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

From: Adam Roach <[email-masked]>
Date: Tue, 31 Jul 2012 13:50:14 -0700

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

---

From: Robin Wilton <[email-masked]>
Date: Tue, 31 Jul 2012 14:02:57 -0700

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