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
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: packet padding, intentional delays, strategic per-packet choice of number of hops and plenty of cover traffic. Luckily, social network chatter is a fine source of cover traffic.
Implemented in: GNUnet, Tor, phantom, I2P, Briar?
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: OwnCloud, RetroShare, libpsyc, Briar?
Scalability
lynX: Multicast strategies. Learn from Bittorrent. Try Gnunet Mesh.
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
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?
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?
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, 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, 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, I2P(too sloooow!!)
Real-time streaming
Implemented in: Retroshare, GlobalSquare, 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
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)
Open questions
What the hell is Goldbug?
