Difference between revisions of "GNU/consensus/berlin-2013"
(→7) Device portability) |
(Page cleanup 1/3) |
||
| Line 2: | Line 2: | ||
Preparing Berlin's workshop, August 24-25 2013. | Preparing Berlin's workshop, August 24-25 2013. | ||
| + | |||
| + | '''The objective of this page is to come up with a short list of objectives we all share, and identify issues.''' | ||
| + | |||
== Klaus' Proposal (KS) == | == Klaus' Proposal (KS) == | ||
| Line 8: | Line 11: | ||
End-to-end encryption whenever I share information with friends - that will be realised by secushare.org | End-to-end encryption whenever I share information with friends - that will be realised by secushare.org | ||
| + | |||
=== 2) Self determined storage === | === 2) Self determined storage === | ||
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). | 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). | ||
| + | |||
=== 3) A migration strategy === | === 3) A migration strategy === | ||
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. | 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. | ||
| + | |||
| Line 22: | Line 28: | ||
=== 1) Client side encryption === | === 1) Client side encryption === | ||
| − | Covers KS#1. | + | {{Consensus}} |
| + | |||
| + | Covers KS#1. | ||
| + | |||
=== 2) Social graph obfuscation === | === 2) Social graph obfuscation === | ||
| − | Consensus | + | {{Consensus}} |
| + | |||
=== 3) Self determined data storage === | === 3) Self determined data storage === | ||
| − | Covers KS#2 | + | {{Consensus}} |
| + | |||
| + | Covers KS#2. See OwnCloud, GNUnet, RetroShare. | ||
| + | |||
=== 4) Scalability === | === 4) Scalability === | ||
| − | Need details | + | {{Need details}} |
| + | |||
=== 5) Integration of old friends on legacy networks === | === 5) Integration of old friends on legacy networks === | ||
| + | |||
| + | {{Consensus|no}} | ||
(which would compromise 1 and 2 for those, of course). | (which would compromise 1 and 2 for those, of course). | ||
| − | Covers KS#3 | + | Covers KS#3. |
* Option #1: keep bridges with legacy infrastructure | * Option #1: keep bridges with legacy infrastructure | ||
| Line 45: | Line 61: | ||
In any case, a migration strategy is needed in the meantime. | In any case, a migration strategy is needed in the meantime. | ||
| + | |||
=== 6) High availability === | === 6) High availability === | ||
| − | + | {{Need details}} | |
| + | |||
| + | You should be able to access your data when you want it. | ||
| − | |||
=== 7) Device portability === | === 7) Device portability === | ||
| − | + | {{Need details}} | |
| − | + | You should be able to access your data from multiple devices at the same time | |
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. | 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 === | === 8) Client choice === | ||
| − | + | {{Need details}} | |
| − | + | You should be able to use a mobile, desktop, or html5 app client (once webcrypto is deployed in browsers). | |
You should have a choice of clients, but html5 is an implementation detail - we should agree on principles at this stage, not implementation details. | You should have a choice of clients, but html5 is an implementation detail - we should agree on principles at this stage, not implementation details. | ||
| + | |||
=== 9) Multiple identity === | === 9) Multiple identity === | ||
| − | + | {{Need details}} | |
| + | |||
| + | You should be able to maintain multiple identities, and choose to link them or not. | ||
| − | |||
=== 10) Protocol agnostic === | === 10) Protocol agnostic === | ||
| − | + | {{Need details}} | |
| − | + | You should be able to cross-communicate with different protocols, be they XMPP, HTTP, or p2p based. | |
Again, this seems like an implementation detail. Interoperation between platforms or providers is presumably the goal here, not protocols for their own sake. | Again, this seems like an implementation detail. Interoperation between platforms or providers is presumably the goal here, not protocols for their own sake. | ||
| + | |||
=== 11) Secure groups === | === 11) Secure groups === | ||
| − | + | {{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. | as the group, because they share a private group-key. | ||
| − | + | 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's Annotations (XA) == | == lynX's Annotations (XA) == | ||
Derived from ES with the following annotations: | Derived from ES with the following annotations: | ||
| + | |||
=== 4) Scalability === | === 4) Scalability === | ||
Multicast strategies. Learn from Bittorrent. Try Gnunet Mesh. | Multicast strategies. Learn from Bittorrent. Try Gnunet Mesh. | ||
| + | |||
=== 5) Integration of old friends on legacy networks === | === 5) Integration of old friends on legacy networks === | ||
| Line 104: | Line 130: | ||
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. | 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. | ||
| + | |||
=== 8) Client choice === | === 8) Client choice === | ||
| Line 110: | Line 137: | ||
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. | 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. | ||
| + | |||
=== 10) Protocol agnostic === | === 10) Protocol agnostic === | ||
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. | 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. | ||
Revision as of 12:56, 5 August 2013
Contents
-
1 Socialnet_3.0
- 1.1 Klaus' Proposal (KS)
-
1.2 Elijah's Proposal (ES)
- 1.2.1 1) Client side encryption
- 1.2.2 2) Social graph obfuscation
- 1.2.3 3) Self determined data storage
- 1.2.4 4) Scalability
- 1.2.5 5) Integration of old friends on legacy networks
- 1.2.6 6) High availability
- 1.2.7 7) Device portability
- 1.2.8 8) Client choice
- 1.2.9 9) Multiple identity
- 1.2.10 10) Protocol agnostic
- 1.2.11 11) Secure groups
- 1.3 lynX's Annotations (XA)
Socialnet_3.0
Preparing Berlin's workshop, August 24-25 2013.
The objective of this page is to come up with a short list of objectives we all share, and identify issues.
Klaus' Proposal (KS)
1) End-to-end encryption
End-to-end encryption whenever I share information with friends - that will be realised by secushare.org
2) Self determined storage
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).
3) A migration strategy
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.
Elijah's Proposal (ES)
1) Client side encryption
Covers KS#1.
2) Social graph obfuscation
3) Self determined data storage
Covers KS#2. See OwnCloud, GNUnet, RetroShare.
4) Scalability
5) Integration of old friends on legacy networks
(which would compromise 1 and 2 for those, of course). Covers KS#3.
- Option #1: keep bridges with legacy infrastructure
- Option #2: abandon legacy infrastructure
In any case, a migration strategy is needed in the meantime.
6) High availability
You should be able to access your data when you want it.
7) Device portability
You should be able to access your data from multiple devices at the same time
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
You should be able to use a mobile, desktop, or html5 app client (once webcrypto is deployed in browsers).
You should have a choice of clients, but html5 is an implementation detail - we should agree on principles at this stage, not implementation details.
9) Multiple identity
You should be able to maintain multiple identities, and choose to link them or not.
10) Protocol agnostic
You should be able to cross-communicate with different protocols, be they XMPP, HTTP, or p2p based.
Again, this seems like an implementation detail. Interoperation between platforms or providers is presumably the goal here, not protocols for their own sake.
11) 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.
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's Annotations (XA)
Derived from ES with the following annotations:
4) Scalability
Multicast strategies. Learn from Bittorrent. Try Gnunet Mesh.
5) Integration of old friends on legacy networks
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.
8) Client choice
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.
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.
10) Protocol agnostic
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.
