Re: [foaf-dev] Re: privacy and open data

Hi Phil,

On 26 Mar 2008, at 13:13, Phil Archer wrote:

> Henry, all,
>
> I've jumped back to the start of this thread to raise an additional  
> concern/use case about the whole issue of data portability and  
> privacy protection.

Thanks; glad you're following this...

> I've been told many times that once asserted, an RDF triple persists  
> until the entropic heath death of the universe. Therefore any  
> privacy protection system that depends on triples, at least in  
> theory, cannot support the rather human practices of growing up,  
> changing one's mind, changing jobs etc.

I suspect you've been misinformed there. It's certainly true that RDF  
itself doesn't offer much subtlety. It's simply a system for making  
claims. But we can wrap systems around it that offer a bit more, I  
think.

> If I allow my e-mail address to be seen by anyone who is no more  
> than 2 hops from my FOAF file, I would want that check be carried  
> out in real time so that if I deleted someone from my FOAF file, the  
> permission would not be granted. But does this break the Semantic  
> model?

W3C Semantic Web here is just a model for making claims. It can be  
plugged into all kinds of protocols and restricted environments, which  
may themselves reason in terms of claims, or simply in terms of access  
to documents (not necessarily via HTTP; XMPP/Jabber is key here too).

> In the POWDER WG, with help from Jeremy Carroll, we've defined a  
> semantic extension to make it possible to put an expiry date on  
> triples [1]. Can something like this be worked into data portability?
>
> I could back this up with a nice gentle "I've changed job so no more  
> e-mail about its staff social functions please" but here's a more  
> scary one:
>
> Imagine a teenage girl who is being abused at home. She uses her  
> social network to call for help. Luckily, she finds it and manages  
> to escape the dangerous home life. Now she wants to keep in touch  
> with her new support network but become invisible to her former  
> abuser.
>
> In short, any privacy control needs to support changing circumstances.

I absolutely agree we must have these scenarios in the forefront of  
our thinking.

Your scenario is pretty close (by no coincidence) to an example I used  
in a recent talk, see slide 29 of http://www.slideshare.net/danbri/whatever-i-can-get/ 
  (I'm in process of writing up my actual talk from a low-quality  
video, will circulate that when finished).

cheers

Dan


> Phil.
>
> [1] http://www.w3.org/TR/2008/WD-powder-dr-20080317/#temporalSE
>
> -- 
> Phil Archer
> Chief Technical Officer,
> Family Online Safety Institute
> w. http://www.fosi.org/people/philarcher/
>
>
> Story Henry wrote:
>> Dear Semantic Web community,
>>    We are looking for a way to solve some simple privacy problem in  
>> RDF. We have explored this previously on the foaf list [1], but  
>> would like to have the input from the larger community on this  
>> issue as the problem is a generic one beyond the bounds of foaf.
>> We have a simple use case. Foaf allows its users to create open  
>> distributed social networks. This is a addressing a real problem  
>> 100s of millions of people are going to be wanting solved in the  
>> near future. But currently all the data is open for all to see.  
>> This is ok for us researchers, but many people would like some of  
>> their information to be available to select groups of individuals.  
>> I know many for example who are happy to publish information about  
>> their professional life, but would rather their family network  
>> remain available only to their family.
>> What is needed now is a way to also enable people to limit who can  
>> see what information about them, in a way compatible with the  
>> constraints of REST and Linked Data. I can think of a couple of  
>> methods:
>>  1. either return different representations of the requested  
>> resource depending on who is viewing the information
>>  2. have different resources be responsible for different subsets  
>> of the data and create rdf:seeAlso links between them. Some of  
>> these resources would only be accessible to certain user agents (UA).
>> In both cases there has to be some way of identifying the authority  
>> of the UA. As OpenId is easy to understand, let us use that for the  
>> moment. So as an example one could develop an rdf vocabulary to say  
>> the following [2][4]
>> <public> rdfs:seeAlso <protected> .
>> <protected> readableBy SomeGroup;
>>            login [ = </login>;
>>                    a OpenidLoginService ].
>> SomeGroup could be defined for example as being all the friends of  
>> one's friends with openids specified by their foaf file (see the  
>> work done by DIG [3])
>> Is there a working group developing such a vocabulary already? Is  
>> there a standard here we should develop upon?
>> Given that this information is to be read by new types of  
>> UserAgents that need to be limited by the functionality of current  
>> web browsers, it is also quite possible to imagine much simpler  
>> protocols than openid. Off the top of my head I thought of a way of  
>> using foaf ids, linked to foaf files, linked to pgp keys to create  
>> a much quicker, cleaner and resource oriented authentication  
>> method. see [2]
>> It  seems to me that it should be quite easy to get something  
>> working here.
>>    Yours sincerly,
>>        Henry
>> [1] http://lists.foaf-project.org/pipermail/foaf-dev/2008-January/008793.html
>> [2] http://lists.foaf-project.org/pipermail/foaf-dev/2008-January/008820.html
>> [3] http://dig.csail.mit.edu/breadcrumbs/node/206
>> [4]  Note that 1. is really a special case of 2. where there is  
>> only one resource that returns different representations depending  
>> on the authority of the user agent.
>> <> readableBy SomeGroup;
>>   login [ = </login>;
>>           a OpenidLoginService ].
>> Home page: http://bblfish.net/
>
>
>
>
> _______________________________________________
> foaf-dev mailing list
> foaf-dev@lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-dev
>

Received on Thursday, 27 March 2008 13:18:10 UTC