[foaf-protocols] I had a crazy idea
nathan at webr3.org
Mon May 17 20:06:55 CEST 2010
Dan Brickley wrote:
> +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
>> <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...
I've been thinking along the same lines, especially with the advent of
foaf+ssl - thus have started pushing for a bit JS crypto support in by
the UA vendors:
Interesting approach above, will give it some thought,
More information about the foaf-protocols