Announcing P2P GNU Social

[Ted Smith]

For the past few weeks, Miron Cuperman and I have been thinking about
how to do social networking in a p2p and privacy-enhanced way. We've
come up with some code and documents that describe a distributed social
networking system that is able to make and enforce strong guarantees
about user privacy while still providing usability in the same vein as
traditional, centralized or hub-and-spoke services. We've collected this
into an effort to build a P2P GNU Social.

The GNU Social P2P effort attempts to create a distributed,
privacy-enhanced and privacy-enforcing, user-controlled social network.
The goals of the P2P effort include:

* User Control - The user can run their own node on their own machine
with maximal ease of use and maintenance - it shouldn't take a sysadmin
to be social
* Privacy controls are not merely stated, but are enforced by strong
cryptography and time-tested protocols. All user data, including the
social graph, is private by default.
* Transparent developer access to other social networking systems,
including OStatus - the modular transport/translation system of the P2P
GNU Social will ensure that from the point of view of the end-user and
developer, there is only One Big Network.
* Modularity - Components in the node stack should be separated such
that it is simple to add and remove components. A full, working GNU
Social P2P node will be composed of several different individual
programs, and several different user interfaces. A strong client-side
API should enable developers to integrate P2P GNU Social into all
relevant existing desktop applications. Some of you may remember this
design from the document I posted to this list some months ago[1].
* Composition - Whenever possible, P2P GNU Social will borrow/loot from
existing Free protocols and implementations, though all code written by
us will be licensed under the AGPL.

To learn more about the P2P GNU Social design and structure, visit
<http://groups.fsf.org/wiki/Group:GNU_Social/P2P>. Currently, we have a
prototype for the GNU Social "core", written in Java, hosted on
Gitorious here: <http://gitorious.org/social-p2p/core>. We also have our
own mailing list at <http://lists.gnu.org/mailman/listinfo/social-p2p>
and an IRC channel at <irc://irc.freenode.net/social-p2p>.

We need people to help make this system a reality, by hacking on it and
fleshing out the protocol. Some things that people could get started
with include transport layers or translators for pre-existing networks,
and building user interfaces, ranging from a basic prototype to
integration with existing "social desktop" initiatives and mobile
devices.

We'd like to emphasize that this is **NOT** a fork of the mainline GNU
Social. StatusNet GNU Social and P2P GNU Social fulfill different niches
in the social networking space and should interoperate fully. If you
have to choose on one implementation to work on, it's probably better
for you to work on StatusNet GNU Social - there's more maturity and
it'll be possible to create free social networking systems faster. We
expect that P2P GNU Social will be more of a "research" effort - a
vanguard into privacy-enhanced social networking - which other social
networking systems, including and especially StatusNet GNU Social, will
be able to learn and build from. We have signed copyright assignment
papers with the FSF and expect contributors to do so as well.

We hope that many of the questions people have about how the network
works and how it guarantees privacy can be answered by our design
documents on groups.fsf.org, but please feel free to ask further
questions.

[1] http://groups.fsf.org/wiki/Group:GNU_Social/P2P/Node_Architecture

[B. Kip]

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 :-)

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?

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?

3. If the answer to no.2 is 'yes', what then are the main privacy
implications of differences in implementation?

Brad

Post by Ted Smith
For the past few weeks, Miron Cuperman and I have been thinking about
how to do social networking in a p2p and privacy-enhanced way. We've
come up with some code and documents that describe a distributed social
networking system that is able to make and enforce strong guarantees
about user privacy while still providing usability in the same vein as
traditional, centralized or hub-and-spoke services. We've collected this
into an effort to build a P2P GNU Social.
The GNU Social P2P effort attempts to create a distributed,
privacy-enhanced and privacy-enforcing, user-controlled social network.
* User Control - The user can run their own node on their own machine
with maximal ease of use and maintenance - it shouldn't take a sysadmin
to be social
* Privacy controls are not merely stated, but are enforced by strong
cryptography and time-tested protocols. All user data, including the
social graph, is private by default.
* Transparent developer access to other social networking systems,
including OStatus - the modular transport/translation system of the P2P
GNU Social will ensure that from the point of view of the end-user and
developer, there is only One Big Network.
* Modularity - Components in the node stack should be separated such
that it is simple to add and remove components. A full, working GNU
Social P2P node will be composed of several different individual
programs, and several different user interfaces. A strong client-side
API should enable developers to integrate P2P GNU Social into all
relevant existing desktop applications. Some of you may remember this
design from the document I posted to this list some months ago[1].
* Composition - Whenever possible, P2P GNU Social will borrow/loot from
existing Free protocols and implementations, though all code written by
us will be licensed under the AGPL.
To learn more about the P2P GNU Social design and structure, visit
<http://groups.fsf.org/wiki/Group:GNU_Social/P2P>. Currently, we have a
prototype for the GNU Social "core", written in Java, hosted on
Gitorious here: <http://gitorious.org/social-p2p/core>. We also have our
own mailing list at <http://lists.gnu.org/mailman/listinfo/social-p2p>
and an IRC channel at <irc://irc.freenode.net/social-p2p>.
We need people to help make this system a reality, by hacking on it and
fleshing out the protocol. Some things that people could get started
with include transport layers or translators for pre-existing networks,
and building user interfaces, ranging from a basic prototype to
integration with existing "social desktop" initiatives and mobile
devices.
We'd like to emphasize that this is **NOT** a fork of the mainline GNU
Social. StatusNet GNU Social and P2P GNU Social fulfill different niches
in the social networking space and should interoperate fully. If you
have to choose on one implementation to work on, it's probably better
for you to work on StatusNet GNU Social - there's more maturity and
it'll be possible to create free social networking systems faster. We
expect that P2P GNU Social will be more of a "research" effort - a
vanguard into privacy-enhanced social networking - which other social
networking systems, including and especially StatusNet GNU Social, will
be able to learn and build from. We have signed copyright assignment
papers with the FSF and expect contributors to do so as well.
We hope that many of the questions people have about how the network
works and how it guarantees privacy can be answered by our design
documents on groups.fsf.org, but please feel free to ask further
questions.
[1] http://groups.fsf.org/wiki/Group:GNU_Social/P2P/Node_Architecture

[Ted Smith]

(I think this only needs to be on one mailing list, so I removed

Post by B. Kip
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 :-)

Post by B. Kip
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.

Post by B. Kip
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.

Post by B. Kip
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.

[Blaine Cook]

Post by Ted Smith
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*.

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.

[Miron Cuperman]

Post by Blaine Cook

Post by Ted Smith
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
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
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.

Post by Blaine Cook
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.

Post by Blaine Cook
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.

[Ted Smith]

Post by Blaine Cook

Post by Ted Smith
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
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
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].

Post by Blaine Cook
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.

Post by Blaine Cook
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/

[B. Kip]

Post by Blaine Cook

Post by Ted Smith
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
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
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

Post by Blaine Cook
- 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?

Post by Blaine Cook
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.

[Ted Smith]

Post by Ted Smith

Post by Ted Smith
It means that if your server (to be precise, your
core) is cracked, or subpoenaed by the MAFIAA/ACTA-Empowered

Sharing

Post by Ted Smith
Police, it can give up no data that you haven't already

decided is

Post by Ted Smith
public.
I don't think that StatusNet GNU Social makes that

guarantee, even when

Post by Ted Smith
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
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
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
* 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.

Post by Ted Smith
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.

[Melvin Carvalho]

Post by Ted Smith

Post by Ted Smith

Post by Ted Smith
It means that if your server (to be precise, your
core) is cracked, or subpoenaed by the MAFIAA/ACTA-Empowered

Sharing

Post by Ted Smith
Police, it can give up no data that you haven't already

decided is

Post by Ted Smith
public.
I don't think that StatusNet GNU Social makes that

guarantee, even when

Post by Ted Smith
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
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
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
* 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.

Post by Ted Smith
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.

Yeah, nice. I've often thought person to person sharing can be encrypted
simply using the next party's public key (GPG or X.509)

For group sharing you can add another optimization of a group sharing an aes
256 key. Of course you're only as strong as your weakest link, but it's a
good start.

With FOAF it's pretty easy to associate a public key with a profile (a few
lines of cut and paste) which is also the basis/simplicity of FOAF+SSL

The elegance of this system is that to get a user's public key, you just
need to lookup the webpage, which is something that's almost trivial to do.


With webfinger it's a bit harder to get information out of the email
address, you'd normally have to deploy a server to specially do this. It's
always nice to be able to get new information from an identifier, IMHO it's
an unnecessary step, but i dont have a huge issue with people that want to
do this, and can see it's necessary for many of the large webmail providers
to finally get into the interop game.

Post by Ted Smith
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.

[Ted Smith]

Post by Ted Smith

On Sat, Jul 10, 2010 at 9:46 PM, Blaine Cook

Post by Ted Smith
It means that if your server (to be precise, your
core) is cracked, or subpoenaed by the

MAFIAA/ACTA-Empowered

Sharing

Post by Ted Smith
Police, it can give up no data that you haven't

already

decided is

Post by Ted Smith
public.
I don't think that StatusNet GNU Social makes that

guarantee, even when

Post by Ted Smith
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
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

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
* 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.
Yeah, nice. I've often thought person to person sharing can be
encrypted simply using the next party's public key (GPG or X.509)
For group sharing you can add another optimization of a group sharing
an aes 256 key. Of course you're only as strong as your weakest link,
but it's a good start.

We get this for free with OpenPGP. It encrypts the data with a symmetric
cipher, and encrypts the key for that with the asymmetric cipher.

Post by Ted Smith
With FOAF it's pretty easy to associate a public key with a profile (a
few lines of cut and paste) which is also the basis/simplicity of FOAF
+SSL
The elegance of this system is that to get a user's public key, you
just need to lookup the webpage, which is something that's almost
trivial to do.
With webfinger it's a bit harder to get information out of the email
address, you'd normally have to deploy a server to specially do this.
It's always nice to be able to get new information from an identifier,
IMHO it's an unnecessary step, but i dont have a huge issue with
people that want to do this, and can see it's necessary for many of
the large webmail providers to finally get into the interop game.

You'd have to set up a server to get information out of FOAF, right? You
need some way to download the information. Webfinger only involves
webpage lookups.

[B. Kip]

Post by Ted Smith

Post by Ted Smith

Post by Ted Smith
It means that if your server (to be precise, your
core) is cracked, or subpoenaed by the MAFIAA/ACTA-Empowered

Sharing

Post by Ted Smith
Police, it can give up no data that you haven't already

decided is

Post by Ted Smith
public.
I don't think that StatusNet GNU Social makes that

guarantee, even when

Post by Ted Smith
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
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
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
* 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.

Post by Ted Smith
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.

Thanks. I meant the question to be about Statusnet GNU Social, but I think
I understand your point: If encryption were included in Statusnet GNU
Social it would take place on the server, so your private key would live
there as well. Unless you were running the instance yourself, there would
be no benefit to be had by encrypting.

Is Statusnet GNU Social designed in such a way that a browser plug-in or
standalone application could be used to interact with it? Could this be
used to as a way to implement public key encryption at the local device
level (PC, phone, whatever) while still having a hosted user account?

[Ted Smith]

Post by Ted Smith

On Sat, Jul 10, 2010 at 9:46 PM, Blaine Cook

Post by Ted Smith
It means that if your server (to be precise, your
core) is cracked, or subpoenaed by the

MAFIAA/ACTA-Empowered

Sharing

Post by Ted Smith
Police, it can give up no data that you haven't

already

decided is

Post by Ted Smith
public.
I don't think that StatusNet GNU Social makes that

guarantee, even when

Post by Ted Smith
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
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

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
* 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.
Thanks. I meant the question to be about Statusnet GNU Social, but I
think I understand your point: If encryption were included in
Statusnet GNU Social it would take place on the server, so your
private key would live there as well. Unless you were running the
instance yourself, there would be no benefit to be had by encrypting.
Is Statusnet GNU Social designed in such a way that a browser plug-in
or standalone application could be used to interact with it? Could
this be used to as a way to implement public key encryption at the
local device level (PC, phone, whatever) while still having a hosted
user account?

If you did that, you'd have P2P GNU Social. The UI is the browser plugin
or standalone application, and the core is what hosts your data and does
routing. Even if you ran your own core, and it was subject to the same
"churn" pattern (of uptime and downtime) as your UI, most of your data
should be mirrored - even your private data can be mirrored, because it
is protected by strong cryptography and it will only be decrypted on a
CPU you control (assuming you're picking your CPUs wisely).

Ideally, it won't be difficult to migrate from StatusNet GNU Social to
P2P GNU Social - it would just be an interface change. Most ideally, it
would mean installing a plugin.

[Eduardo Lima Mitev]

Post by Ted Smith
For the past few weeks, Miron Cuperman and I have been thinking about
how to do social networking in a p2p and privacy-enhanced way. We've
come up with some code and documents that describe a distributed social
networking system that is able to make and enforce strong guarantees
about user privacy while still providing usability in the same vein as
traditional, centralized or hub-and-spoke services. We've collected this
into an effort to build a P2P GNU Social.
[...]
[1] http://groups.fsf.org/wiki/Group:GNU_Social/P2P/Node_Architecture

Hi Ted,

What is the status of this initiative?
Are you still working on it?
Where can I find the wiki pages and the repo that apparently were moved
out from the wiki?

thanks and cheers,
Edu

[Ted Smith]

Post by B. Kip

Post by Ted Smith
For the past few weeks, Miron Cuperman and I have been thinking about
how to do social networking in a p2p and privacy-enhanced way. We've
come up with some code and documents that describe a distributed social
networking system that is able to make and enforce strong guarantees
about user privacy while still providing usability in the same vein as
traditional, centralized or hub-and-spoke services. We've collected this
into an effort to build a P2P GNU Social.
[...]
[1] http://groups.fsf.org/wiki/Group:GNU_Social/P2P/Node_Architecture

Hi Ted,
What is the status of this initiative?
Are you still working on it?
Where can I find the wiki pages and the repo that apparently were moved
out from the wiki?
thanks and cheers,
Edu

groups.fsf.org/wiki/Group:GNU_Social redirects to gnu.org now, so we
moved the wiki out to this page:

<http://groups.fsf.org/wiki/Group:GNU_Social_P2P>

All of the information on social-p2p should be there now.