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 -- Liberationtech is public & archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at [email protected].
