[rdfweb-dev] FOAF & Privacy

Scott Northrop scott at dragonflylodge.org
Fri May 7 19:16:33 UTC 2004

B.K. DeLong wrote:

> In order to deal with privacy and trust, it looks like the master FOAF 
> file of any person needs to be encrypted with their public key - 
> provided they have one. There's too much information that could be 
> incredibly useful that the user needs to be able to set TRUST with 
> RELATIONSHIPS to share certain info. Not only with People....but with 
> Groups and potentially online accounts.


> So it's almost like we need some sort of Java application that manages 
> one's FOAF and has the ability to encrypt and decrypt based on the 
> user's private key

You've identified an excellent design goal for an application I think we 
absolutely need, but I'd suggest the actual design go in a different 
direction. :)  (For one thing, what happens when two disjoint groups 
have access to the same sensitive bit of your FOAF file?  Does it get 
encrypted twice with different keys?  With ten or twenty groups, does it 
get encrypted ten or twenty times?)

Access control on FOAF data will be required to greater or lesser degree 
for everyone.  Rather than encrypting the data and putting it out there 
for almost everyone to throw away, I suggest only giving the data to 
those who have permission to see it.  So instead of having a simple web 
server serving a simple file with really complex encryption to limit 
access, you have a smart server serving RDF triples with a simple 
public-key authentication/access control system to limit access.

Marc Canter wrote:

>I know that many here felt that FOAF was a persistent store of dynamic processes, agents and 'intelligent' that would then get used by other dynamic processes.  That kind of shook up my world, and made mne think "Gee how could we be so out of sync?"
>FOAF immediately seemed to me to be the world standard for "About Me" pages.  That's how I've always thought of it.  So getting PPD in there - was key.

I'm firmly in the "dynamic processes" camp.  I believe much of the data 
will be very dynamic, the users will have very active clients 
intermediating the data for them, and the transport that best serves 
both ends will allow fine-grained data access.  (More like SOAP, and 
less like getting/parsing a whole FOAF.txt to find where they keep their 
headshot.jpg.  Or, for that matter, getting and parsing a whole  
MeNowDocument.txt to find out what IRC channel they're on.)

There is a lot of great stuff that can happen for users before this 
becomes fully realized, and a static file is plenty good enough for the 
short and perhaps even medium term.  But things will be a lot harder in 
the future if the model is split now into "static" and "dynamic" 
portions -- the eventual system will be completely dynamic, and static 
files are the necessary, and completely laudable engineering compromise 
of today.

There will always be a need for a http-accessible "about me" page -- but 
I think it'll be dynamically generated from a triple store.

This is all, of course, just my view, and I in no way wish to step on 
any toes, or imply anything less than huge respect and thanks for all 
those who've actually done work here.  Huge.  Really big.  Superlative, 
to say the least.

I wrote some notes [<a 
href="http://www.dragonflylodge.org/foaf/dns4people.html">1</a>] on 
this, which lots of people read and nobody commented on.  If you have a 
moment and some spare generosity, I'd love to know if YOU (yes you, 
there at the keyboard, with the soda) think my little brain dump is A) 
completely irrelevant and orthogonal to the concerns of the list, B) 
woefully confused and wrong, C) a vision of the far future and not 
currently worth considering.  (I suppose "D) real nifty" is an option 
too. :) )



More information about the foaf-dev mailing list