-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 18/09/14 14:20, Nathan of Guardian wrote: > They should have learned more from Twister: http://twister.net.co/ > since they have thought about the metadata issue a lot: > > "twister is the fully decentralized P2P microblogging platform > leveraging from the free software implementations of Bitcoin and > BitTorrent protocols." > > The other news yesterday was about Richocet aka Invsible.IM, which > is basically just TorChat evolved (P2P hidden service chat). > Unfortunately, it has a very fragile binary protocol, and depends > on the idea of massive scaling of Tor Hidden Services, which they > were not designed to do: > > https://github.com/ricochet-im/ricochet > > Any comment or update from Briar folk about either of these > systems?
(CCing the hidden-services list in case anyone there wants to offer a more informed opinion than mine.) I haven't looked deeply into Twister or Ricochet, but here are my initial thoughts. I'm really impressed by Twister as a piece of distributed systems engineering, but I'm not sure its metadata privacy is terribly strong. Anyone can participate in an account's swarm of followers to see who else is in the swarm and to receive messages (including encrypted DMs) sent by that account. That enables some basic traffic analysis: anyone can see that Alice and Bob participate in each other's swarms and therefore follow each other; if Alice sends a DM at 12.01, Bob sends one at 12.02, Alice at 12.03, and Bob at 12.04, what are we seeing? It's interesting that Invisible.im has switched from XMPP-over-Tor to Ricochet - I wonder whether that choice was made for protocol reasons or to avoid fragmentation of effort. I suppose presence is one aspect of XMPP that's a poor fit for P2P, as it requires you to poll for connections to your peers even when you don't want to talk to them. (I think you've argued in the past that presence is a poor fit for mobile too, which I agree with - so maybe a custom protocol is a good choice here.) Ricochet's binary protocol is moving to Protocol Buffers, which should help with the fragility concerns. In any case, consider the alternatives: I don't think either libpurple or libsmack could really be described as bulletproof... I don't see anything in the Tor HS design that would prevent it from supporting a large number of low-traffic services. The HS directories are essentially a DHT accessed via Tor, so the number of DHT nodes has to grow with the number of services - but as far as I know the HS directories are just ordinary relays, so this reduces to the perennial problem of ensuring enough relay capacity. I do have concerns about the HS design and implementation when services lose connectivity frequently, but I'm hoping those can be addressed at the endpoints by (a) not caching hidden service descriptors and (b) publishing an empty set of introduction points when a service knows it's going offline. When I get some time to work on this again I'll do some experiments to test those hopes. Cheers, Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJUHGscAAoJEBEET9GfxSfMvuoH/R7OipPi9k97e49SxjBmDDPJ pCEZt01/0Y7SyK3eLQy5aeuwAgvaVhcbScjdOn58oHBxWopA90nlGmHz7HUl+TML QLRWnhpBDcd0Tk6BaoV7gvVYMStTRTPYZxtX8+8QjIDzCwuIb24HiRd7YSFsRNLX uXuL7PGBwOrudYG289+WK5g8aLs0ZC8kgPuxaKGz8IcUN9duKKRkrv+Oi7bm4jzQ /STc2Nx6pgVMdpZU6gPFi4AlvmDmr+bdnAiXhzoq+JH56A0GshHtadrNGD6NZA+f g0hVe/HYexWjRc3zsN7/v21MKiMApvnbcghg8AM44oJpKOXU3aqfHAPmvvqPPqw= =mDrl -----END PGP SIGNATURE----- _______________________________________________ Guardian-dev mailing list Post: [email protected] List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To Unsubscribe Send email to: [email protected] Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/archive%40mail-archive.com You are subscribed as: [email protected]
