[liberationtech] An interesting anonymous chat project: Invisible.im

[carlo von lynX]

On Fri, Jul 11, 2014 at 07:24:45PM +0200, Fabio Pietrosanti (naif) wrote:
> I feel that we don't need another IM, but we need:
> - CONSOLIDATION of existing opensource/secure technologies
> - INTEROPERABILITY among existing opensource/secure technologies

naif, I love you, but you're sooo wrong on this.  :)

> We need to focus on what's already in the user's hand, make it  ubiquous
> and interoperable.
> 
> There are other "IM approach" that try to use Tor for anonymous chatting
> such as:
> - TorChat: https://github.com/prof7bit/TorChat
> - jTorChat: https://github.com/jtorchat/jtorchat
> - Richolet: https://ricochet.im/

And none of them solve the hidden service scalability problem.

Also, invisible.im's got a point I was wrong about in my last
mail - I had forgotten why I gave up on Tor federation: Tor
auth is one way - you know who you are connecting to but you
don't know who is connecting you. Tor could possibly solve that
by providing a demonstration of ownership of the onion's private
key, but I presume this doesn't exist yet. So the protocols
need to somehow do that on top.

Using ratchets to authenticate at the current point in time
without needing an "absolute" identity (the thing about OTR
being used in an ephemeral way) is how Briar does it. It
makes it harder to reconstruct the social graph as you need
to break into both sides of a communication. If you then
periodically inform everyone of a new .onion you are about
to use, then you make it harder to link a .onion to a person,
but you risk losing people if you can't be sure everyone got
that address change - and the more friends you have, the
lesser that works as a form of social graph protection really.

No, you shouldn't have a hidden service for each friend, as
that would blow up Tor in no time. So I still see a problem
there. Ephemerals on both sides are great, but the Tor DHT
isn't built for ephemeral rendezvous events. It is built for
having as few hidden service ports as possible - and having
to establish lots of circuits to each contact, just to say -
hi - i am online now - is already a problem enough.

> Any attempt to improve security is good, but i would strongly
> concentrate on consolidating and collaborating with existing projects,
> by improving them, rather than reinventing the wheel.

Well, in a situation were none of the solutions are safe and
scalable, why on earth would you want consolidation and even
interoperability? We need at least one solution that is
recommendable, then others can be compatible to it. Standards
and interoperability are only important when dealing with
providers of proprietary technologies - we have none of those
here. What we need now is a large degree of experimentation
and most of all interest in learning from the mistakes of
others - people keep redoing the same mistakes! People keep
pushing the scalability issue aside because it is not fun to solve.

> For example i would suggest to leverage existing CryptoCat codebase, to
> adapt/improve it to the requirements of "invisible.im" .

Why?

> Remember that maybe 90% of software job is making the software product
> to works properly, not making it secure.
> 
> If someone else already have done the 90% job, just focus on the 10%
> minor security improvements here and there.

What if the problem of most implementations is at the foundation of
the architecture? Also, invisible.im are reusing prosody and libotr so
they are already doing as you say - more than I would recommend.  ;)


-- 
	    http://youbroketheinternet.org
 ircs://psyced.org/youbroketheinternet