Talk:On Presence updates/User Profiles/Collaboration: Difference between revisions
(Privacy) |
(Scalability) |
||
| Line 6: | Line 6: | ||
I appreciate that on a mesh network, every node can be a router, and the routing protocol may require that every router know the source and/or destination. However, that data will be encrypted, and so it will be impossible to identify it without traffic analysis. Requiring a malicious eavesdropper to perform traffic analysis of encrypted streams seems a reasonable bar to set for privacy. [[User:Bemasc|Ben]] 11:40, 29 April 2008 (EDT) |
I appreciate that on a mesh network, every node can be a router, and the routing protocol may require that every router know the source and/or destination. However, that data will be encrypted, and so it will be impossible to identify it without traffic analysis. Requiring a malicious eavesdropper to perform traffic analysis of encrypted streams seems a reasonable bar to set for privacy. [[User:Bemasc|Ben]] 11:40, 29 April 2008 (EDT) |
||
== Scalability == |
|||
You note that the broadcast approach provides n^2 scalability, which improves to near-linear in a dense mesh. However, as you have noted, meshes have fundamental scaling limits. In particular, I have never seen a proposal for mesh routing that does not require each node to maintain memory at least linear in the number of nodes. Thus, we may expect that the internet will not be using a mesh routing approach any time soon. On a wired network, the scaling behavior is again n^2, and wired networks are where the largest n is likely to occur. |
|||
We can do better than n^2 using server-based caching, like Daf's [[Gadget]]. Support for this should not be an afterthought. [[User:Bemasc|Ben]] 11:49, 29 April 2008 (EDT) |
|||
Revision as of 15:49, 29 April 2008
Privacy
I would argue strongly that the list of activities in which I am participating is private. You wouldn't want your IRC client telling me what other applications you're running. The Sugar design calls for implementation of sharing Activities that are only visible to a specific group, where each group corresponds to a single unique keypair.
One possible way of implementing this is to set up a distinct, parallel presence system for each group. Offhand, I cannot think of any acceptably efficient way of implementing this design, especially since every non-public activity generates a new group. Instead, we may encrypt each entry in the list of shared activities with the private key of the group that has permission to join it. With this system, I can tell whether two people are in the same activity, but I cannot tell what activity it is. To improve privacy further, we may pad out each Activity entry to a fixed length with random data before encryption, so that two people joined to the same activity show different entries in their presence data.
I appreciate that on a mesh network, every node can be a router, and the routing protocol may require that every router know the source and/or destination. However, that data will be encrypted, and so it will be impossible to identify it without traffic analysis. Requiring a malicious eavesdropper to perform traffic analysis of encrypted streams seems a reasonable bar to set for privacy. Ben 11:40, 29 April 2008 (EDT)
Scalability
You note that the broadcast approach provides n^2 scalability, which improves to near-linear in a dense mesh. However, as you have noted, meshes have fundamental scaling limits. In particular, I have never seen a proposal for mesh routing that does not require each node to maintain memory at least linear in the number of nodes. Thus, we may expect that the internet will not be using a mesh routing approach any time soon. On a wired network, the scaling behavior is again n^2, and wired networks are where the largest n is likely to occur.
We can do better than n^2 using server-based caching, like Daf's Gadget. Support for this should not be an afterthought. Ben 11:49, 29 April 2008 (EDT)