The word 'ownership' always makes me nervous in this kind of context… and apologies, this is one of my pet rant topics, so I promise not to beat the subject to death. Bottom line: it may be healthier if we refer to venues as being 'data controllers', rather than 'data owners'. 

In brief, the underlying point is this: 

You've probably all seen privacy threads where an aggrieved data subject says "All I want is to be given back *my* data"… The implicit assumption is that, in some way, I 'own' my [sic] personal data. Unfortunately, not far down the line that leads to all kinds of unwanted consequences, and therefore we're better off not starting out with a model based on concepts of 'ownership' if at all possible.

For instance, as Bob Blakley pithly put it, "You can't control the stories other people tell about you". There's lots of personal data about you over which you have no control, let alone 'ownership', because it's generated by other people. The only time you get control over it is, for instance, if the information is libellous. Even then, you don't get 'ownership' of the data, but you get the opportunity to exercise certain rights pertaining to it.
 
Similarly, a model based on a concept of 'ownership' doesn't work well for informational resources that can be 'stolen' from you, yet still leave you in possession of the data. Think of copyright digital media… you own the CD of Beethoven's 5th., but there are rights to do with the original work (or the performance) that you don't enjoy.

Legally, there are distinctions between the treatment of "personal property" (or personalty) and "real property" (or realty), and if you want to delve into that aspect, my own belief is that we're better off treating personal data as if it were realty than as if it were personalty. (Happy to take that offline… ;^)

I know this is a rather terse and dense statement of the issue, and my apologies again for that - there are doubtless points here that could be unpacked ad infinitum - but suffice to say, I think an approach based on assumptions of 'rights' over data has fewer problems than one based on assumptions of 'ownership'. I think this is especially true of personal data (including location/tracking/behavioural data): it makes little sense to claim that I 'own' the data collected about my path through a shopping mall, but it makes s lot of sense to claim that I have certain rights relating to data about me.

Hope this is helpful - 


Robin

Robin Wilton
Technical Outreach Director - Identity and Privacy
Internet Society

email: wilton@isoc.org
Phone: +44 705 005 2931
Twitter: @futureidentity




On 1 Aug 2012, at 10:29, Ted Morgan wrote:

> Well the venues will be unwilling to interchange their data if their is not some licensing model associated with it.  That ownership question has dramatically slowed the adoption of indoor technologies.  In fact venue owners have told us data ownership is the single biggest factor keeping them from deploying in-store location technology.  If not part of a standard like this, where would that *promise* be accommodated?  
> 
> 
> On Aug 1, 2012, at 12:03 PM, Martin Thomson wrote:
> 
>> My own:
>> 
>> Given what I know of the deployment models for this sort of
>> technology, I don't see that license information is a) useful to an
>> automaton, and b) necessary for a standardized interchange format.
>> 
>> Also, I don't see the beacons as being relevant to the survey, but
>> more to the venue.  (You might also consider capturing ephemerides if
>> you are capturing EMEA sentences and if you want an archival format.)
>> 
>> There are privacy implications on the use of device characteristics,
>> useful as they are.
>> 
>> To Adam's points:
>> 
>> I believe that there is a fair degree of pre-arrangement involved in
>> this that may alleviate most of your concerns.  A description of the
>> two primary modes of operation is important, because that makes the
>> considerations clearer.
>> 
>> On 31 July 2012 14:02, Robin Wilton <wilton@isoc.org> wrote:
>>> Thanks Adam -
>>> 
>>> In the same spirit, here's a quick recap of my remarks at the mic….
>>> 
>>> The 'venue survey' use-case is an interesting one in its own right, but also
>>> gives an opportunity to explore issues which will be relevant to privacy in
>>> other contexts. Three such issues are:
>>> 
>>> 1 - Opt-in versus opt-out by default. There have been a lot of
>>> 'opted-in-by-default' service deployments in recent years, with
>>> corresponding concern about user notice and consent. The venue survey
>>> use-case is an opportunity to explore the alternative of
>>> 'opted-out-by-default' and to look at ways of encouraging the data subject
>>> to take part on the basis of an engaged awareness.
>>> 
>>> 2 - User transparency; as noted by another commenter, there's a potential
>>> lack of transparency here, with the consequence that individuals may have no
>>> idea that their information is being collected or why… A paper that explores
>>> the various possible means of making users aware of what's going on would be
>>> of value.
>>> 
>>> 3 - The need to take account of possible third party access to the
>>> geolocation data collected through the survey. The temptation is to design
>>> for the 'straight-through' use-case where the only parties involved are the
>>> data subject, the venue owner and the data collector. For privacy purposes,
>>> the proposed document ought at least to acknowledge the risks arising out of
>>> potentially malicious third-party access to data collected.
>>> 
>>> Hope this helps -
>>> 
>>> Robin
>>> 
>>> Robin Wilton
>>> Technical Outreach Director - Identity and Privacy
>>> Internet Society
>>> 
>>> email: wilton@isoc.org
>>> Phone: +44 705 005 2931
>>> Twitter: @futureidentity
>>> 
>>> 
>>> 
>>> 
>>> On 31 Jul 2012, at 13:50, Adam Roach wrote:
>>> 
>>> This is intended to be a reiteration of the points I made at the microphone
>>> today, for the purpose of stimulating discussion on the mailing list.
>>> 
>>> The document covers an aspect of something that I think is interesting and
>>> has utility. At the moment, it covers a syntax for conveying survey
>>> information as well as a fairly rigorous description of what each element in
>>> that information means.
>>> 
>>> What appears to be missing is a discussion of how these documents move
>>> around the network. Based on the microphone discussion with the author, it
>>> appears that the current plan for moving this information around is
>>> something like using PUT or POST requests over https. I think it would be of
>>> great use to cover this topic, either in this document or in a separate one.
>>> 
>>> Key things to consider would be:
>>> 
>>> * What https URL is used for the PUT or POST?
>>>   o How is it provisioned into survey devices?
>>>   o Is it valid to use http instead of https?
>>> * What kind of authentication is used? Basic? Digest? Client certs?
>>> S/MIME signatures? Something else?
>>> * What can the client infer from the HTTP response code regarding the
>>> state of the information it has submitted?
>>> * Is there utility in defining additional transport mechanisms?
>>>   o SIP SUBCRIBE/NOTIFY?
>>>   o Is there value in distributing this information in Atom over HTTP?
>>> * Do we need to define an inter-server protocol for exchanging
>>> information between survey aggregators?
>>> 
>>> 
>>> In terms of permissions (which is related to the privacy question raised by
>>> the presentation), it seems that this kind of document would be well suited
>>> for talking about using Common Policy (RFC 4745). However, without having a
>>> better grip on the larger architecture in which these documents will be
>>> used, I can't really come up with useful suggestions about how such
>>> documents are conveyed/applied/etc.
>>> 
>>> 
>>> /a
>>> 
>>> _______________________________________________
>>> Geopriv mailing list
>>> Geopriv@ietf.org
>>> https://www.ietf.org/mailman/listinfo/geopriv
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Geopriv mailing list
>>> Geopriv@ietf.org
>>> https://www.ietf.org/mailman/listinfo/geopriv
>>> 
>> _______________________________________________
>> Geopriv mailing list
>> Geopriv@ietf.org
>> https://www.ietf.org/mailman/listinfo/geopriv
>