Difference between revisions of "GNU/consensus/berlin-2013"

From LibrePlanet
< GNU‎ | consensus
Jump to: navigation, search
(Identified comments. Integrated lynX's comments.)
Line 1: Line 1:
 
= Socialnet_3.0 =
 
= Socialnet_3.0 =
  
Preparing Berlin's workshop, August 24-25 2013.
+
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.'''
 
'''The objective of this page is to come up with a short list of objectives we all share, and identify issues.'''
 +
 +
== Consensus on Minimal Requirements ==
 +
 +
{{Consensus}}
 +
 +
'''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]].'''
 +
 +
=== 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 Obfuscation ===
 +
 +
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.
 +
 +
=== Self-Determined Storage ===
 +
 +
Each person should be able to elect how their data is stored. At minimum, online social services must protect the privacy of their users, and provide a way for them to control it. That includes exporting the files, and being aware of third party requests for any data provided by a user.
  
  
 
== Elijah's Proposal (ES) ==
 
== Elijah's Proposal (ES) ==
 +
 +
'''From this section started the page. It will eventually dissolves into the previous section.'''
  
 
=== 1) Client side encryption ===
 
=== 1) Client side encryption ===
Line 50: Line 78:
  
 
[[User:Hellekin|hellekin]]: In any case, a migration strategy is needed in the meantime.
 
[[User:Hellekin|hellekin]]: In any case, a migration strategy is needed in the meantime.
 
 
  
  
Line 88: Line 114:
  
 
You should be able to maintain multiple identities, and choose to link them or not.
 
You should be able to maintain multiple identities, and choose to link them or not.
 +
 +
[[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.
  
  

Revision as of 14:32, 5 August 2013

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.

Consensus on Minimal Requirements

We could reach consensus on this point. :)

This section provides additional details for consensual issues. If the description does not match your expectations, please discuss it in the associated Talk page.

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 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.

Self-Determined Storage

Each person should be able to elect how their data is stored. At minimum, online social services must protect the privacy of their users, and provide a way for them to control it. That includes exporting the files, and being aware of third party requests for any data provided by a user.


Elijah's Proposal (ES)

From this section started the page. It will eventually dissolves into the previous section.

1) Client side encryption

We could reach consensus on this point. :)

Klaus: End-to-end encryption whenever I share information with friends - that will be realised by secushare.org


2) Social graph obfuscation

We could reach consensus on this point. :)


3) Self determined data storage

We could reach consensus on this point. :)

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).

See OwnCloud, GNUnet, RetroShare.


4) Scalability

Resolving this point requires more details. There is no consensus yet on this point. :(

lynX: Multicast strategies. Learn from Bittorrent. Try Gnunet Mesh.


5) Integration of old friends on legacy networks

There is no consensus yet on this point. :(

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.


6) High availability

Resolving this point requires more details. There is no consensus yet on this point. :(

You should be able to access your data when you want it.


7) Device portability

Resolving this point requires more details. There is no consensus yet on this point. :(

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.


8) Client choice

Resolving this point requires more details. There is no consensus yet on this point. :(

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 must be secure: if your device isn't running a free operating system, you can't be sure of anything.

lynX (cont'd): 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.


9) Multiple identity

Resolving this point requires more details. There is no consensus yet on this point. :(

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.


10) Protocol agnostic

Resolving this point requires more details. There is no consensus yet on this point. :(

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 grandmother that some chatrooms, forums, fan pages or individuals are "not safe" to interact with.


11) Secure groups

Resolving this point requires more details. There is no consensus yet on this point. :(

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.