Re: privacy and open data

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.

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.

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?

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.

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/
>

Received on Wednesday, 26 March 2008 13:14:25 UTC