[foaf-dev] beyond foaf:mbox_sha1sum

Dan Brickley danbri at danbri.org
Sat Dec 19 15:42:54 CET 2009


Time to gently retire it?
http://ebiquity.umbc.edu/blogger/2009/12/17/foafmbox_sha1sum-considered-harmful/
etc

We introduced it as an alternative to making our email addresses
completely public; however it drifted into use as an alternative to
them being fully private.

The main advantage it has over URIs for people, weblogs, homepages,
openids etc is that it can be used to match up against people
information where the only identifier is an email address (mailing
lists, folders etc.). While this can be pretty useful in some
contexts, it doesn't justify encouraging social network sites to
expose it publically for each user. These days, mechanisms like OAuth
allow downstream apps to negotiate (with user permission) access to
closed data like full email addresses. OpenID AX, FOAF+SSL, XMPP and
other mechanism are also promising. I think hashed mailboxes may serve
some role in those contexts, where we might semi-trust some unknown
app but might want an extra layer of obfuscation. However it is very
difficult to communicate the risks and issues to non-technical users;
eg. by explaining the nature of sha1 hashes, rainbox tables
(http://en.wikipedia.org/wiki/Rainbow_table), or the probabilities
associated with dictionary attacks using common names / syntax and
domain names. Email addresses are concentrated these days on a number
of domains (google mail; hotmail etc), and it's a mistake to think of
mbox_sha1sum as any kind of strong protection.

Thoughts on ways forward?

1. mark foaf:mbox_sha1sum as archaic
2. rewrite http://xmlns.com/foaf/spec/#term_mbox_sha1sum to more
clearly emphasise the risks, and that decision to publish shouldn't be
made for others
3. perhaps remove the owl:InverseFunctionalProperty typing (this will
help with OWL DL compatibility too)
4. encourage data publishers to assign URIs to account holders
directly, to indicate openID URIs and other identifying properties as
users permit

cheers,

Dan


More information about the foaf-dev mailing list