[foaf-dev] beyond foaf:mbox_sha1sum

Melvin Carvalho melvincarvalho at gmail.com
Mon Dec 21 15:22:18 CET 2009

On Sat, Dec 19, 2009 at 3:42 PM, Dan Brickley <danbri at danbri.org> wrote:

> 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

I think next generation FOAFs will have better access control over
foaf:mbox, possibly utilizing the MVC pattern, read/write options
(SPARUL/WebDAV) and/or FOAF authentication (SSL/OpenID/password/etc.)

I see three options for ACL based on WebAccessControl [1]

1. Algorithmically

Decide which options you wish to display to the user based on what you know
about them.  Then program a filter to show them these options.  This could
take the form of a SPARQL CONSTRUCT method, or a more complex algorithm

- Rapid deployment
- High Control

- Requires Controller class
- Implementation specific

2. Named Graphs

Apply the web access control vocab to named graphs.  Splitting your FOAF up
into several segments, each with a given name, you can then smush them
together based on the web access control vocab, and display to the given
user.  This is perhaps a use case that named graphs were designed to solve
and some quad stores may provide functionality to help.

- Requires no new vocabs/techniques
- Some quad stores will have named graph functionality built in

- Quad store specific
- Added complexity if breaking up and naming FOAF graphs

3.  ACLStatement

This is my own personal proposal.  I merely want to add this as an option,
so that it's possible to remain within the subject predicate object paradigm
for those that wish to do so.

The idea is to add a class ACLStatement to the web access control vocab.
This is modeled in a similar fashion to a Talis Changelist [2] to include
rdf:subject and rdf:predicate as inputs to a web access control group and
action (read/write/control).  Thus, maintaining a FOAF file which also
contains the rules by which it can display itself

- Portable (remains withing subject predicate object paradigm)
- High level of granularity

- Requires Controller class
- The reification style is an historically unpopular technique

I'd argue that all three techniques are valid, however I'm, right now
leaning towards (3) as a technique that give you a lot of options, and I'd
argue that the advantages outweigh the disadvantages.  If there's not too
much objections, I'd propose moving towards working this structure into [1],
rather than creating a vocab locally for it.  I think over time, in this
way, FOAFs can become more dynamic entities, which will allow us to leverage
the full power of LOD and the Sem Web.

[1] http://esw.w3.org/topic/WebAccessControl
[2] http://n2.talis.com/wiki/Changesets

> cheers,
> Dan
> _______________________________________________
> foaf-dev mailing list
> foaf-dev at lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-dev/attachments/20091221/53aa8c56/attachment.htm 

More information about the foaf-dev mailing list