Re: Geofencing API: Initial attempt at answering Privacy Questionnaire

I think that David is hitting some important points here.

In terms of zones, the only rational way to approach this (in my
opinion at least) is to regard this as a permanent, persistent
tracking capability.  We can't expect users to reason about the zones
they don't get to see.

My previous work on location privacy has taught me that small pieces
of geolocation information can be used to learn a lot about the
location of a person.  You don't actually have to set a zone for the
police station to learn that someone is visiting it.

I think that there are other concerns that this raises, with respect
to access to other system resources.  This is an open point of
discussion on other service worker APIs, like Web Push and Background
Sync.

I disagree with Giri's assessment on some of the points below.

On 21 October 2015 at 06:14, David Singer <singer@apple.com> wrote:
> Hi
>
> thanks for this.  I think it reveals that we need to think hard about this questionnaire, alas.
>
> I am concerned about the privacy aspects of this.  I rather suspect that the theory is that people would prefer to give background permission to a web app to know when they enter and exit ‘zones’, than to follow them everywhere they go. But that doesn’t answer the question of whether we can ever construct this so that the users won’t be exposed to greater privacy risk than they can perceive when they are asked. Should they *ever* say ‘yes’?
>
> Also, there are privacy questions about the zones as well as the user. What if the web app draws zones that match apartments that are rented by the hour, for example, or police stations? Doesn’t the owner of the property in the zone have privacy considerations over what tracing of people entering/leaving is allowed? They are nowhere in the permission loop here.
>
> Then, the API might attempt to re-assure people that the zones are (for example) roughly 1 square mile in size. But (a) if they overlap or are close, the overlaps may reveal much finer-grained data and (b) anywhere near an edge, such that they oscillate across it, will be seen to be on the edge somewhere — both much higher precision.
>
>> On Oct 19, 2015, at 19:30 , Mandyam, Giridhar <mandyam@qti.qualcomm.com> wrote:
>>
>> Hello Geolocation WG and PING,
>>
>> As per guidance from the TAG, I am taking an attempt at answering the Privacy questionnaire [1] with respect to the latest version of the Geofencing API [2], [3].  Note that the Geofencing API does have an existing security and privacy section [4] that may be modified depending on how the answers to the questionnaire shape up.  I’ve added notes in the form of ‘{NOTE: …}’ for questions whose answers I think need special scrutiny.
>>
>>
>>
>> Thanks,
>>
>> -Giri Mandyam, Geolocation WG Chair
>>
>>
>>
>> References
>>
>> [1] https://w3ctag.github.io/security-questionnaire/#questions
>>
>> [2] https://w3c.github.io/geofencing-api/
>>
>> [3] https://github.com/w3c/geofencing-api
>>
>> [4] https://w3c.github.io/geofencing-api/#security-and-privacy-considerations
>>
>> [5] http://www.w3.org/TR/geolocation-API/
>>
>> [6] http://www.w3.org/TR/service-workers/#dfn-scope-url
>>
>>
>>
>>       • 3.1 Does this specification deal with personally-identifiable information?
>> Yes.  Geolocation data can be used help in identifying a person.  A user’s location profile (i.e. the probabilistic distribution of the likelihood a person is in a given place at a given time), in combination with other information, may be used to uniquely determine a device user.
>>
>>       • 3.2 Does this specification deal with high-value data?
>> Yes.  Location data may be used for end user authentication (based on a ‘trusted location’).  Moreover, this specification’s target technology (geofencing) may be used as part of a “pervasive monitoring” attack (as defined in RFC 7258).
>>
>>       • 3.3 Does this specification introduce new state for an origin that persists across browsing sessions?
>> Yes.  The dependency on Service Workers allows for process persistence across browsing sessions.  As has already been pointed out in the questionnaire itself, Service Workers offers some mitigation in the form of requiring authenticated origins.

An authenticated origin is not an effective mitigation.  Service
workers have very little in terms of mitigation.

>>       • 3.4 Does this specification expose persistent, cross-origin state to the web?
>> {NOTE:  I may not fully understand the nature of this question, so my answer should be taken with a grain of salt}.  This specification does not in and of itself expose persistent cross-origin state to the web.  This is because Service Workers are registered against the invoking origin.  However, the main page (main thread) that created the service worker may expose any associated data to other origins using acceptable web technologies.  The mitigation for this is to prohibit mixed content.

The answer is "It's complicated".  There is no direct sharing of
state.  However, by virtue of the fact that different origins receive
the same information at the same time, a single user can be identified
across origins.

>>       • 3.5 Does this specification expose any other data to an origin that it doesn’t currently have access to?
>> No.  Geofencing as a function can always be implemented at the application layer using the existing W3C Geolocation API (see References, [5]).  However, this does not allow the web application to (a) take advantage of efficient platform-based implementations for geofencing, and (b) achieve a level of geofencing process persistence based on the use of Service Workers.

The answer is Yes, because the information is made available at times
that an application would not otherwise be able to access that
information.

>>       • 3.6 Does this specification enable new script execution/loading mechanisms?
>> No.
>>
>>       • 3.7 Does this specification allow an origin access to a user’s location?
>> Yes.  This specification is cited as an example in the questionnaire itself.
>>
>>       • 3.8 Does this specification allow an origin access to sensors on a user’s device?
>> Yes, but not necessarily to discrete sensor data.  Modern location engines use a variety of sources in creating the determination of user device location, and therefore implement a form of “sensor fusion.”
>>
>>       • 3.9 Does this specification allow an origin access to aspects of a user’s local computing environment?
>> No.

This is Yes.

>>       • 3.10 Does this specification allow an origin access to other devices?
>> No.
>>
>>       • 3.11 Does this specification allow an origin some measure of control over a user agent’s native UI?
>> No.
>>
>>       • 3.12 Does this specification expose temporary identifiers to the web?
>> Yes.  Service Workers have a notion of a scope URL (see References, [6]).
>>
>>       • 3.13 Does this specification distinguish between behavior in first-party and third-party contexts?
>> {NOTE:  I am making an assertion about how Service Workers deal with cookies based on my reading of the spec; I may be wrong}. No, but with specific respect to “first-party-only cookies” it does not need to.  The functionality defined in this specification is restricted to service workers.  Service workers do not have direct access or visibility to cookies.

The answer is no, but the last statement is incorrect.

>>       • 3.14 How should this specification work in the context of a user agent’s "incognito" mode?
>> Yes it should.  Incognito mode should not be affected by the presence of Service Workers.

I think that this is incorrect.  Service Worker permissions need to
terminate when a user switches into a privacy-enhanced mode or there
is linkability.

>>       • 3.15 Does this specification persist data to a user’s local device?
>> {NOTE:  I believe this question seems to be getting at features such as cookies or app cache.  Note also that my assertion about Service Workers and data persistence may not be accurate.}  Service Workers are tied to persistent background processing, and the user agent must persist a list of all registered service workers.  However, this is not the same kind of data persistence that is seen with cookies or features such as applicationCache or LocalStorage.  The persisted data associated with the Service Worker is controlled by the User Agent, not the invoking origin.

The answer is Yes.  I believe that fences need to be persisted for this to work.

>>       • 3.16 Does this specification have a "Security Considerations" and "Privacy Considerations" section?
>> Yes.  See References, [4].
>>
>>       • 3.17 Does this specification allow downgrading default security characteristics?
>> {NOTE:  This question needs more explanation.  I didn’t quite understand it, and the examples given (e.g. CORS) did not provide insight as to an example of ‘downgrading default security charactersistics’}.  No.

Received on Wednesday, 21 October 2015 18:16:01 UTC