<trackbot> Date: 26 October 2015

<npdoty_> scribenick: npdoty

<npdoty_> scribenick: npdoty_

introductions: small group

gmandyam: an interest in geofencing from implementers, especially for mobile devices
... last year, saw a discussion about limitations to Service Workers
... which would also enforce a limitation regarding authenticated origins
... we didn't have consensus on switching to authenticated origins

hadley: what was the dissent?

gmandyam: comment from Martin Thompson in particular
... Geolocation API had a long history of not requiring HTTPS

torgo: but that was a different era
... certainly expect it to go https-only, a TAG view

hadley: can you go over a couple of the motivating use cases?

gmandyam: an older one: alert when points of interest are in a user's vicinity
... assert tracking, when an asset enters or leaves a particular area
... mobile marketing, as a way of verifying that a user who saw an ad has actually entered a store, for example
... current status, published a FPWD, going through issues and started to answer the privacy/security questionnaire

torgo: should TAG start to review this now?

gmandyam: sure. early questionnaire answers noted some serious privacy problems

thread regarding privacy/security questionnaire: https://lists.w3.org/Archives/Public/public-privacy/2015OctDec/0014.html

gmandyam: want to leverage platform-optimized geofencing implementations, like Android geofencing
... Service Workers allows for global scope and process persistence
... currently only define circular geofence, but could have more complex types
... 3 events propagated (enter, leave, error)
... optional position attribute (per npdoty at last TPAC), to allow for data minimization
... developer has to request it, but implementation can choose whether or not to return it

https://github.com/w3c/geofencing-api/issues

Geofencing Issues

Mek: separate permissions between geofencing and geolocation

torgo: sounds confusing

discussion of granularity of the permissions model

npdoty: not clear that geofencing regions can be described to users in a way other than "background tracking all the time"

giri: is a separate geolocation permission required for the Permissions API?

npdoty: what is the purpose of the Permissions API?

Mek: a large part of the purpose is for a site to know whether there is going to be a permission prompt

npdoty: which is why I'm concerned about it for geolocation, because the presence of a prompt makes the use in background scripts less likely

torgo: samsung.com and other large websites, prompt for location immediately
... and should have a more fine-grained alternative so that the site can walk people through the permission prompt

rigo: could store permissions/exceptions, like in DNT exceptions API
... some jurisdictions expect or require ambient notice of geolocation (like through a little icon)

giri: a lot of browsers have a special way to indicate when geolocation is active
... but for service workers, which can run in the background

rigo: should distinguish between GPS geolocation, which is passive and just on the device
... vs. what goes over the network

giri: a geofence breach event will let the webpage do something

rigo: distinction between local limitations of geolocation access, vs. what we send over the wire

Mek: browser can't guarantee that it won't leave the local device, and so don't want to show that to the user

giri: sould geofencing have a distinct level of permission, in terms of the Permission API?
... or should authenticated origins that have "geolocation" permission also get geofencing?

dka: persisting permissions for geofencing is valuable, because I want to get prompted about a Starbucks payment

<dka> (to elaborate: the Starbucks use case is: on IOS, when I have the Starbucks app installed, I can get a home-screen prompt to allow me to bring up a “pay by qr code” feature when I am near a starbucks store (in service of making the payment scenario easier)

<dka> Another geofencing use case: being able to set a reminder that prompts you “when I get home” or “when I get to the office” (allowing the user to set their own geofences). For example “remind me to read the gas meter when I get home”. This is currently possible on IOS.

npdoty: do we need the ability to request and query permission separate from registering a geofence?

Mek: you could imagine an app that wants the permission ahead of time, and then later creates lots of geofences based on input, and wouldn't want to ask for permission on each request

npdoty: but that would be a permission request that can't include information about the geo/zones

giri: so can we just add a Permissions API descriptor for geofencing?

npdoty: I'm not sure we should, since there is this distinction between a single geofence and general permission for geofencing

dsinger: have we tried to list the privacy/security concerns for this API?
... unless we actually specify the pernicious outcomes, harder to mitigate against them
... particularly things in the gray area

<npdoty> scribenick: npdoty

dsinger: geofencing it's difficult to make any verification of how reasonable the zones that are set up

dka: have been demonstrating the positive pattern for geolocation, of providing a single sentence explanation

https://support.apple.com/en-us/HT203033 has an image of this in iOS with Weather

giri: concern that web pages would use that to lie

dka: this was the argument at the time (Geolocation 2009), but I think we should have done the option of a little bit of explanatory text
... because what we've ended up with is blind requests for permission, when users have no idea why it's there

dsinger: spec just needs to clarify that the text is a claim from the website

3: 30 discussion today in #webapps about Service Workers and background privacy

<scribe> ACTION: giri to contact WebAppSec regarding Permissions API and geolocation/geofencing [recorded in http://www.w3.org/2015/10/26-geolocation-minutes.html#action01]

<trackbot> Error finding 'giri'. You can review and register nicknames at <http://www.w3.org/2008/geolocation/track/users>.

<scribe> ACTION: mandyam to contact WebAppSec regarding Permissions API and geolocation/geofencing [recorded in http://www.w3.org/2015/10/26-geolocation-minutes.html#action02]

<trackbot> Created ACTION-114 - Contact webappsec regarding permissions api and geolocation/geofencing [on Giridhar Mandyam - due 2015-11-02].

giri: broader discussion about whether geolocation should provide a way for sites to delcare intent

martin: basic problem with the Permissions API is a single flag in geolocation (yes/no)
... Push uses a little more complexity, with the descriptor field
... does Geolocation need that additional context?

rigo and others: user agents can make contextually dependent decisions based on lots of information

npdoty: but not clear that those details need to be specified here

https://github.com/w3c/geofencing-api/issues/25

giri: why is geofencing tied to service workers? I would like for this to be closed
... also, for people who think authenticated origins is advantageous, this is also helpful

martin: we decided previously that any single page wanted to use it, they could just spin up a service worker

npdoty: what if a site developer wants to create a service worker that dies when the page closes?

dsinger: in iOS, location prompts include "whenever I'm using the app"

giri: if the main page is active, the user could implement it with watchPosition

martin: but it would be difficult and expensive

Mek: should there be an option in the geofence options to say "only when there's an active page"?

martin: extra options attached to the geolocation permissions, "in the background" yes/no

giri: potential permission for background access only where there is an active page

martin: one problem is that sites are going to need to know whether they have permission only when a page is open

action-114: Mek: should there be an option in the geofence options to say "only when there's an active page"

<trackbot> Notes added to action-114 Contact webappsec regarding permissions api and geolocation/geofencing.

https://github.com/w3c/geofencing-api/issues/19

Mek: why is the browser generating a unique tag, as opposed to the site developer just entering a specific name?

npdoty: would have to handle conflicts

Mek: sure, but could do that in the same way as other APIs

dka: could you build a plugin for the browser that could give statistics on when geofences are being used? (discussion to be taken offline)

we agree that it's possible to have bad, privacy-invasive geofence IDs, but shouldn't

[reviewing the agenda]

adjourned until 2pm

<scribe> scribenick: npdoty

Geofence Issues

giri: re issue 19, discussed potential problems with the identifier
... issue 16 about optional inclusion of position attribute
... positive response from dka earlier
... suggestion is to close the issue and keep position optional (requested by site user, and also optional for user agent to provide them in responding)
... issue about potential race condition in removing fences

Mek: yes, there is a risk, that could be fixed in the text

timeless: two calls to "remove" at the same time

npdoty: does the call need to be asynchronous? is there any reason to return "false"?

timeless: easiest implementation would just be to resolve in all cases, but remove the different return values, just make it void

Mek will make spec change.

[some questions about the privacy/security questionnaire]

DeviceOrientation

giri: current spec is in a holding state, hasn't progressed beyond Working Draft
... many known implementations in Mozilla, Chrome, Apple, Microsoft
... Apple doesn't incorporate magnetometer, so developers have to process data to get the same output as the DeviceOrientation spec expects
... not much interest in the work; zero responses on the mailing list this summer
... propose taking this spec to Last Call and otherwise redirect to DAP Generic Sensor API

npdoty: why go to Last Call if you don't want to work on it any more?

timeless: there are interoperable implementations, so valuable to move towards Rec

https://github.com/w3c/deviceorientation/commit/21d433e23808f0ecb57e5c7404522cbca6a14334

<Mek> https://groups.google.com/a/chromium.org/d/msg/blink-dev/lT_-2CiHOf4/UEpwwtdvAgAJ is the blink-dev thread where this was discussed

[some uncertainty about changes that were made to the editor's draft and when]

Mek: Google expressed interest in implementing a changed version of the spec

Giri will follow up with Tim, and on the mailing list.

npdoty: would be worth discussing the privacy issue of background tab access to orientation events

https://lists.w3.org/Archives/Public/public-geolocation/2015Aug/0006.html

npdoty will re-raise the issue on the mailing list/github.

EMMA Extensible MultiModal Annotation

ddahl: EMMA used for semantic, complex interaction, with voice for example
... now more popularized in Siri, Cortana and other AI voice agents
... recently published 2.0, which has a more detailed location semantics
... so that inputs could be location-stamped
... description and address -- description might be an open-ended way of getting location not from a sensor
... or addresses as a possible attribute

http://tools.ietf.org/html/rfc4119

http://www.w3.org/2015/spatial/wiki/Main_Page

Open GeoSpatial Consortium

rigo: could meet with Phil Archer and others who are here this week

ddahl: Geolocation API is all JavaScript? yes.

npdoty: can look at IETF RFCs for a specific XML schema

for example, http://tools.ietf.org/html/rfc5139#section-4 Civic Address Schema

giri: wouldn't be hard to convert features returned by the Geolocation API to convert into an XML document

<kaz> [ break ]