social-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Social-discuss] Announcing P2P GNU Social


From: Ted Smith
Subject: Re: [Social-discuss] Announcing P2P GNU Social
Date: Sat, 10 Jul 2010 08:26:58 -0400

(I think this only needs to be on one mailing list, so I removed
address@hidden)

On Sat, 2010-07-10 at 13:29 +0900, B. Kip wrote:
> Hi Ted,
> 
> I've read through the documents you linked below, but my technical
> understanding is thin and I'm still trying to wrap my brain around the
> issues involved in doing privacy on a  social network, so please bear
> with me :-)
> 
Okay :-)

> I have three questions:
> 
> 1. I was wondering why you are taking the approach of combining the
> storage and routing functions into a single core application.  In my
> own imagining about how this might work I was thinking that having the
> UI, storage (which could be physically fragmented), and routing as
> independent functions would allow for the most flexibility in
> configuring the network.  If these functions were all allowed to work
> independently, it wouldn't matter how they were packaged- they could
> all be combined into a single desktop app in one instance, and all be
> on different machines in different places installed and maintained by
> different people in another.  Since end-to-end encryption would allow
> the user to control all access to data, it shouldn't matter where any
> functions outside of the UI itself took place.  Is there a particular
> reason why you are combining them?
> 
The short answer is that we aren't. You're right that using crypto
allows the user to control access to their data, no matter where it
lives - so one of the main features of the core will be mirroring the
data of other users.

The end goal is to do both routing and storage via a small-world
network, exploiting the fact that friends will probably be willing to
share computing resources with each other.

> 2. I'm also trying to understand the differences between the P2P GNU
> Social and Main GNU Social approaches to privacy.  I've read the
> Private Messaging Plugin description for GNU Social.  With respect to
> objectives- not implementation- as far as I can understand the main
> difference between the approaches is that P2P GNU Social works to
> privatize the social graph (connections between users) in addition to
> the content, while GNU Social only secures the content itself.  Both
> would keep content data encrypted end-to-end, provided it was
> encrypted at the origin.  So the most significant privacy difference
> (in terms of objective) between the two systems is exposure of the
> social graph.  Is this understanding correct?  

Half. Probably the most important feature is safeguarding the social
graph. 
> 3. If the answer to no.2 is 'yes', what then are the main privacy
> implications of differences in implementation?

The main difference is that while privacy is enforced by policy in
StatusNet/Mainline GNU Social (and in Facebook, and in basically every
social networking system, at least every one I've ever seen), privacy is
enforced by design in social-p2p. 

This means that rather than a check to see if a user is authenticated to
receive a private message, we can just send the private message and if
the user is lying about who they are, they'll get undecryptable
ciphertext. It also means that we safeguard the social graph, and not
just by not allowing people to see who's friends with whom, the way
early Facebook did (securing the social graph for everyone who doesn't
work at Facebook, at least), but by using time-tested anonymity
protocols to ensure that our security is at least as good as these
pre-existing systems. It means that if your server (to be precise, your
core) is cracked, or subpoenaed by the MAFIAA/ACTA-Empowered Sharing
Police, it can give up no data that you haven't already decided is
public. 

I don't think that StatusNet GNU Social makes that guarantee, even when
it comes to private messaging. I would be very happy to be wrong.

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]