Subject: Re: [Geopriv] Comments on draft-jones-geopriv-sigpos-survey

From: Martin Thomson <[email-masked]>
Date: Wed, 1 Aug 2012 09:03:48 -0700

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 <[email-masked]> 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: [email-masked]
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv
>
>
>
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv
>

---

From: Ted Morgan <[email-masked]>
Date: Wed, 1 Aug 2012 12:29:42 -0500

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?

---

From: Martin Thomson <[email-masked]>
Date: Wed, 1 Aug 2012 10:41:50 -0700

> 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 technolo…

I'm not suggesting that there is no license, I just don't understand
well-enough how you intend for the license to be populated and
consumed as part of this particular interchange format.

I don't think that this particular mechanism is going to solve your
underlying problem, which is that you have to obtain license from both
the person performing measurements and the venue owner to use the
information, each with varying constraints.

---

From: Kipp Jones <[email-masked]>
Date: Wed, 1 Aug 2012 12:51:16 -0500

Didn't we go through some similar discussions wrt locarion data rights from users? Retention, expiration, etc.? I know this is a different issue, but it seems we should be able to get the people together to work through a basic model.

I'm not sure we should punt too quickly on the hard parts. And the people performing the survey could be considered agents of the venue owner, acting on behalf of the venue.

I'd like to get some more feedback, we'll try to get some venue owners to speak up as well.

Cheers

Kipp

Sent from my iPhone

---

From: Martin Thomson <[email-masked]>
Date: Wed, 1 Aug 2012 10:53:52 -0700

Maybe if the flow of information were better understood, then this
might be more tractable.  Currently, I do not see how a venue owner
interacts with the entity creating the document.

---

From: Robin Wilton <[email-masked]>
Date: Wed, 1 Aug 2012 11:20:56 -0700

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

email: [email-masked]
Phone: +44 705 005 2931
Twitter: @futureidentity

---

From: Robin Wilton <[email-masked]>
Date: Wed, 1 Aug 2012 11:27:16 -0700

Oops. Apologies if there has already been discussion of rights versus ownership. I didn't intend to re-hash anything that's already been dealt with. One of the perils of joining a thread well into its lifecycle.

R

Robin Wilton

email: [email-masked]
Phone: +44 705 005 2931
Twitter: @futureidentity

---

From: Ted Morgan <[email-masked]>
Date: Wed, 1 Aug 2012 14:54:40 -0500

Fair points and maybe there is better language to use but the venue owners (think Best Buy, MGM Grand, Mall owners, corp campuses, Ball parks) are very protective about what happens on their premises and do view those wifi networks as something very proprietary.  These aren't public hotspots.  Now, we know that anyone can observe and collect these signals on their own, but what is trying to be accomplished with this standard is to have the venue owners participate in and drive the mapping of their venues.  Some comments we have heard "why should I let someone scan my ball park and then make money off of apps/services which we see none of?" "I don't want XXXX coming in here and mapping my store only to offer comparative shopping services to show people how to leave my store and buy a product elsewhere".  So if they are going to be involved, they want control.  We may not like it but our alternative is to watch the adoption move at the rate it has for the last ten years (slow).  With this model, they can say "anyone can come into my venue and do detailed mapping as long as they support the standard".

Hopefully the venue owners will get involved in this list as well so you can hear their concerns directly.

On Aug 1, 2012, at 2:20 PM, Robin Wilton wrote:

Hope this is helpful -

Robin

Robin Wilton

email: [email-masked]<mailto:[email-masked]>
Phone: +44 705 005 2931
Twitter: @futureidentity

My own:

To Adam's points:

On 31 July 2012 14:02, Robin Wilton <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Adam -

Hope this helps -

Robin

Robin Wilton

email: [email-masked]<mailto:[email-masked]>
Phone: +44 705 005 2931
Twitter: @futureidentity

/a

_______________________________________________
Geopriv mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/geopriv

---

From: Martin Thomson <[email-masked]>
Date: Wed, 1 Aug 2012 14:22:18 -0700

I think that you need to explain _how_ before I can make any sort of
judgement about the mechanism.  And I'm talking about Adam's question
more than the contents of an XML document.

On 1 August 2012 12:54, Ted Morgan <[email-masked]> wrote:
> Fair points and maybe there is better language to use but the venue owners
> (think Best Buy, MGM Grand, Mall owners, corp campuses, Ball parks) are very
> protective about what happens on their premises and do view those wifi
> networks as something very proprietary.  These aren't public hotspots.  Now,
> we know that anyone can observe and collect these signals on their own, but
> what is trying to be accomplished with this standard is to have the venue
> owners participate in and drive the mapping of their venues.  Some comments
> we have heard "why should I let someone scan my ball park and then make
> money off of apps/services which we see none of?" "I don't want XXXX coming
> in here and mapping my store only to offer comparative shopping services to
> show people how to leave my store and buy a product elsewhere".  So if they
> are going to be involved, they want control.  We may not like it but our
> alternative is to watch the adoption move at the rate it has for the last
> ten years (slow).  With this model, they can say "anyone can come into my
> venue and do detailed mapping as long as they support the standard".
>
> 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'.
>
> 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
> 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?
>
>

---

From: Robin Wilton <[email-masked]>
Date: Wed, 1 Aug 2012 15:39:15 -0700

Thanks Ted - entirely rational. I was perhaps misinterpreting the emphasis of this work (i.e. on mapping the premises, rather than on mapping the movement of customers - so apologies if I was tilting at the wrong windmill ;^)

I think the 'finesse' here might be to draw the distinction between 

i - the venue owner's entitlement to exercise their rights relating to the premises, the private networks etc

ii - the rights individuals might have relating to data about them that is captured as a result of their presence/movement/actions in a given space

(And I also fully appreciate that there are different legal contexts (and different social expectations) relating to this, depending which country etc this is happening in.)

Engagement/discussion with venue owners would be great… because stakeholder engagement is always good, and because down the road, one foreseeable outcome is some form of self-regulatory code of conduct on the collection/use of this kind of data.

Yrs.,
Robin

Robin Wilton

email: [email-masked]
Phone: +44 705 005 2931
Twitter: @futureidentity

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 2 Aug 2012 07:43:11 +0800

I like the idea of this document, well done Kipp.
My suggestion is probably noise when compared to the various "rights to use" discussion that has been going on.

I would like to see the ability to provide some of the venue information by reference as well as by value.
For example if I were doing a big survey of a building and included multiple sessions that looking at example that starts on page 41, I have to repeat quite a lot of verbose information that is likely to be repeated over and over, providing a URL that points to this information would be a nice optimization.

I agree with Adam also that the more discussion on how the information gets from the device to the LIS needs to be had, whether this is done in this document or a supporting document I don't mind.

Cheers
James