01:50:58 RRSAgent has joined #geolocation 01:50:58 logging to http://www.w3.org/2015/10/26-geolocation-irc 01:51:00 RRSAgent, make logs member 01:51:00 Zakim has joined #geolocation 01:51:02 Zakim, this will be GEO 01:51:02 I do not see a conference matching that name scheduled within the next hour, trackbot 01:51:03 Meeting: Geolocation Working Group Teleconference 01:51:03 Date: 26 October 2015 01:51:15 rrsagent, logs will extend beyond midnight 01:51:15 I'm logging. I don't understand 'logs will extend beyond midnight', npdoty_. Try /msg RRSAgent help 01:52:33 scribenick: npdoty 01:52:38 scribenick: npdoty_ 01:52:47 introductions: small group 01:53:14 present+ gmandyam, mounir, npdoty, torgo, hadley 01:54:13 gmandyam: an interest in geofencing from implementers, especially for mobile devices 01:54:35 ... last year, saw a discussion about limitations to Service Workers 01:54:55 ... which would also enforce a limitation regarding authenticated origins 01:55:17 ... we didn't have consensus on switching to authenticated origins 01:55:22 hadley: what was the dissent? 01:55:36 gmandyam: comment from Martin Thompson in particular 01:56:15 ... Geolocation API had a long history of not requiring HTTPS 01:56:22 torgo: but that was a different era 01:56:40 ... certainly expect it to go https-only, a TAG view 01:57:38 hadley: can you go over a couple of the motivating use cases? 01:59:08 gmandyam: an older one: alert when points of interest are in a user's vicinity 01:59:17 ... assert tracking, when an asset enters or leaves a particular area 01:59:46 ... mobile marketing, as a way of verifying that a user who saw an ad has actually entered a store, for example 02:03:56 gmandyam: current status, published a FPWD, going through issues and started to answer the privacy/security questionnaire 02:04:01 torgo: should TAG start to review this now? 02:04:34 gmandyam: sure. early questionnaire answers noted some serious privacy problems 02:05:24 thread regarding privacy/security questionnaire: https://lists.w3.org/Archives/Public/public-privacy/2015OctDec/0014.html 02:05:55 gmandyam: want to leverage platform-optimized geofencing implementations, like Android geofencing 02:06:04 ... Service Workers allows for global scope and process persistence 02:06:27 ... currently only define circular geofence, but could have more complex types 02:06:53 ... 3 events propagated (enter, leave, error) 02:07:20 ... optional position attribute (per npdoty at last TPAC), to allow for data minimization 02:07:50 ... developer has to request it, but implementation can choose whether or not to return it 02:08:02 https://github.com/w3c/geofencing-api/issues 02:08:08 Topic: Geofencing Issues 02:08:11 -> https://www.w3.org/wiki/TPAC/2015/SessionIdeas breakout session ideas 02:09:04 s|-> https://www.w3.org/wiki/TPAC/2015/SessionIdeas breakout session ideas|| 02:09:05 mounir: separate permissions between geofencing and geolocation 02:09:11 torgo: sounds confusing 02:13:29 npdoty_ has joined #geolocation 02:15:19 discussion of granularity of the permissions model 02:15:58 npdoty: not clear that geofencing regions can be described to users in a way other than "background tracking all the time" 02:16:21 giri: is a separate geolocation permission required for the Permissions API? 02:17:56 npdoty: what is the purpose of the Permissions API? 02:18:20 mounir: a large part of the purpose is for a site to know whether there is going to be a permission prompt 02:18:59 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 02:19:16 torgo: samsung.com and other large websites, prompt for location immediately 02:19:31 ... and should have a more fine-grained alternative so that the site can walk people through the permission prompt 02:19:53 rigo: could store permissions/exceptions, like in DNT exceptions API 02:20:37 dka has joined #geolocation 02:21:12 present+ DKA, hadleybeeman 02:21:56 hadleybeeman has joined #geolocation 02:22:44 rigo: some jurisdictions expect or require ambient notice of geolocation (like through a little icon) 02:23:10 giri: a lot of browsers have a special way to indicate when geolocation is active 02:23:19 ... but for service workers, which can run in the background 02:25:05 rigo: should distinguish between GPS geolocation, which is passive and just on the device 02:25:12 ... vs. what goes over the network 02:25:42 giri: a geofence breach event will let the webpage do something 02:28:30 rrsagent, draft minutes 02:28:30 I have made the request to generate http://www.w3.org/2015/10/26-geolocation-minutes.html kaz 02:29:24 rigo: distinction between local limitations of geolocation access, vs. what we send over the wire 02:31:13 mounir: browser can't guarantee that it won't leave the local device, and so don't want to show that to the user 02:32:46 giri: sould geofencing have a distinct level of permission, in terms of the Permission API? 02:33:31 ... or should authenticated origins that have "geolocation" permission also get geofencing? 02:35:08 dka: persisting permissions for geofencing is valuable, because I want to get prompted about a Starbucks payment 02:37:05 dsinger has joined #geolocation 02:37:13 (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) 02:38:52 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. 02:39:07 npdoty: do we need the ability to request and query permission separate from registering a geofence? 02:39:37 mounir: 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 02:41:10 npdoty: but that would be a permission request that can't include information about the geo/zones 02:41:22 giri: so can we just add a Permissions API descriptor for geofencing? 02:41:47 npdoty: I'm not sure we should, since there is this distinction between a single geofence and general permission for geofencing 02:42:11 dsinger: have we tried to list the privacy/security concerns for this API? 02:42:26 ... unless we actually specify the pernicious outcomes, harder to mitigate against them 02:42:33 ... particularly things in the gray area 02:45:58 s/mounir:/Mek:/g 02:47:03 dsinger: geofencing it's difficult to make any verification of how reasonable the zones that are set up 02:49:45 dka: have been demonstrating the positive pattern for geolocation, of providing a single sentence explanation 02:49:58 https://support.apple.com/en-us/HT203033 has an image of this in iOS with Weather 02:50:20 giri: concern that web pages would use that to lie 02:51:19 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 02:51:33 ... because what we've ended up with is blind requests for permission, when users have no idea why it's there 02:52:05 dsinger: spec just needs to clarify that the text is a claim from the website 02:54:32 3:30 discussion today in #webapps about Service Workers and background privacy 02:54:52 action: giri to contact WebAppSec regarding Permissions API and geolocation/geofencing 02:54:52 Error finding 'giri'. You can review and register nicknames at . 02:55:02 action: mandyam to contact WebAppSec regarding Permissions API and geolocation/geofencing 02:55:03 Created ACTION-114 - Contact webappsec regarding permissions api and geolocation/geofencing [on Giridhar Mandyam - due 2015-11-02]. 02:55:47 giri: broader discussion about whether geolocation should provide a way for sites to delcare intent 02:56:14 martin: basic problem with the Permissions API is a single flag in geolocation (yes/no) 02:56:27 ... Push uses a little more complexity, with the descriptor field 02:56:33 ... does Geolocation need that additional context? 03:01:25 rigo and others: user agents can make contextually dependent decisions based on lots of information 03:02:55 npdoty: but not clear that those details need to be specified here 03:08:30 npdoty has joined #geolocation 03:10:36 https://github.com/w3c/geofencing-api/issues/25 03:10:51 giri: why is geofencing tied to service workers? I would like for this to be closed 03:11:17 ... also, for people who think authenticated origins is advantageous, this is also helpful 03:13:03 martin: we decided previously that any single page wanted to use it, they could just spin up a service worker 03:16:02 npdoty: what if a site developer wants to create a service worker that dies when the page closes? 03:20:08 dsinger: in iOS, location prompts include "whenever I'm using the app" 03:20:44 giri: if the main page is active, the user could implement it with watchPosition 03:20:50 martin: but it would be difficult and expensive 03:21:12 Mek: should there be an option in the geofence options to say "only when there's an active page"? 03:21:32 martin: extra options attached to the geolocation permissions, "in the background" yes/no 03:22:01 giri: potential permission for background access only where there is an active page 03:22:43 martin: one problem is that sites are going to need to know whether they have permission only when a page is open 03:23:47 action-114: Mek: should there be an option in the geofence options to say "only when there's an active page" 03:23:47 Notes added to action-114 Contact webappsec regarding permissions api and geolocation/geofencing. 03:24:02 https://github.com/w3c/geofencing-api/issues/19 03:25:05 Mek: why is the browser generating a unique tag, as opposed to the site developer just entering a specific name 03:25:11 s/name/name?/ 03:25:19 npdoty: would have to handle conflicts 03:25:40 Mek: sure, but could do that in the same way as other APIs 03:28:09 dka: could you build a plugin for the browser that could give statistics on when geofences are being used? (discussion to be taken offline) 03:31:46 we agree that it's possible to have bad, privacy-invasive geofence IDs, but shouldn't 03:32:02 [reviewing the agenda] 03:32:25 adjourned until 2pm 03:32:29 rrsagent, please draft the minutes 03:32:29 I have made the request to generate http://www.w3.org/2015/10/26-geolocation-minutes.html npdoty 04:40:32 Zakim has left #geolocation 04:44:19 dka has joined #geolocation 04:57:31 dsinger has joined #geolocation 04:57:44 dsinger has left #geolocation 05:05:10 npdoty has joined #geolocation 05:05:59 kaz has joined #geolocation 05:23:46 scribenick: npdoty 05:23:55 Topic: Geofence Issues 05:24:15 giri: re issue 19, discussed potential problems with the identifier 05:25:00 ... issue 16 about optional inclusion of position attribute 05:25:14 ... positive response from dka earlier 05:25:23 RRSAgent, make logs world 05:25:28 RRSAgent, draft minutes 05:25:28 I have made the request to generate http://www.w3.org/2015/10/26-geolocation-minutes.html timeless 05:25:58 ... 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) 05:26:09 chair: giri 05:26:13 RRSAgent, draft minutes 05:26:13 I have made the request to generate http://www.w3.org/2015/10/26-geolocation-minutes.html timeless 05:26:23 present+ timeless 05:27:31 giri: issue about potential race condition in removing fences 05:27:49 ddahl has joined #geolocation 05:27:58 Mek: yes, there is a risk, that could be fixed in the text 05:30:50 timeless: two calls to "remove" at the same time 05:33:46 dka has joined #geolocation 05:33:56 npdoty has joined #geolocation 05:36:53 npdoty: does the call need to be asynchronous? is there any reason to return "false"? 05:37:09 timeless: easiest implementation would just be to resolve in all cases, but remove the different return values, just make it void 05:37:29 Mek will make spec change. 05:40:23 [some questions about the privacy/security questionnaire] 05:40:27 Topic: DeviceOrientation 05:40:50 giri: current spec is in a holding state, hasn't progressed beyond Working Draft 05:41:03 ... many known implementations in Mozilla, Chrome, Apple, Microsoft 05:41:39 ... Apple doesn't incorporate magnetometer, so developers have to process data to get the same output as the DeviceOrientation spec expects 05:42:24 ... not much interest in the work; zero responses on the mailing list this summer 05:43:28 ... propose taking this spec to Last Call and otherwise redirect to DAP Generic Sensor API 05:46:49 npdoty: why go to Last Call if you don't want to work on it any more? 05:49:22 timeless: there are interoperable implementations, so valuable to move towards Rec 05:54:00 https://github.com/w3c/deviceorientation/commit/21d433e23808f0ecb57e5c7404522cbca6a14334 05:54:35 https://groups.google.com/a/chromium.org/d/msg/blink-dev/lT_-2CiHOf4/UEpwwtdvAgAJ is the blink-dev thread where this was discussed 05:55:29 [some uncertainty about changes that were made to the editor's draft and when] 05:57:41 Mek: Google expressed interest in implementing a changed version of the spec 05:57:49 Giri will follow up with Tim, and on the mailing list. 06:00:16 npdoty: would be worth discussing the privacy issue of background tab access to orientation events 06:00:17 https://lists.w3.org/Archives/Public/public-geolocation/2015Aug/0006.html 06:00:29 npdoty will re-raise the issue on the mailing list/github. 06:03:09 Topic: EMMA Extensible MultiModal Annotation 06:03:30 ddahl: EMMA used for semantic, complex interaction, with voice for example 06:03:39 ... now more popularized in Siri, Cortana and other AI voice agents 06:03:49 ... recently published 2.0, which has a more detailed location semantics 06:04:44 ... so that inputs could be location-stamped 06:05:16 ... description and address -- description might be an open-ended way of getting location not from a sensor 06:05:23 ... or addresses as a possible attribute 06:06:35 dka has joined #geolocation 06:08:14 dom has joined #geolocation 06:09:27 http://tools.ietf.org/html/rfc4119 06:09:46 http://www.w3.org/2015/spatial/wiki/Main_Page 06:10:52 Open GeoSpatial Consortium 06:15:12 rigo: could meet with Phil Archer and others who are here this week 06:16:18 ddahl: Geolocation API is all JavaScript? yes. 06:17:27 npdoty: can look at IETF RFCs for a specific XML schema 06:17:34 for example, http://tools.ietf.org/html/rfc5139#section-4 Civic Address Schema 06:17:57 giri: wouldn't be hard to convert features returned by the Geolocation API to convert into an XML document 06:21:02 rigo has joined #geolocation 06:23:06 npdoty has joined #geolocation 06:24:10 [ break ] 06:24:14 rrsagent, draft minutes 06:24:14 I have made the request to generate http://www.w3.org/2015/10/26-geolocation-minutes.html kaz 07:14:48 npdoty has joined #geolocation 07:15:11 dka has joined #geolocation 07:18:47 npdoty has joined #geolocation