Difference between revisions of "GNU/consensus/berlin-2013"
m (→Elijah's Proposal (ES): typo) |
(reorg some) |
||
| Line 4: | Line 4: | ||
'''The objective of this page is to come up with a short list of objectives we all share, and identify issues.''' | '''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 [[Talk:GNU/consensus/berlin-2013|associated Talk page]].''' | '''This section provides additional details for consensual issues. If the description does not match your expectations, please discuss it in the [[Talk:GNU/consensus/berlin-2013|associated Talk page]].''' | ||
| − | == | + | == Basic Requirements == |
| − | End-to- | + | === End-to-end encryption === |
| − | + | {{Consensus}} | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | 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. | |
| − | + | === Social graph and transmission pattern obfuscation === | |
| − | |||
| − | === | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
{{Consensus}} | {{Consensus}} | ||
| − | + | Interpersonal [[GNU/consensus/relationships|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. | |
| + | [[User:CvL|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. | ||
| − | === | + | === Self determined data storage === |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
{{Consensus}} | {{Consensus}} | ||
| Line 54: | Line 29: | ||
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). | 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). | ||
| − | + | [[User:CvL|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. | |
| + | See also: OwnCloud, RetroShare, secushare. | ||
| − | === | + | === High availability === |
{{Need details}} | {{Need details}} | ||
| − | + | You should be able to access your data when you want it. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| + | [[User:CvL|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. | ||
| − | === | + | === Scalability === |
{{Need details}} | {{Need details}} | ||
| − | + | [[User:CvL|lynX]]: Multicast strategies. Learn from Bittorrent. Try Gnunet Mesh. | |
| + | == Welcome features == | ||
| − | === | + | === Device portability === |
{{Need details}} | {{Need details}} | ||
| Line 95: | Line 57: | ||
[[User:Mrogers|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. | [[User:Mrogers|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. | ||
| + | [[User:CvL|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. | ||
| − | === | + | === User interface choice === |
{{Need details}} | {{Need details}} | ||
| Line 104: | Line 67: | ||
[[User:Mrogers|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. | [[User:Mrogers|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. | ||
| − | [[User:CvL|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 | + | [[User:CvL|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. |
| − | |||
| − | |||
| + | [[User:CvL|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. | ||
| − | === | + | === Multiple identity === |
{{Need details}} | {{Need details}} | ||
| Line 117: | Line 79: | ||
[[User:Mrogers|Michael]]: One person should be able to speak/listen with many identities, and many people should be able to speak/listen with one identity. | [[User:Mrogers|Michael]]: One person should be able to speak/listen with many identities, and many people should be able to speak/listen with one identity. | ||
| + | [[User:CvL|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. | ||
| − | === | + | === Secure groups === |
{{Need details}} | {{Need details}} | ||
| + | |||
| + | 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. | ||
| + | |||
| + | [[User:Mrogers|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. | ||
| + | |||
| + | [[User:CvL|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. | ||
| + | |||
| + | == Things we don't need, really == | ||
| + | |||
| + | === Protocol agnostic === | ||
| + | |||
| + | {{Consensus|no}} | ||
You should be able to cross-communicate with different protocols, be they XMPP, HTTP, or p2p based. | You should be able to cross-communicate with different protocols, be they XMPP, HTTP, or p2p based. | ||
| Line 126: | Line 102: | ||
[[User:Mrogers|Michael]]: Again, this seems like an implementation detail. Interoperation between platforms or providers is presumably the goal here, not protocols for their own sake. | [[User:Mrogers|Michael]]: Again, this seems like an implementation detail. Interoperation between platforms or providers is presumably the goal here, not protocols for their own sake. | ||
| − | [[User:CvL|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 | + | [[User:CvL|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. |
| + | |||
| + | === Integration of old friends on legacy networks === | ||
| + | {{Consensus|no}} | ||
| − | + | 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. | |
| + | |||
| + | [[User:CvL|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 | ||
| − | + | [[User:Hellekin|hellekin]]: In any case, a migration strategy is needed in the meantime. | |
| − | |||
| − | [[User: | + | [[User:CvL|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). |
Revision as of 11:35, 7 August 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.
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.
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.
See also: OwnCloud, RetroShare, secushare.
High 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.
Scalability
lynX: Multicast strategies. Learn from Bittorrent. Try Gnunet Mesh.
Welcome features
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.
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.
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.
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.
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.
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).
