Re: [Social-discuss] Announcing P2P GNU Social

[B. Kip]

Still trying to understand this in detail:

On Sat, Jul 10, 2010 at 9:46 PM, Blaine Cook <address@hidden> 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*.

 

From: GNU social - Privatemessaging - Open wiki - Gitorious
http://gitorious.org/social/pages/Privatemessaging:

• If Bob hasn’t authenticated against Alice’s server, then Bob’s server goes through the Webfinger auth process, generating a shared secret. If he already has, he’ll already have such a secret.
  
• Bob’s server uses the shared secret from the Webfinger auth process to retrieve Alice’s message.

So, as I understand it, this shared secret is simply a way of ensuring that Bob is really Bob and Alice is really Alice, and that they know eachother, not a key that is used to encrypt messages between Alice and Bob- correct?

If you go this far why not take the extra step of encryption?  Is that a whole lot more complicated to do?  What process are you using to authenticate?  Are you making use of public keys shared through Webfinger?

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?

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.