[foaf-protocols] I had a crazy idea

Dan Brickley danbri at danbri.org
Mon May 17 12:16:04 CEST 2010

+cc: foaf-protocols (feel free to drop the cc later in thread, just
wanted to link the conversations)

On Sat, Apr 17, 2010 at 2:02 AM, Evan Prodromou
<evan.prodromou at gmail.com> wrote:
> So, one of the things we don't have in OStatus is privacy. Your
> updates that go out are visible to the entire world. For some people,
> that's not acceptable.
> I had a crazy idea of how we could handle this.
> For status updates that are "private", we could use encryption. Since
> we have RSA keys for every OStatus participant (we need 'em for
> Salmon), we could do the same little trick that PGP does. That is, we
> encrypt the notice with a one-time key, and then encrypt that key for
> the keys of each follower.
> So the outgoing atom entry would have something like:
> <content type="application/rsa-encrypted-blob">
> bzzzztttt bbzzzzzzzt line noise bzzzzttt phhhptttttt
> </content>
> <ostatus:key for="evan at status.net">morelinenoise</ostatus:key>
> <ostatus:key for="james at status.net">bbzzzzttttpphhhh</ostatus:key>
> There are a few problems with this. First, if you have a million
> followers, it's going to be a REALLY big message.
> Second, it's exposing all your followers to each other. I don't know
> if that'd be a requirement of privacy, but it's at least interesting.
> Anyways, wanted to get that out.

Interesting. I hadn't noticed RSA in Salmon.

There were some similar experiments in the FOAF community a while
back, eg. see Edd Dumbill's writeup from ~2002:


"""Next, sign and encrypt the private file with GPG, giving the key ID
with the -r option:

  gpg -sea -r 6C7F734E foaf-private.rdf
This should create a foaf-private.rdf.asc file, or something named similarly.

Finally, you need to link in the new file from your existing FOAF
file. If you've read Adding people into the FOAF web, you will be
familiar with the rdfs:seeAlso way of linking files. We just use the
same mechanism, but adding some properties to describe the encryption.

Don't forget to declare the wot namespace in your FOAF file:

And then add the link:

 <!-- private info for authorized agents only -->
       <!-- encrypted for the #foaf community -->
         <wot:PubKey wot:hex_id="6C7F734E" />
Add this fragment into your original FOAF file, and republish (don't
forget to re-sign!)"""

We never got beyond proof of concept with this stuff since it relied
on users/publishers (a) understanding PGP's pubkey model (b)
remembering how to use the PGP/GPG tools, (c) manually doing a lot of
publishing. Perhaps Salmon and OStatus gets around much of this.

Which leaves us with the problem of explicitly enumerating the keys of
every one in the 'permitted readers' group. When we looked at this for
FOAF I wasn't sure whether it was a bug or a feature, but if for eg. I
wanted to encrypt some data for "W3C Staff readers only", I would've
had to explicitly enumerate all the staff. And they change over time
(eg. I'm no longer W3C staff :). I lean towards seeing that as a
feature rather than bug actually.

The other aspect of this you mention is that people who want to
encrypt to millions of followers. Since effective privacy of
information drops with every new legitimate reader you add, by the
time you get past 100 or 1000 recipients (still small list compared to
millions), the information is coming close to being public. I don't
know what the largest plausible non-public group of people is;
http://en.wikipedia.org/wiki/Indian_Railways have 1.6 million
employees, but maybe don't need to send non-public memos to them all.
Stephen Fry has a comparable number of followers on twitter, and
probably similar lack of need for intimacy with them. Perhaps you
could pick a cut off and say "above that, it's effectively public, so
we'll use a special key for 'everyone'"?

Not sure where I'm going with this, but it's an interesting topic to revisit...



More information about the foaf-protocols mailing list