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 19:11:05 -0400

On Sat, 2010-07-10 at 13:46 +0100, 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*.
> 
We haven't thought about that a lot, but you're definitely right as far
as human-level usability goes. I want to depend on DNS as little as
possible, however, for reasons that should be obvious given recent
events[1].

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

Well, from my point of view, data you've shared with others *is* public.
This is the best we can do without some form of DRM. However, this
approach only requires that you trust people who you already view as
your friends. 

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

Monkeysphere is something I've been looking at (and would be interested
in seeing integrated with this project); I'm not sure how much can be
gained from RedPhone, though (isn't it proprietary/mostly secret? Where
is the documentation? I know it uses ZRTP, but not much more than that).
As for VIPR, it's not very google-able. Do you mean this:
<http://www.aastraintecom.com/cps/rde/xchg/30/hs.xsl/28584.htm>?

[1]
http://torrentfreak.com/pirate-bay-and-megaupload-escape-domain-seizure-by-us-100707/

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


reply via email to

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