GNU/consensus/berlin-2013
Contents
Socialnet_3.0
Preparing Berlin's workshop, August 24-25 2013, on the next decade's strategies for privacy-preserving free social networking software.
The objective of this page is to come up with a short list of objectives we all share, and identify issues.
This section provides additional details for consensual issues. If the description does not match your expectations, please discuss it in the associated Talk page.
Basic Requirements
End-to-end encryption
End-to-End encryption is a basic requirement for social network programs to respect privacy by design. Friend-to-friend encryption reflects basic Human Rights and Constitutional Rights in democratic countries under the regime of res publica. Encryption of connections to access public contents also makes sense as a privacy-preserving tool, against abusive surveillance. Therefore, free social software must provide strong encryption support by default, and leave it to the user to opt-out from encryption.
Implemented in: all viable candidates (except GlobalSquare?)
lynX: As you know I am very doubtful of web-browser based solutions
Perfect Forward Secrecy
It takes special effort that usually goes by the acronyms DHE or ECDHE to ensure that things you said cannot forever be tied to your identity and retroactively be decrypted if somebody gets her hands on your device. TLS typically provides this on link-level, but it is susceptible to downgrade attacks. Retroshare has it on the wire, but when the messages arrive they are either unencrypted or regularely PGP-encrypted, thus not forward secret.
<lynX> The problem with ephemeral keys is, when is the right moment to throw them away? Pond has a very advanced opportunistic approach to this problem that we need to imitate. OTR requires both sides to be online, which doesn't always work out.
Implemented on link level: all viable candidates (except GlobalSquare?)
Implemented end-to-end: Pond, OTR, Briar?, I2P?
Planned in: GNUnet/libpsyc
Social graph and transmission pattern obfuscation
Interpersonal relationships belong to the people making them, and as such belong to the private sphere of each individual. Free social software should thrive to protect this information from third parties.
lynX: Doesn't make much sense to use anything less but onion routing. In fact we should have more than just that. Current onion routers such as Tor and I2P were built assuming that a global adversary is a too paranoid presumption. Stuff that conspiracy theories are made of. Well, Mr Snowden has taught us that the global adversary is working hard to implement that kind of approach. Thus we should step up our strategies beyond just mere onion routing. GNUnet has experimented with some nifty features such as packet padding, intentional delays, strategic per-packet choice of number of hops and plenty of cover traffic. Chances are, we shouldn't dare anything less. Luckily, social network chatter is a fine source of cover traffic. It will be hard to distinguish a social one-to-many distribution from a packet that is being onion-routed.
Implemented in: GNUnet?, phantom?, Briar?, Tor, I2P.
Self determined data storage
Klaus: Self determined storage of my data in a platform independent way - that will be realised by unhosted.org (and it is already built into Diaspora as a possibility afaik).
lynX: unhosted handles situations where data needs to be used by web applications in order to fulfil their scope (SaaS). It is however even better if applications reside on your own computer in the form of free software - in this case the data that goes with it only needs to be on your own computers, or if you like to, made available to people you share it with.
Implemented in: Tahoe-LAFS, OwnCloud, RetroShare, libpsyc, Pond, Briar?
Scalability
Here are the details: Social networking requires a scalable many-to-many distribution strategy because every little gesture.. a posting, a comment on a posting.. is always a message to potentially thousands of recipients (if we want to try to reach the popularity of Faceboogle). We need an implementation of a distribution strategy, integrated or at least on top of our routing infrastructure. Even if we chose to run a federation, the problem doesn't go away. Only a silo would be easier, since there are existing solutions for that.
lynX: Silos use solutions that distribute via database replication which typically imply that the nodes are owned by the same company and run under a common policy of trust and administration. Some examples of such apps: BigCouch, Cassandra, Couchbase, Hadoop, HBase, MongoDB. Redis uses multicast (described as "A slave may be a master to another slave"). We can also learn from Bittorrent how to make multicast work for the general public. The GNUnet and PSYC developers are working on a multicast strategy that makes sense to integrate with onion routing.
Implemented in: GlobalSquare
Planned in: GNUnet/libpsyc
Welcome features
High data availability
You should be able to access your data when you want it.
lynX: Best, if it already is on your devices so you can look up a friend's phone number even when you're out of reach for Internet.
Implemented in: Retroshare, Briar, libpsyc, Pond?
Device portability
You should be able to access your data from multiple devices at the same time
Michael: This may conflict with self-determined data storage (ES#3): if I want to store data on my own device, it may not be accessible from elsewhere.
lynX: No problem if the protocol has a flexible channel subscription model, then your own data is just data sets in such channels and your devices can subscribe to them, thus stay synced. Still you are in charge of deciding access to your data.
Implemented in: Retroshare?, Tor?, I2P?, Briar?, Pond?
Planned in: libpsyc (= core library of secushare)
User interface choice
You should be able to use a mobile, desktop, or html5 app client (once webcrypto is deployed in browsers).
Michael: You should have a choice of clients, but html5 is an implementation detail - we should agree on principles at this stage, not implementation details.
lynX: With all the loopholes in HTTP combined with JS and HTML, web-based is always dangerous for privacy. Browsers are particularely unreliable for encryption jobs. Still, a localhost-based web interface or smartphone-like app is viable as an alternative to a native user interface. Of course the foundation the browser or app runs on may reduce the quality of your privacy: if your device isn't running a free operating system, privacy-enhancing software probably protects your everyday communications... unless somebody has serious interest in you.
lynX: You may want to question the terms "client" and "server" since such architectures are frequently part of the problem. Our aim is for self-sufficient nodes and if you really really need a "server" it must be free from administration requirements and capable of running in your home. Servers must not serve large numbers of users of dumb client apps, but only as routers for fully operational mobile nodes.
Implemented in: Retroshare, Tor?, I2P?, Briar?, Pond?
Planned in: libpsycclient (= user interface library for secushare)
Multiple identity
You should be able to maintain multiple identities, and choose to link them or not.
Michael: One person should be able to speak/listen with many identities, and many people should be able to speak/listen with one identity.
lynX: Boils down to being able to host multiple public-key-based identities in a single network node. The user interface may be able to handle them in parallel or cheat by having you switch.
Implemented in: Retroshare, Tor, Pond, I2P?, GNUnet?, Briar?
Secure groups
Groups with membership determined cryptographically. Groups function as a virtual user, with all users in the group able to receive and send as the group, because they share a private group-key.
Michael: Whether the group membership is determined cryptographically is an implementation detail. Perhaps it would be better to express this as "group identities", as the sibling of multiple identities (ES#9). One person should be able to speak/listen with many identities, and many people should be able to speak/listen with one identity.
lynX: In order for the platform to fulfil Scalability requirements it needs a multicast group implementation anyhow. This solves distributed storage issues and naturally provides for any other form of secure groups, too. Particularely useful scenario for secure groups is the distribution of the software itself or the management of an entire free operating system. So this is likely to be a by-product of a solid platform, anyway.
Implemented in: Briar, Retroshare, libpsyc, I2P?
File exchange
Share files and documents between contacts and small groups.
Implemented in: Briar, Retroshare, Tor, Pond, GNUnet, GlobalSquare, I2P(sloooow!)
File sharing
Share files to large groups, providing actual distribution and retransmission capabilities. Useful cover traffic for the more important things.
Implemented in: GNUnet, Retroshare, GlobalSquare, Tor(slow), I2P(too sloooow!!)
Real-time streaming
Implemented in: Retroshare, GlobalSquare, Tor?, I2P?
Planned in: GNUnet
Telephony
With or without video, provide for a free Skype replacement (and offer cover traffic for whatever else).
Implemented in: Retroshare, Tox (not a typo), Mumble over Tor
Planned in: GNUnet
Things we don't need, really
Protocol agnostic
You should be able to cross-communicate with different protocols, be they XMPP, HTTP, or p2p based.
Michael: Again, this seems like an implementation detail. Interoperation between platforms or providers is presumably the goal here, not protocols for their own sake.
lynX: For the purpose of tunneling, yes. For the purpose of interaction and exchange, no. All other communication technologies can't offer the same degree of privacy and it would be intransparent having to explain to your grandfather that some chatrooms, forums, fan pages or individuals are "not safe" to interact with.
Tunneling implemented in: Briar, GNUnet, Tor, I2P
Gatewaying implemented in: psyced (= other libpsyc application, gateways to XMPP, IRC, HTTP, SMTP, POP, WAP, telnet)
Integration of old friends on legacy networks
Klaus: A migration strategy, which makes the transfer to socialnet_3.0 painless. This was the most difficult requirement to understand. But the solution is not complicated: Socialnet_3.0 will be a "social browser" that keeps my old contacts going in the world of faceboogle via plugins.
lynX: Not important. Legacy networks aren't at the same level of privacy and security, so they may result in security leaks and downgrade attack scenarios. Facebook never needed to be compatible to anyone else to become the leader, so do we not. People will simply start using our tools and discover they no longer need the other ones. This implies that I also regard 3) A migration strategy from KS' proposal as actually not important to fulfil our goals, although it is feasible anyway. (which would compromise 1 and 2 for those, of course).
- Option #1: keep bridges with legacy infrastructure
- Option #2: abandon legacy infrastructure
hellekin: In any case, a migration strategy is needed in the meantime.
lynX: We can have optional tools that make it easy to invite your contacts, but still it's kind of pointless if we are there-by skipping the authentication step which is important for the new network's credibility. It's better to do strong authentication with some of your contacts, then transitively adopt their friends into your network (as they vouch for them).
Implemented in: Retroshare (invite by email), psyced?
Open questions
What the hell is Goldbug?
