FOAF Spheres of Privacy

Joseph Reagle

So many social network communities have recently been announced (e.g., sixdegrees,Friendster,, Ryze, LinkedIn, EveryOnesConnected, and Friends Reunited) that a special abbreviation has been coined in response: "YASN", yet another social network. However, these communities typically lack two, much discussed, features: expansion (interoperability) and segmentation (filters).

The information that makes up these networks are proprietary and each community hopes to take advantage of the obvious market benefits gained from combining a proprietary network with first-mover advantage. Of course, this is also inconvenient to a user who may have friends on different networks. Consequently, if such information was transparent and interoperable, one's network would be seamless and expansive. But of course, with expansion comes overload. We then need mechanisms to distinguish a good friend from a business associate, or other acquaintance.

An alternative to the above social networks is FOAF (Friend of a Friend). It's based on an open Web data format (RDF/XML), so just like one's home page it's decentralized and very extensible. However, as I discussed a few years ago with Dan Brickley, the privacy implications of its openness are all the more severe. While my profile and friends are in someway limited to the gated community of one the services above, in FOAF my information is available to the whole world. This essay briefly proposes a method of granting more control to the social networks one maintains in FOAF.

Web of Trust

A well known feature of the decentralized security application PGP was that one did not have to rely upon heirchical and bureaucratic relationships between any two parties. Instead, I would sign the key of my friends. For example, I've exchanged and signed keys with my longstanding friend Alice. Consequently, if we send a signed email to each other, we need only check that the key we once proved to ourselves as belonging to the other (via signing the key), is the same key used in the most recent message. Now, if Alice's friend, Bob, wants to communicate securely with me, I need only check that Alice signed Bob's key. In this way, Alice is acting as an "introducer", and I can set a value of how trustworthy some of my friends are for introducing me to others, and a threshold for how many links in a chain of introduction I'm willing to accept.

As Barabási wrote about in Linked: The New Science of Network,much like the organization of the Web or even our social relationships (e.g., all of the social services above), one is very often quite "close" (e.g., 6 degrees of Kevin Bacon) to others. It is not that difficult to build a very large (many nodes) but intimate (few hops between nodes) network.

Threshold Schemes

A novel cryptographic tool is that one can often distribute a single key amongst a cadre of associates. For instance, for backup/escrow purposes, I might distribute the key I use to protect my various papers and notes to five of my closest friends. In the event of my death, I could construct the key such that it would take 3 out of the 5 of my friends to reconstruct the key and render my work to posterity. I might fear that one or two of them alone might try to cheat and expose my embarrassing emails to the world while I'm still alive, but 3 of them would never do such a thing.

Spheres of Privacy

With an understanding of the need for distinguishing relationships, and decentralized and threshold based trust, I offer a tentative proposal.

As already proposed, FOAF could be extended to support digital signature and a Web of trust for validating the information found.

One's personal information could be segmented and made available to spheres of peers. For example, I might be willing to publish my name and homepage to the world, but if you want my email address (in order to foil spammers) you need the secret key in order to access that information. That portion of my profile as described in XML Encryption Section 2.2, has been secured by an EncryptedData element.

<foaf:Person xmlns:foaf="">
  <foaf:name>Joseph Reagle</foaf:name>
  <foaf:homepage rdf:resource="" />
  <EncryptedData Id='Profile' Type=''
    <ds:KeyInfo xmlns:ds=''>
      <ds:KeyName>Joseph's Profile Key</ds:KeyName>

To find my email address, you need to know my profile key, which has has been entrusted to five of my closest friends via a threshold introducer key. Here is one such key:

<ds:KeyInfo xmlns:ds=''>
  <ds:KeyName>The Second Introducer Key</ds:KeyName>

This introducer key sits in a secured portion of my friend's profile. The simplest approach is for my friend to include it directly in with his secured profile such that if he's willing to release the information he considers non-public to someone, then he's also released a third of the information necessary to get my profile key and email address. In effect, if 3 out of 5 of my friends are willing to share their semi-private information (e.g., email address) to someone, they can then also get my email address.

Future Issues