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: Sun, 11 Jul 2010 00:18:59 -0400

On Sun, 2010-07-11 at 11:21 +0900, B. Kip wrote:
> 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?

I believe that's correct. I'm not entirely sure what "the Webfinger auth
process" is here. A cursory look at Webfinger doesn't indicate what that
is. I assume it is something that Bob's server uses to prove that it
hosts Bob's account, at which point Alice's server sends Bob's server
the message.

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

There's not really any point of encryption if your key material is
stored on an untrusted server.

I'm not really sure if you're asking questions about Statusnet GNU
Social or P2P GNU Social, but in P2P GNU Social, there's no need for
authentication, because the messages are encrypted end-to-end. Like all
other content, Alice notifies Bob of a message, and Bob pulls the
message. If anyone else is scraping Alice's core and finds the URL that
Bob uses to pull Alice's message, they can have it - as long as the
protocols Alice and Bob picked to use in OpenPGP are secure (probably
RSA and AES), there is not much hope of that person obtaining the
message.

As for key sharing, that happens during friendship - if I'm friends with
Alice, I have her public key. Public keys are also public, so we can get
them however we want. I don't think we've thought about this
particularly hard.

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


reply via email to

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