Re: [Social-discuss] Announcing P2P GNU Social

[Miron Cuperman]

On 07/10/2010 05:46 AM, Blaine Cook wrote:
> On 10 July 2010 13:26, Ted Smith <address@hidden> wrote:
>   
>> 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.
>>     
> It doesn't, though servers are free to encrypt the data before and/or
> after it's sent. The same applies for email. Two thoughts:
>
> 1. I welcome experiments using P2P networks for social networks, but
> consider the human-level usability concerns. No matter what the
> underlying technology is, you need a human-level addressing system
> (the acid test for a good addressing scheme is the ability for one
> person to be able to write down on a scrap of paper an address at
> which someone else can contact them later). If you use webfinger (re:
> email-like addresses), you can maintain compatibility with mainline
> GNU Social, Status.net, Diaspora (i.e., OStatus), and Google Buzz
> while providing forwards-compatibility to stronger privacy-based
> networks*.
>   
Discovery and search are definitely critical components.  Webfinger is
fine as a legacy protocol for compatibility, but since it depends on DNS
it's not enough by itself for this particular effort.  A DHT type
solution, as you suggest, is a good match for the system.   It might be
interesting to extend the DHT concept with friend-to-friend routing.
> 2. Your threat model is incomplete. The data you've shared is private
> not until *you* decide it's public, but until *someone you've shared
> the data with* decides it's public (or is forced to make it public).
> It's certainly true that the approach you describe is *more* secure
> than the default approach, but it's important to remember that it's
> not *completely* secure. Another way to think about this issue is to
> consider what (deployment / payload) approaches provide strong
> security over the default (OStatus-esque) approach, providing a local
> maximum of utility AND security?
>   
We are focused on making things private by default and disclosure an
intentional action.  Of course, if you disclose something to a friend
who then posts it somewhere, all is lost.  But there's not much you can
do to protect against this particular threat, other than being careful
with your friends.  Encrypting it on disk and in transit means that you
won't experience unwanted disclosure without intentional malicious
action on the part of someone you trust.

I think that having an encrypted storage mechanism with no access to
plaintext ("Core"), plus a user-agent ("UI") that lives close to the
user gives the right balance between usability, including uptime, and
security.  If you have further ideas about this, I'd love to hear.

> b.
>
> * There are approaches to using DHTs and either webs-of-trust or
> bootstrapping methods to provide trusted DNS-independent lookups for
> email addresses (and other addresses). See VIPR, MonkeySphere, and
> RedPhone for ideas.
>   

-- 

Miron Cuperman

http://hyper.to/blog/link/category/the-new-web/reputations/

http://groups.fsf.org/wiki/User:Miron2