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

From LibrePlanet
< GNU‎ | consensus
Jump to: navigation, search
(reorg some)
(clearer formulation concerning Self determined data storage)
 
(11 intermediate revisions by 2 users not shown)
Line 14: Line 14:
  
 
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.
 
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:''' OTR, PGP, Retroshare, Pond, Briar, I2P?, Tahoe-LAFS?, OwnCloud?, GlobalSquare?
 +
 +
'''Not implemented in:''' Diaspora, Friendica, GNU Social, Kune, Jappix, Movim, Buddycloud, StatusNet, Pump.IO, Sockethub, Tent... and many more
 +
 +
[[User:CvL|lynX]]: As you know I am very [http://secushare.org/end2end doubtful of web-browser based solutions]
 +
 +
=== Perfect Forward Secrecy ===
 +
 +
{{Consensus}}
 +
 +
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. Briar and RetroShare use similar approaches. OTR requires both sides to be online, which doesn't always work out.
 +
 +
'''Implemented on link level:''' Tor, I2P, Retroshare, Briar, OwnCloud?, GlobalSquare?
 +
 +
'''Implemented end-to-end:''' Pond, OTR, Briar, RetroShare?, I2P?
 +
 +
'''Planned in:''' GNUnet/libpsyc
  
 
=== Social graph and transmission pattern obfuscation ===
 
=== Social graph and transmission pattern obfuscation ===
Line 21: Line 41:
 
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.
 
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.
+
[[User:CvL|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 [http://secushare.org/conspiracy 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:''' Tor, I2P, GNUnet?, phantom?, Briar?
 +
 
 +
'''Not implemented in:''' Diaspora, Friendica, GNU Social, Kune, Jappix, Movim, Buddycloud, StatusNet, Pump.IO, Sockethub, Tent... and many more
  
 
=== Self determined data storage ===
 
=== Self determined data storage ===
Line 29: Line 53:
 
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.
+
[[User:CvL|lynX]]: To make it clear, by self-determined we don't mean that you have to choose between hell and inferno on which server you have to store your data, but rather that your data will ''exclusively'' exist in the clear only on the user devices of the people that you chose to share it with. That also means that if you don't share it with anybody, this features allows you to sync private data between your own devices.
 +
 
 +
'''Implemented in:''' Tahoe-LAFS, OwnCloud, RetroShare, libpsyc, Pond
  
−
See also: OwnCloud, RetroShare, secushare.
+
'''Not implemented in:''' Diaspora, Friendica, GNU Social, Kune, Jappix, Movim, Buddycloud, StatusNet, Pump.IO, Sockethub, Tent... and many more
  
−
=== High availability ===
+
=== Scalability ===
  
 
{{Need details}}
 
{{Need details}}
  
−
You should be able to access your data when you want it.
+
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.
 +
 
 +
[[User:CvL|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: [https://en.wikipedia.org/wiki/BigCouch BigCouch], [https://en.wikipedia.org/wiki/Cassandra_%28database%29 Cassandra], [https://en.wikipedia.org/wiki/Couchbase_Server Couchbase], [https://en.wikipedia.org/wiki/Apache_Hadoop Hadoop], [https://en.wikipedia.org/wiki/HBase HBase], [https://en.wikipedia.org/wiki/MongoDB MongoDB]. [https://en.wikipedia.org/wiki/Redis 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 [http://about.psyc.eu/Multicast PSYC developers] are working on a multicast strategy that makes sense to integrate with onion routing.
 +
 
 +
'''Implemented in:''' GlobalSquare
 +
 
 +
'''Planned in:''' GNUnet/libpsyc
 +
 
 +
'''Not implemented in:''' the rest
  
−
[[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.
+
== Welcome features ==
  
−
=== Scalability ===
+
=== High data availability ===
  
 
{{Need details}}
 
{{Need details}}
  
−
[[User:CvL|lynX]]: Multicast strategies. Learn from Bittorrent. Try Gnunet Mesh.
+
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.
 +
 
 +
'''Implemented in:''' Retroshare, Briar, libpsyc, Pond?
  
−
== Welcome features ==
+
'''Not implemented in:''' Diaspora, Friendica, GNU Social, Kune, Jappix, Movim, Buddycloud, StatusNet, Pump.IO, Sockethub, Tent... and many more
  
 
=== Device portability ===
 
=== Device portability ===
Line 58: Line 96:
  
 
[[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: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.
 +
 +
'''Implemented in:''' Retroshare?, Tor?, I2P?, Briar?, Pond?
 +
 +
'''Planned in:''' libpsyc (= core library of secushare)
  
 
=== User interface choice ===
 
=== User interface choice ===
Line 63: Line 105:
 
{{Need details}}  
 
{{Need details}}  
  
−
You should be able to use a mobile, desktop, or html5 app client (once webcrypto is deployed in browsers).
+
Somebody said you should be able to use a mobile, desktop, or html5 app client (once webcrypto is deployed in browsers).  
  
 
[[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.
Line 69: Line 111:
 
[[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]]: 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.
+
[[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 (and thus become interesting for coercion), but only as agnostic routers for fully operational mobile nodes.
 +
 
 +
'''Implemented in:''' Retroshare, Tor?, I2P?, Briar?, Pond?
 +
 
 +
'''Planned in:''' libpsycclient (= user interface library for secushare)
 +
 
 +
=== Software security, free software ===
 +
 
 +
{{Need details}}
 +
 
 +
Software security is about the path the software, which is going to be encharged of providing end-to-end encryption and other crucial parts of the privacy puzzle, takes to get onto your devices. Libre, peer-reviewed and cryptographically signed software distribution is important. For reasons that are obvious to anyone at GNU, any such software has to be free software.
 +
 
 +
'''Implemented in:''' all non-silo-oriented free software.
 +
 
 +
[[User:CvL|lynX]]:  But free software alone is no guarantee if for example in the Jabber/XMPP world there is a strong tendency for people to use large silo installations. In that case no peer review is realistically happening. We are now living in a world, [https://leastauthority.com/blog/open_letter_silent_circle.html where any single person or company can be coerced] to put backdoors into a piece of binary code, if there is sufficient interest in doing so. Even companies that release source code only help the ones that know how to spend the extra effort of regularely updating their own program binaries - the vast majority of users still depend on the distribution channel to be healthy. It becomes therefore important to decentralize and double-check the distribution channel. If Google's, Apple's or the company's own distribution channels are the only options, this is bad. Software distribution has to happen in source code, several distributors can then generate binaries and feed them into their respective distribution channels. This is how free software OS distributions work. It is odd how something similar hasn't established itself in the Apple and Microsoft worlds. Best even if the code is compiled at home as with Gentoo. Soon we'll have compilers that actually produce identical binaries from identical source codes, so we have an improved way to check the correctness of the binaries coming our way. That will solve a few problems in this field.
  
 
=== Multiple identity ===  
 
=== Multiple identity ===  
Line 80: Line 136:
  
 
[[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.
 
[[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.
 +
 +
'''Implemented in:''' Retroshare, Tor, Pond, I2P?, GNUnet?, Briar?
  
 
=== Secure groups ===
 
=== Secure groups ===
Line 91: Line 149:
  
 
[[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.
 
[[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.
 +
 +
'''Implemented in:''' Briar, Retroshare, libpsyc, I2P?
 +
 +
=== File exchange ===
 +
 +
{{Need details}}
 +
 +
Share files and documents between contacts and small groups.
 +
 +
'''Implemented in:''' Briar, Retroshare, Tor, Pond, GNUnet, GlobalSquare, I2P(sloooow!)
 +
 +
=== File sharing ===
 +
 +
{{Need details}}
 +
 +
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 ===
 +
 +
{{Need details}}
 +
 +
'''Implemented in:''' Retroshare, GlobalSquare, Tor?, I2P?
 +
 +
'''Planned in:''' GNUnet
 +
 +
=== Telephony ===
 +
 +
{{Need details}}
 +
 +
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 ==
 
== Things we don't need, really ==
Line 103: Line 197:
  
 
[[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.
 
[[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.
 +
 +
'''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 ===
 
=== Integration of old friends on legacy networks ===
Line 119: Line 217:
  
 
[[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).
 
[[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).
 +
 +
'''Implemented in:''' Retroshare (invite by email), psyced?
 +
 +
== Open questions ==
 +
 +
What the hell is [http://sourceforge.net/p/goldbug/wiki/Home/ Goldbug]?
 +
 +
 +
== INVITATION FOR 30C3 ==
 +
 +
'''#youbroketheinternet - we'll make ourselves a new one'''
 +
 +
Social networking is a means of direct, group based, and international communication that became a basic commodity of life for very many people. For those born after 1990 it is the normal state of the world.
 +
Both individuals and companies want to keep informational self determination (sovereignty) and ownership of their data not only in social networks. Social and environmental activists are dependent on trustworthy communication via secure and linked-up channels.
 +
"Trustworthiness" encompasses features such as end-to-end encryption, social graph obfuscation, forward secrecy, self determined data storage, free and open software and, in the very end, self determined communication meshes, independent from hierarchically managed networks, as well as free and open hardware that is unlikely to be equipped with backdoors.
 +
 +
youbroketheinternet is an initiative to create a scalable social communications and data exchange network that brings all the things you need to share to just the people that are intended to have it. Already, a substantial number of projects exist that purport to fullfill these goals. Looking closer at those projects in the past two years made it clear that they all have serious deficiencies as regards either privacy, scalability, or usability. But the existing projects also have their merits. Therefore, #youbroketheinternet will not try to build the ideal system from scratch, but rather it will try to integrate, re-use, and re-orient existing projects to work towards a common goal.
 +
 +
To this end we want to organize a cluster of events at 30C3. An introductory panel presentation as kick-off, and a series of workshops with introductory talks on the following topics:
 +
 +
*  Social Net Politics and Political Attack Vectors
 +
*  Usability and Adoption Threshold
 +
*  Scalability and Architecture
 +
*  Crypto Routing Cores
 +
*  (Wireless) Mesh Networks
 +
*  Open Hardware
 +
*  Fincancing and Business Models
 +
 +
 +
'''Social Net Politics and Political Attack Vectors:'''
 +
Using communication technology as a tool for solving social problems is regarded "dangerous" by the elite.
 +
 +
'''Usability and Adoption Threshold:'''
 +
How can we appeal to a large audience? And how can we make the technologies developed grandparent compatible?
 +
 +
'''Scalability and Architecture:'''
 +
How can we build systems that are capable of scaling to, in the best case, some hundred million users? How can we leverage the distributed computing power and refuse to be thrown back into the cloud?
 +
 +
'''Crypto Routing Cores:'''
 +
How can we achieve confidential transmission of information? How much anonymity is possible and what are the tradeoffs?
 +
 +
'''(Wireless) Mesh Networks:'''
 +
We need more infrastructure that is run independently of nation states or for-profit corporations. How can we as a society operate networks for the common good?
 +
 +
'''Open Hardware:'''
 +
If the hardware we are running our systems on is intrinsically insecure, we may be building a fortress on top of a house of cards. What is required on the lowest levels to get reasonable endpoint security?
 +
 +
'''Fincancing and Business Models:'''
 +
Operating networks and developing software that do not, by design, allow the aggregation,  marketing, and eavesdropping of user data is a technical challenge. Making it trustworthy for the general public calls for free and open software. This creates its own challenges when it comes to financing and sustaining a business. How can we get done what we think is right and still afford a living?
 +
 +
 +
'''Invited projects (so far) are'''
 +
:<no longer up to date/>
 +
 +
 +
'''Open list of supporters:'''
 +
:<no longer up to date/>

Latest revision as of 15:58, 20 November 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.

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

We could reach consensus on this point. :)

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: OTR, PGP, Retroshare, Pond, Briar, I2P?, Tahoe-LAFS?, OwnCloud?, GlobalSquare?

Not implemented in: Diaspora, Friendica, GNU Social, Kune, Jappix, Movim, Buddycloud, StatusNet, Pump.IO, Sockethub, Tent... and many more

lynX: As you know I am very doubtful of web-browser based solutions

Perfect Forward Secrecy

We could reach consensus on this point. :)

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. Briar and RetroShare use similar approaches. OTR requires both sides to be online, which doesn't always work out.

Implemented on link level: Tor, I2P, Retroshare, Briar, OwnCloud?, GlobalSquare?

Implemented end-to-end: Pond, OTR, Briar, RetroShare?, I2P?

Planned in: GNUnet/libpsyc

Social graph and transmission pattern obfuscation

We could reach consensus on this point. :)

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: Tor, I2P, GNUnet?, phantom?, Briar?

Not implemented in: Diaspora, Friendica, GNU Social, Kune, Jappix, Movim, Buddycloud, StatusNet, Pump.IO, Sockethub, Tent... and many more

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

lynX: To make it clear, by self-determined we don't mean that you have to choose between hell and inferno on which server you have to store your data, but rather that your data will exclusively exist in the clear only on the user devices of the people that you chose to share it with. That also means that if you don't share it with anybody, this features allows you to sync private data between your own devices.

Implemented in: Tahoe-LAFS, OwnCloud, RetroShare, libpsyc, Pond

Not implemented in: Diaspora, Friendica, GNU Social, Kune, Jappix, Movim, Buddycloud, StatusNet, Pump.IO, Sockethub, Tent... and many more

Scalability

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

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

Not implemented in: the rest

Welcome features

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

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?

Not implemented in: Diaspora, Friendica, GNU Social, Kune, Jappix, Movim, Buddycloud, StatusNet, Pump.IO, Sockethub, Tent... and many more

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.

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

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

Somebody said 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 (and thus become interesting for coercion), but only as agnostic routers for fully operational mobile nodes.

Implemented in: Retroshare, Tor?, I2P?, Briar?, Pond?

Planned in: libpsycclient (= user interface library for secushare)

Software security, free software

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

Software security is about the path the software, which is going to be encharged of providing end-to-end encryption and other crucial parts of the privacy puzzle, takes to get onto your devices. Libre, peer-reviewed and cryptographically signed software distribution is important. For reasons that are obvious to anyone at GNU, any such software has to be free software.

Implemented in: all non-silo-oriented free software.

lynX: But free software alone is no guarantee if for example in the Jabber/XMPP world there is a strong tendency for people to use large silo installations. In that case no peer review is realistically happening. We are now living in a world, where any single person or company can be coerced to put backdoors into a piece of binary code, if there is sufficient interest in doing so. Even companies that release source code only help the ones that know how to spend the extra effort of regularely updating their own program binaries - the vast majority of users still depend on the distribution channel to be healthy. It becomes therefore important to decentralize and double-check the distribution channel. If Google's, Apple's or the company's own distribution channels are the only options, this is bad. Software distribution has to happen in source code, several distributors can then generate binaries and feed them into their respective distribution channels. This is how free software OS distributions work. It is odd how something similar hasn't established itself in the Apple and Microsoft worlds. Best even if the code is compiled at home as with Gentoo. Soon we'll have compilers that actually produce identical binaries from identical source codes, so we have an improved way to check the correctness of the binaries coming our way. That will solve a few problems in this field.

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.

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

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.

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

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

Share files and documents between contacts and small groups.

Implemented in: Briar, Retroshare, Tor, Pond, GNUnet, GlobalSquare, I2P(sloooow!)

File sharing

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

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

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

Implemented in: Retroshare, GlobalSquare, Tor?, I2P?

Planned in: GNUnet

Telephony

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

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

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

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.

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?


INVITATION FOR 30C3

#youbroketheinternet - we'll make ourselves a new one

Social networking is a means of direct, group based, and international communication that became a basic commodity of life for very many people. For those born after 1990 it is the normal state of the world. Both individuals and companies want to keep informational self determination (sovereignty) and ownership of their data not only in social networks. Social and environmental activists are dependent on trustworthy communication via secure and linked-up channels. "Trustworthiness" encompasses features such as end-to-end encryption, social graph obfuscation, forward secrecy, self determined data storage, free and open software and, in the very end, self determined communication meshes, independent from hierarchically managed networks, as well as free and open hardware that is unlikely to be equipped with backdoors.

youbroketheinternet is an initiative to create a scalable social communications and data exchange network that brings all the things you need to share to just the people that are intended to have it. Already, a substantial number of projects exist that purport to fullfill these goals. Looking closer at those projects in the past two years made it clear that they all have serious deficiencies as regards either privacy, scalability, or usability. But the existing projects also have their merits. Therefore, #youbroketheinternet will not try to build the ideal system from scratch, but rather it will try to integrate, re-use, and re-orient existing projects to work towards a common goal.

To this end we want to organize a cluster of events at 30C3. An introductory panel presentation as kick-off, and a series of workshops with introductory talks on the following topics:

  • Social Net Politics and Political Attack Vectors
  • Usability and Adoption Threshold
  • Scalability and Architecture
  • Crypto Routing Cores
  • (Wireless) Mesh Networks
  • Open Hardware
  • Fincancing and Business Models


Social Net Politics and Political Attack Vectors: Using communication technology as a tool for solving social problems is regarded "dangerous" by the elite.

Usability and Adoption Threshold: How can we appeal to a large audience? And how can we make the technologies developed grandparent compatible?

Scalability and Architecture: How can we build systems that are capable of scaling to, in the best case, some hundred million users? How can we leverage the distributed computing power and refuse to be thrown back into the cloud?

Crypto Routing Cores: How can we achieve confidential transmission of information? How much anonymity is possible and what are the tradeoffs?

(Wireless) Mesh Networks: We need more infrastructure that is run independently of nation states or for-profit corporations. How can we as a society operate networks for the common good?

Open Hardware: If the hardware we are running our systems on is intrinsically insecure, we may be building a fortress on top of a house of cards. What is required on the lowest levels to get reasonable endpoint security?

Fincancing and Business Models: Operating networks and developing software that do not, by design, allow the aggregation, marketing, and eavesdropping of user data is a technical challenge. Making it trustworthy for the general public calls for free and open software. This creates its own challenges when it comes to financing and sustaining a business. How can we get done what we think is right and still afford a living?


Invited projects (so far) are

<no longer up to date/>


Open list of supporters:

<no longer up to date/>
Retrieved from "https://libreplanet.org/wiki?title=GNU/consensus/berlin-2013&oldid=33956"