00:12:59 RRSAgent has joined #dap 00:12:59 logging to https://www.w3.org/2019/09/19-dap-irc 00:13:12 Zakim has joined #dap 00:13:18 RRSAgent, make logs public 00:13:25 Meeting: Devices and Sensors F2F Day 1 – 19 September 2019 00:13:32 Chair: Anssi, Reilly 00:13:40 Agenda: https://github.com/w3c/devicesensors-wg/issues/24 00:14:12 scribenick: reillyg 00:14:54 Scribe: Reilly 00:15:06 RRSAgent, draft minutes v2 00:15:06 I have made the request to generate https://www.w3.org/2019/09/19-dap-minutes.html anssik 00:15:47 Present+ Anssi_Kostiainen 00:15:54 RRSAgent, make logs public 00:16:03 RRSAgent, draft minutes v2 00:16:03 I have made the request to generate https://www.w3.org/2019/09/19-dap-minutes.html xfq 00:16:03 present+ Reilly Grant, Google LLC 00:16:04 Present+ Flaki 00:16:10 present+ Fuqiao_Xue 00:16:24 Present+ Thomas_Steiner 00:16:49 Present+ Ovidio Ruiz-Henríquez 00:19:55 Present+ Kris_McGlinn 00:20:03 Present+ Nikhil_Thorat 00:20:11 RRSAgent, draft minutes v2 00:20:11 I have made the request to generate https://www.w3.org/2019/09/19-dap-minutes.html anssik 00:20:37 Topic: Agenda bashing 00:21:09 Present+ Fuqiao_Xue 00:21:25 Kris has joined #dap 00:22:06 anssik: Hello, I'm Anssi from Intel, co-chair of this group. I'm interested in getting a perspective from non-Chromium engines and the wider community. 00:22:20 ... Chromium is the spearhead project driving a lot of this work. 00:22:32 ... TPAC is an opportunity to get feedback from others. 00:23:03 flaki: Hi, I work from Mozilla, here as an observer. I don't represent Mozilla's official position. 00:23:17 ... Those are represented by github.com/mozilla/standard-positions. 00:23:22 RRSAgent, draft minutes v2 00:23:22 I have made the request to generate https://www.w3.org/2019/09/19-dap-minutes.html anssik 00:23:30 ... I'm here because of my love for IoT. 00:23:52 ... I'm interested in APIs that provide native parity. My favorite is Web Bluetooth. 00:24:32 Nikhil: I'm from Google and I work on TensorflowJS. I'm here because I'm interested, not representing Google's opinion. 00:24:49 ... Would like to do processing of sensor data locally on device for privacy preservation. 00:25:16 Anssi: Have you been doing any on-client sensors work today with TensorFlowJS? 00:25:36 Nikhil: We use camera and audio, no work yet with motion. Something to look at for the future. 00:25:45 ... Could be used for motion controls, accessibility. 00:26:33 flaki: Charlie Gerrard (@devdevcharlie), experimenting with motion controls and gesture detection. 00:26:53 Tom: I'm Chrome Developer Relations. 00:27:17 ... These APIs aren't real APIs unless they land in other browsers so excited to see other vendors here even in an unofficial capacity. 00:27:22 Present+ Rijubrata_Bhaumik 00:27:36 Charlie's talk mentioned: https://www.youtube.com/watch?v=HvtlRMpDbnQ 00:27:37 Riju has joined #Dap 00:27:39 ... Excited by new use cases. Ambient light sensor. Geolocation. Orientation. 00:28:27 Riju: Involved from the start in Generic Sensors, working on shipping ALS and Proximity soon. 00:28:46 Anssi: What is blocking your work? What should be resolved in the wider community. 00:29:16 Riju: I would like other vendors to implement. Hoping to leverage new connections with privacy folks. 00:30:11 Anssi: We would like to hear from other vendors so we can solve technical issues. 00:30:28 ... The generic sensors work started with a request from Mozilla. 00:30:46 ... The original device orientation API provided a very minimal configuration surface, underspecified. 00:30:57 ... AnneVK suggested we should do something better. 00:31:57 flaki: In general there is a lot of concern on Mozilla's side on allocation of resources for implementation as well as a concern for privacy. 00:33:07 Anssi: Recognizes that privacy is a focus of Mozilla and Apple's browsers. We have invited university researchers to present to us on privacy of this API. 00:33:15 wonsuk__ has joined #dap 00:33:32 ... We want to break down privacy concerns into actionable items and make sure mitigations are in place. 00:33:48 ... Riju and Reilly developed a technical measure against ALS-based attacks. 00:34:10 Riju: Yes, we added mitigation against using ALS to skim PIN codes being entered on the device. 00:34:39 ... Readouts are limited to an accuracy of 50 lux. Output needs to vary by more than 25 lux before a new value is available. 00:34:52 flaki: It's always a fight between accuracy and use of the API. 00:35:02 Riju: Feedback from developers is that this mitigation doesn't prevent their use cases. 00:35:55 flaki: Use case for more raw data from folks who are trying to build their own sensor fusion, separated from other use cases. 00:36:06 ... Hardware world is moving that processing into drivers and hardware. 00:36:32 s/Scribe: Reilly// 00:36:33 RRSAgent, draft minutes v2 00:36:33 I have made the request to generate https://www.w3.org/2019/09/19-dap-minutes.html xfq 00:36:52 Riju: For the new Generic Sensors API we have more configuration knobs so we can understand exactly what kind of capability the site really needs (high or low frequency, etc.) 00:38:16 i/anssik: Hello,/scribenick: reillyg 00:38:16 Anssi: By definition low level APIs expose more granularity. There could be some innovation in how you acquire user consent. IF you get low level access there could be more user consent in place. For high-level data threats may not apply and so lower consent needed. 00:38:17 RRSAgent, draft minutes v2 00:38:17 I have made the request to generate https://www.w3.org/2019/09/19-dap-minutes.html xfq 00:38:40 flaki: Consent is complicated and questionably effective. 00:39:12 ... I'm generally on-board with this kind of ramp-up model for capabilities and consent. 00:39:41 ... I'm not familiar with the research in this area and they are not as trivial as they seem. 00:40:11 Anssi: Personally I prefer making the common case simple for dev and user. Make advanced use cases possible but they don't need to be easy. 00:40:37 ... As that applies to privacy, the advanced use case that requires more privacy should require more advanced prompting. 00:40:49 ... The common use case should have a smoother UX if the threat level is low. 00:41:15 Riju: Intel has a sensor hub (ISH) where all the processing happens in hardware and drivers. 00:42:32 flaki: The WebXR polyfill is a good example of the power of the extensible web manifesto. 00:43:05 ... On the other hand the web is not native. You can get away with high accuracy data. The web can't get away with that. 00:43:20 Riju: We shouldn't say what is allowed. We should give options. 00:43:43 flaki: This isn't boolean. 00:43:48 Anssi: Yes, this isn't boolean. 00:44:01 ... Multiple low risk sensors together might be high risk. 00:44:47 Anssi: Invited research coming later. Marian, from Newcastle University, is doing device sensor privacy research. 00:45:57 s/Marian/Maryam/ 00:46:05 reillyg: We're now deep into this Generic Sensors discussion. 00:46:13 Topic: Generic Sensors API 00:47:03 Riju: Proximity implemented as a WIP change and waiting on use cases/develeoper partners. 00:47:18 ... ALS has seen progress on mitigations and has developer interest. 00:47:49 Tom: We tried to get internal (Google) customers interested. 00:48:19 ... For external partners we struggle to prioritise features to introduce to them given their resource limitations. 00:48:51 Riju: Reached out to developers and saw nice-looking demos but couldn't see anything useful. 00:49:14 ... One use case is iProov. They do 3D face recognition for authentication. 00:50:29 ... Not pushing Magnetometer right now. Chatted with the Chrome Security & Privacy team. Might need to revisit mitigations. 00:50:53 Anssi: Anything that would help with this from a spec perspective or is it an implementation concern? 00:51:24 Riju: WebXR isn't interested in Magnetometer anymore. 00:51:46 Anssi: Has seen other cases of gesture recognition using this sensor. 00:51:58 Present+ Ehsan_Toreini 00:52:27 Ehsan: I come from Newcastle University. My field is cybersecurity-related protocol design. 00:52:38 ... We analyzed various attacks through sensors on the web. 00:52:56 ... We are here to describe security and privacy aspects of sensors. 00:53:27 Ovidio: I work at Google with Reilly on device APIs. This is my first TPAC. 00:53:40 ... Most of my work has been on WebUSB and Web Bluetooth. 00:54:13 ... I've done some permissions UX work. I'm interested in how the UI for these sensor permissions should be done. 00:54:43 Anssi: It would be great to see Namrata (Google UX)'s presentation materials from last week here in this group. 00:55:02 xfq: I have been the team contact for this group for the past 2 years. 00:55:19 ... We are very interested in hearing more feedback from other engines re: the work in this group. 00:55:35 ... If you need any help from the W3C team on logistics or process feel free to contact me. 00:55:58 Kris: I'm here to observer and see what you guys do in this group. 00:56:10 ... I am a researcher at Trinity University in Dublin. 00:56:22 ... I'm interested in smart-buildings and adaptive services. 00:57:12 rrsagent, make minutes 00:57:12 I have made the request to generate https://www.w3.org/2019/09/19-dap-minutes.html xfq 00:57:24 rrsagent, make minutes v2 00:57:24 I have made the request to generate https://www.w3.org/2019/09/19-dap-minutes.html xfq 00:57:24 s/Topic: Generic Sensors API// 00:58:27 s/Agenda bashing/Intros/ 00:58:32 Topic: Agenda 00:59:39 Anssi: Presenting the set of specifications that are in scope. 01:00:49 ... w3.org/das/roadmap 01:04:52 Topic: Permissions UX 01:05:33 Tom: For context, in Chrome we have a number of different reviews including UX, Security and Privacy. 01:05:56 Ovidio: Presenting slides from the Fugu Summit last week originally presented by Namrata. 01:13:12 Anssi: On defaults, these are something that each vendor can decide for themselves. 01:13:20 RRSAgent, draft minutes v2 01:13:20 I have made the request to generate https://www.w3.org/2019/09/19-dap-minutes.html anssik 01:15:17 Reilly: So as an example, Chrome is working through shifting the defaults for sensors. 01:15:43 flaki: For new APIs shifting the default shouldn't be as difficult because the API has been designed from the beginning to support permissions. 01:16:26 Tom: Why did Apple build a separate static method for sensor permissions rather than integrate with the Permissions API. 01:16:57 Anssi: Apple doesn't ship the Permissions API, a static method was a compromise. 01:18:42 reillyg: from developer perspective, good to have a consistent way to manage permissions, also reduces spec language duplication, understanding cross-browser consensus is important 01:19:16 tom: does Chrome implement both status requestPermission() and Permissions API's corresponding mechanism together? 01:19:37 reillyg: will need to look into that 01:22:10 Reilly: There doesn't seem to be much investment into the Permissions API given lack of consensus. 01:22:23 Tom: From a developer perspective the lack of consistency is confusion. 01:22:29 s/confusion/confusing/ 01:27:49 flaki: Scope of file system permission is comparable to combining multiple sensor types. 01:28:03 ... We need further research into how to message these to users effectively. 01:28:48 Ehsan: Permissions like camera are obvious, the consequences of sensors are not. 01:29:39 Anssi: We need greater diversity of expertise to solve these problems. 01:31:49 ... We should message to users how long permissions will be granted. 01:32:19 Ovidio: There have been discussions in Chromium that we should have temporary permissions. Everyone agrees that we should try it 01:32:58 RRSAgent, draft minutes v2 01:32:58 I have made the request to generate https://www.w3.org/2019/09/19-dap-minutes.html anssik 01:43:20 Ovidio: (Wrapping up presentation) the important thing is showing what is being granted, to whom and how long. 01:43:34 ... We will work on making these slides public. 01:58:10 kip has joined #dap 02:05:40 xfq has joined #dap 02:20:40 Present+ Kearwood_Gilbert 02:21:12 Present+ Henricus_Cabanier 02:21:29 RRSAgent, draft minutes v2 02:21:29 I have made the request to generate https://www.w3.org/2019/09/19-dap-minutes.html anssik 02:25:01 scribeNick: anssik 02:25:08 Battery Status API question on Twitter: https://twitter.com/jsscclr/status/1174469243582078977 02:25:11 present+ 02:25:16 Topic: Generic Sensor API 02:26:31 reillyg: first issue Add API for requesting permission https://github.com/w3c/sensors/issues/388 02:27:18 ... Permissions API lack of consensus, so this issue asking if the Generic Sensor API should add its own requestPermission() similarly to DeviceOrientation, Notifications 02:28:24 ... proposing we should do this, if the method is defined in a similar way as in Permissions API, implementation could be reused/shared 02:28:34 QingAN has joined #dap 02:28:51 ... Permissions API is a generic API for requesting permissions, API exposed on navigator.permissions 02:29:43 ... Generic Sensor API could provide a requestPermission() that hooks into the Permissions API implementation on those implementations that currently implement that API 02:30:08 ... other vendors' position on Permissions API informs the approach this group should take 02:31:08 tom: Permissions API enables bundling, we bundled low-level sensors accelerometer, gyroscope, magnetometer under one high-level sensors bundle 02:32:17 reillyg: today in Chrome you have a permission for "sensors" that grants access to accelerometer, gyroscope, orientation sensor, however it is implemented in such a way that we can surface low-level permissions as needed 02:35:10 reillyg: I can back off a bit from my comment that Sensor.start() should not have side-effects 02:38:11 tom: I'm torn between bundling, closing roads to that future 02:41:01 reillyg: Chromium moving to "ask by default" so would need something like this, Apple is in "ask by default" or "block by default", Mozilla's position needs to be checked 02:46:24 https://w3c.github.io/sensors/#api 02:47:34 PROPOSED RESOLUTION: Close issue #388 without adding a static `requestPermission()` API. Relying on the existing side-effects in `Sensor.start()` and the Permissions API for more advanced use cases such as permissions bundling. 02:48:15 RESOLUTION: Close issue #388 without adding a static `requestPermission()` API. Relying on the existing side-effects in `Sensor.start()` and the Permissions API for more advanced use cases such as permissions bundling. 02:48:29 RRSAgent, draft minutes v2 02:48:29 I have made the request to generate https://www.w3.org/2019/09/19-dap-minutes.html anssik 02:48:49 https://www.w3.org/2019/09/19-dap-minutes.html#x05 02:50:56 anssik: discussing features in-scope for CR re-enter (since last CR added WebDriver Extension API) 02:51:28 xfq: I asked the group to consider to re-enter CR since we're behind the roadmap 02:51:47 ... we're of course waiting for more implementations 02:52:19 reillyg: Generic Sensor API, Accelerometer, Gyroscrope and Orientation Sensor are feature complete 02:53:01 ... for ALS, Proximity, Magnetometer, do we need to include further Security and Privacy input before declaring feature completeness and re-enter CR 02:54:44 anssik: any objections to re-publish CRs? 02:55:00 ... specifically, CRs of Generic Sensor API, Accelerometer, Gyroscrope and Orientation Sensor 02:55:29 PROPOSED RESOLUTION: Re-publish CRs of Generic Sensor API, Accelerometer, Gyroscrope and Orientation Sensor 02:56:29 [no concerns] 02:56:32 RESOLUTION: Re-publish CRs of Generic Sensor API, Accelerometer, Gyroscrope and Orientation Sensor 02:56:39 RRSAgent, draft minutes v2 02:56:39 I have made the request to generate https://www.w3.org/2019/09/19-dap-minutes.html anssik 02:57:08 https://github.com/w3c/sensors/issues/13 02:57:17 Allowing data batching when poll frequency < sensor frequency #13 02:58:45 reillyg: related with workers, batching, high frequency 02:59:14 ... can react to sensor events when the main thread is busy, there are couple of solutions, input stack uses a concept of batching 02:59:54 ... that's something we could adopt for sensors as well, there's also a question in general on the recommended pattern of using this API over DeviceOrientation, it does not need to be event-driven 03:00:12 ... for example in an event loop you may want to read the sensor reading 03:00:29 ... issues around data batching are implementation questions mostly, that is an important thing to have in the spec 03:02:27 ... if you look at this #13 in contrast to #171, the latter seems duplicate 03:02:53 ... #171 is a Level 2 issue that is premised on a fact that high freq data is available 03:03:32 ... this suggest we leave #13 to be, since no strong use cases for high frequency readouts, and WebXR work is ongoing now, so may not be needed for that 03:04:36 PROPOSED RESOLUTION: Allowing data batching when poll frequency < sensor frequency #13 maintains it Level 2 status, awaits use cases 03:08:10 Ehsan: privacy-related information is already leaking at lower frequency, so that'd be amplified with high frequency polling 03:08:32 [no concerns with proposed resolution] 03:08:37 RESOLUTION: Allowing data batching when poll frequency < sensor frequency #13 maintains it Level 2 status, awaits use cases 03:08:54 s/it Level 2/its Level 2/ 03:09:02 RRSAgent, draft minutes v2 03:09:02 I have made the request to generate https://www.w3.org/2019/09/19-dap-minutes.html anssik 03:09:36 Topic: Geolocation API 03:10:19 https://github.com/w3c/geolocation-api/issues/25 is fixed! \o/ 03:11:31 reillyg: in Chromium we've used CSP for restricting access to iframes 03:11:53 ... it sounds like we have implemented this restriction in Chromium, but there's no such language in the spec 03:13:08 reillyg: do you block Geolocation API in x-origin frames? I recall Feature Policy is not Mozilla-preferred mechanism 03:13:31 s/used CSP/used Feature Policy/ 03:14:32 Flaki: there's a Mozilla bug for this, closed 9 days ago! 03:14:58 ... another bug related to Feature Policy in this context, fixed in Firefox 71 03:15:56 PROPOSED RESOLUTION: Add Feature Policy integration into Geolocation API to match Chromium and upcoming Firefox 03:16:18 PROPOSED RESOLUTION: Add Feature Policy integration into Geolocation API to match Chromium and upcoming Firefox (fixes issue #10) 03:16:44 The bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1579373 (fix landed, slated for Firefox 71 and expected to go stable at the end of this year,) 03:17:33 anssik: will lack of WebKit's Feature Policy implementation cause an interop issue here? 03:18:25 WebKit's status on Feature Policy: https://bugs.webkit.org/show_bug.cgi?id=187816 (not implemented currently) 03:18:48 reillyg: FP can default to same-origin, that's how we'd spec it for this API, so if Apple blocks x-origin, it would breaks sites that expect to grant access to x-origin subframe 03:20:03 tom: in this case no breakage, if it is not allowed [in WebKit]? 03:21:33 RESOLUTION: Add Feature Policy integration into Geolocation API to match Chromium and upcoming Firefox (fixes issue #10) 03:21:41 RRSAgent, draft minutes v2 03:21:41 I have made the request to generate https://www.w3.org/2019/09/19-dap-minutes.html anssik 03:21:56 https://www.w3.org/2019/09/19-dap-minutes.html#x09 03:23:04 reillyg: https://github.com/w3c/geolocation-api/issues/11 is a duplicate of #25 that we discussed just a minute ago 03:23:51 WebKit currently allows x-origin iframe geolocation requests, so no breakage: https://stump-product.glitch.me 03:26:14 reillyg: https://github.com/w3c/geolocation-api/issues/12 was resolved by https://github.com/w3c/geolocation-api/pull/34 03:26:37 Firefox also allows x-origin access 03:27:29 https://github.com/w3c/geolocation-api/issues/24 03:28:22 anssik: spec language issue related to WebIDL, no implementation impact, just work that needs to be done 03:29:01 ... https://github.com/w3c/geolocation-api/pull/20 was finally landed in Chromium, also Gecko implemented this as well as WebKit 03:29:39 ... Plan to publish a revised Rec? 03:30:27 anssik: https://www.w3.org/TR/geolocation-API/ is not reflecting reality anymore 03:31:05 reillyg: let's fix #24 and then re-publish 03:31:28 xfq: we need to go back to CR and Rec 03:31:36 anssik: do we need to do wide review? 03:31:45 reillyg: changes are around security 03:32:14 xfq: wide review for the diff is enough 03:32:44 PROPOSED RESOLUTION: Publish CR and then Rec after fixing issue #24, wide review for the diff to previous Rec 03:33:21 [no concerns with the publication plan] 03:33:26 RESOLUTION: Publish CR and then Rec after fixing issue #24, wide review for the diff to previous Rec 04:07:11 yoshiaki_ has joined #dap 04:10:13 zkis has joined #dap 04:32:59 xfq has joined #dap 04:33:03 Zakim has left #dap 04:34:41 Present+ Mariko_Kosaka 04:37:38 yoshiaki has joined #dap 04:38:48 scribeNick: reillyg 04:39:21 Topic: Geolocation Sensor 04:40:03 Present+ Maryam_Mehrnezhad 04:41:13 Anssi: Background, Geolocation API is the currently shipping API with consensus that we are not adding new feature but have resolved a few issues to strengthen security and privacy. 04:41:52 Riju has joined #Dap 04:42:12 ... GeolocationSensor is a new API shape taking advantage of the Generic Sensor API structure and solutions to existing problems. 04:43:33 Tom: My interest in coming to this specification is from background geolocation. The core specification was already there. 04:43:51 ... Outstanding issues to discuss: 04:44:04 ... 1. Accuracy 04:44:28 Riju_ has joined #Dap 04:44:31 yoshiaki_ has joined #dap 04:44:47 ... Specification should be informed by what it technically feasable. 04:44:57 [tom discussing Geolocation Sensor features that are work-in-progress, outlined at https://github.com/w3c/devicesensors-wg/issues/24#issuecomment-506748290] 04:45:22 yoshiaki_ has joined #dap 04:45:44 Maryam: Are these standards-level questions to resolve or is it up to implementers? 04:46:08 Anssi: The previous API was underspecified. This new API provides the developer more control. 04:46:09 yoshiaki_ has joined #dap 04:47:32 Reilly: More information from developers (better API) allows implementations to make better decisions. 04:48:27 Anssi: This stage of specification is a good opportunity to suggest changes. 04:49:24 Tom: From the start this API had the concept of fuzzing a location. 04:50:06 ... That idea was abandoned as infeasible because "city-level" depends on density (Tokyo vs. rural America). 04:50:42 ... 3. Worker 04:50:48 ... Relatively straightforward. 04:51:02 ... 4. Foreground tracking 04:52:50 Anssi: Frequency, accuracy, latency, are all correlated. 04:57:25 Anssi: One-shot readings are specifically included in the GeolocationSensor interface. 04:57:34 Reilly: This could also be useful for orientation sensors. 04:57:38 RRSAgent, draft minutes v2 04:57:38 I have made the request to generate https://www.w3.org/2019/09/19-dap-minutes.html anssik 04:57:48 Tom: 7. Background tracking 04:58:04 ... This could be a better for wake lock. 05:01:45 ... If there is a `geo` wake lock then we could offload to the hardware to do tracking and not keep the site itself awake. 05:01:58 Tom: 8. Background geofencing 05:02:35 ... Notification triggers are specified generically, they could be geofences. 05:03:55 Reilly: A background location tracking API could look similar to an event batching API discussed previously. 05:04:03 Tom: 9. Power saving 05:05:14 Maryam: Feedback from users is that apps in stores are approved by Google, Apple, etc. Whereas websites are not approved and would be concerned by background tracking. 05:06:03 Tom: System Wake Lock is not currently enabled precisely because we are not yet sure of the permission model. 05:09:26 Reilly: We are working on adding app-like UX to web applications with Installable PWAs. 05:09:45 ... Also on Chromium we have a site engagement score which could be used as a signal. 05:10:05 Maryam: Do we have research into how user trust of a site adjusts when it is installed? 05:10:13 Present+ Vincent_Scheib 05:10:33 Tom: As a developer site engagement is difficult because of a lack of predictability. 05:11:14 Present+ Sudeep_Divakaran 05:14:20 satakagi_ has joined #dap 05:15:10 Anssi: As something to study, why do users trust applications that are in the store? It is human review? Association with a known brand? The flow of installation itself? 05:16:03 Maryam: This shifts over time with generations, but generally people trust app stores no matter the process. It appears to be the branding of the store itself. 05:17:28 ... Are stores planning to inspect the code for PWAs in app stores? 05:17:42 Tom: To some extent, possibly black-box testing. 05:17:53 Present+ Sangwhan_Moon 05:18:39 ... PWAs on the app store are built as TWAs which have to go through the normal review process. 05:19:36 RRSAgent, draft minutes v2 05:19:36 I have made the request to generate https://www.w3.org/2019/09/19-dap-minutes.html anssik 05:21:19 Reilly: Next steps for work appear to be geofencing (through Notification Triggers) and foreground tracking with more expressive configuration. 05:21:32 Tom: Could we implement expressive configuration in the original specification? 05:22:10 Anssi: It would be more digestible for existing implementations to iterate on the original specification? 05:23:19 PROPOSED RESOLUTION: Explore retrofitting expressive configuration of foreground tracking into the Geolocation API specification. 05:24:15 scheib has joined #dap 05:24:21 s/expressive configuration/expressive configuration (Tom's comment on #24 items 1..5)/ 05:24:53 PROPOSED RESOLUTION Explore retrofitting expressive configuration (Tom's comment on #24 items 1..5) of foreground tracking into the Geolocation API specification. 05:25:28 RESOLUTION: Explore retrofitting expressive configuration (Tom's comment on #24 items 1..5) of foreground tracking into the Geolocation API specification. 05:25:40 [sangwhan agrees] 05:29:21 satakagi has joined #dap 05:29:33 scribeNick: anssik 05:29:34 Topic: Device Orientation Event 05:29:46 reillyg: a number of issue, we'll work them one by one 05:30:37 ... issue #74 asks for clarification of behavior of the Permissions API 05:31:06 ... which event to fire when permission is granted, when to throw exception if not granted 05:31:30 ... Safari implements this API 05:32:00 yoshiaki_ has joined #dap 05:32:26 ... we need to spec more precisely the details raised in #74, once we have another implementation we should be able to resolve this with implementation experience from two implementions 05:35:28 anssik: the group agrees #74 this is spec work that is blocked on Chromium being the second implementation 05:35:46 reillyg: https://github.com/w3c/deviceorientation/issues/70 is kind of related with #74 05:36:36 s/related with #74/related with Generic Sensor API issue #388/ 05:37:21 riju: talked with Firefox folks why they do not implement Permissions API 05:38:30 sangwhan: there's design disagreement, TAG has an action to look at aligning "Permission-like" APIs 05:39:17 tom: permissions are currently something UAs do as they want, any TAG interest to get people together to agree on the permissions UX and related APIs, incl. permissions bundling 05:39:46 sangwhan: yes, but it is complicated, since browsers and OSs have different permission models and UX 05:40:19 ... bringing a lot of new features to the Web means this requires attention to avoid prompt fatigue 05:40:28 ... diss discuss this with mwest 05:40:34 s/diss/will/ 05:40:53 yoshiaki has joined #dap 05:41:10 reillyg: issue #70 can potentially wait until we have clarity on the status of Permissions API 05:41:21 sangwhan: agree, not critical 05:41:49 ... another issue related to WebXR that exposes sensors, a different permission from sensor APIs, or is an OR gate 05:43:01 reillyg: right answer might be to have a token per each API, and for WebXR have "webxr" token, and leave it to UAs to decide how to communicate that to the users; API needs to be expressive enough so that implementations can communicate the need to users in an understandable way 05:43:28 sangwhan: TAG would like to hear your feedback on this matter 05:43:57 reillyg: you should be able to express the need "I need geolocation every 15 meters with an accuracy of 5 meters" 05:44:17 sangwhan: similar this in media 05:44:22 anssik: constraints model? 05:44:25 sangwhan: right 05:44:33 ... also a similar pattern exists in audio 05:44:49 maryam: do web sites explain why they want this particular permission? 05:45:11 reillyg: in some native app platforms it is possible to add a custom string into the permission prompt 05:45:40 ... this is possible on iOS and not on Android, not on the Web. 05:46:03 sangwhan: that is not very useful feature, people would just use "just press yes" on the Web 05:46:30 maryam: studies show explaining the reason for permission in the context of permission request is helpful for the user 05:47:35 Riju has joined #dap 05:47:57 anssik: on the web there's an emerging pattern of an onboarding page that explains why the permission is needed just before a prompt is shown 05:48:43 tom: problem is people can lie what the reason is for permission request, on the web there's no review process 05:51:00 PROPOSED RESOLUTION: For issue #70 wait until we have clarity on the status of Permissions API. 05:51:10 RESOLUTION: For issue #70 wait until we have clarity on the status of Permissions API. 05:51:11 Publishers ask for notification permission on page load because the opt-in rate in A/B tests was higher than in contextual asking. What the blindspot of these A/B tests is is that users then block the notifications once the first (spammy) notification arrives. 05:51:29 (On Chrome, we have started mitigations against this) 05:51:38 PermissionState enum already defined in Permission API #82 05:51:53 RRSAgent, draft minutes v2 05:51:53 I have made the request to generate https://www.w3.org/2019/09/19-dap-minutes.html anssik 05:52:28 https://github.com/w3c/deviceorientation/issues/82 05:53:47 reillyg: seems we can just spec this out 05:54:06 anssik: Chris of Apple agrees, no change on WebKit implementation 05:54:47 PROPOSED RESOLUTION: Re-use the PermissionState enum from the Permissions API (fixes issue #82). 05:54:56 [no concerns] 05:55:02 RESOLUTION: Re-use the PermissionState enum from the Permissions API (fixes issue #82). 05:55:52 RRSAgent, draft minutes v2 05:55:52 I have made the request to generate https://www.w3.org/2019/09/19-dap-minutes.html anssik 05:56:06 https://www.w3.org/2019/09/19-dap-minutes.html#x15 05:56:45 reillyg: Integration with Feature Policy 05:57:19 ... Chromium does Feature Policy, Safari and Firefox comply with the default Feature Policy 05:57:30 ... proposing we spec this using Feature Policy 05:57:54 https://github.com/w3c/deviceorientation/issues/64 05:58:42 PROPOSED RESOLUTION: Add integration with Feature Policy (fixes issue #64). 05:59:24 PROPOSED RESOLUTION: Specify and add integration with Feature Policy into Device Orientation Event specification (fixes issue #64). 05:59:51 PROPOSED RESOLUTION: Specify and add integration with Feature Policy using ["self"] as an allowlist into Device Orientation Event specification (fixes issue #64). 06:00:09 yoshiaki has joined #dap 06:00:17 [no concerns] 06:00:23 RESOLUTION: Specify and add integration with Feature Policy using ["self"] as an allowlist into Device Orientation Event specification (fixes issue #64). 06:00:43 reillyg: compassneedscalibration implementation experience 06:00:58 RRSAgent, draft minutes v2 06:00:58 I have made the request to generate https://www.w3.org/2019/09/19-dap-minutes.html anssik 06:01:28 https://www.w3.org/2019/09/19-dap-minutes.html#x16 06:01:54 reillyg: https://github.com/w3c/deviceorientation/issues/38 only implemented by IE, should we remove it from the spec? 06:03:21 anssik: this has been open for ~3 years with no feedback 06:04:26 anssik: couldn't this just be delegated to the underlying platform API and a native UI? 06:05:14 reillyg: options: 1) do nothing, 1) use platform UI, or 3) expose the event and allow custom web calibration UI 06:05:39 tom: on iOS there's a low-level system thing that triggers platform UI 06:05:57 https://developer.apple.com/documentation/corelocation/cllocationmanager/1620563-dismissheadingcalibrationdisplay 06:06:45 maryam: OSs and/or hardware do this automatically, I think 06:07:06 reillyg: proposal to leave this issue open 06:07:45 RRSAgent, draft minutes v2 06:07:45 I have made the request to generate https://www.w3.org/2019/09/19-dap-minutes.html anssik 06:08:07 https://github.com/w3c/deviceorientation/issues/33 06:08:14 Security/privacy consideration: cross-origin linkage #33 06:09:00 reillyg: global state is the generic issue, orthogonal with iframes, with multiple tabs open they get the same data, should we restrict to visible content only, not an issue on mobile since only one visible at the time 06:10:21 ... the existing Permissions API work does not resolve this issue 06:12:39 ... Chromium implementation restricts the DeviceOrientation/MotionEvents to visible browsing context. 06:13:48 anssik: we should probably specify this? 06:13:59 reillyg: should look at x-browser compatibility 06:14:41 anssik: Generic Sensor API has a mitigation in place for this, spec'd and implemented 06:14:52 reillyg: iframe case was only implemented recently 06:15:49 PROPOSED RESOLUTION: Restrict DeviceOrientation to visible browsing context, borrow language from Generic Sensor API (fixes issue #33). 06:16:26 [no concerns] 06:16:29 RESOLUTION: Restrict DeviceOrientation to visible browsing context, borrow language from Generic Sensor API (fixes issue #33). 06:16:44 https://github.com/w3c/deviceorientation/issues/30 06:16:50 Malicious use of the phone's Gyroscope #30 06:19:11 reillyg: mitigations are moving these to permissions that are not allowed by default, reducing sampling rate is not enough 06:28:46 rakuco has joined #dap 06:29:53 tomayac has joined #dap 06:41:41 is webex supposed to be working? I've joined the conference but don't hear anyone 06:43:45 zkis_ has joined #dap 06:50:28 Present+ Balazs_Engedy 06:51:05 scribeNick: reillyg 06:52:05 Topic: Privacy and Security 06:53:40 Slide: A Systematic Approach to Minimize the Risks of Mobile Sensors 06:54:17 A handout has been passed around summarizing the sensors currently exposed on native and web platforms. 06:54:50 Slide: Sensors access via Android, iOS, and Browsers 06:55:38 Maryam: We have implemented attacks using artificial intelligence to recover sensitive information. 06:55:53 ... My understanding is that the web is trying to become as powerful (or more powerful?) as native apps. 06:56:22 Anssi: We can never reach parity because we run on those platforms but we want to reduce incentive for developers to target native over web while balancing security and privacy. 06:56:33 Riju has joined #dap 06:57:58 Maryam: Categorization of sensors is controversial but these 4 groups make it easier to consider the way that users interact with consent. 06:58:18 Anssi: Are these 4 sensor categories what users understand? 06:59:16 Maryam: People are much more concerned about ID and Comm sensors even though motion sensors can also be used to detect user location. 06:59:39 ... The actual risks might not match the users' perceived risks. 07:00:08 ... Are all these sensors in scope for this group? 07:00:44 Anssi: Motion and ambient are in scope for this group but members of this group also work on NFC and Bluetooth. 07:01:52 RRSAgent, draft minutes v2 07:01:52 I have made the request to generate https://www.w3.org/2019/09/19-dap-minutes.html anssik 07:02:46 james has joined #dap 07:02:49 James_Hollyer: Fitness sensors, such as heart rate, use Bluetooth and so are already covered by Web Bluetooth. 07:03:22 Maryam: Insurance companies are very interested in health information and that can have negative consequences. 07:04:08 present+ James_Hollyer 07:04:44 Reilly: Most of these sensors are in scope for this group but they are blocked by this kind of security and privacy work. 07:06:00 ... Intel has an implementation of depth camera support in Chrome but depth cameras are currently rare. 07:06:50 Slide: History and Facts 07:10:21 flaki: In Accessibility WG it was mentioned that this sensor data can be used to detected disabilities. 07:11:17 Maryam: GDPR has highlighted these issues. 07:11:32 scheib: For big companies GDPR has been implemented worldwide. 07:12:09 Maryam: The GDPR doesn't specifically speak to sensor data and whether or not it is personal data. 07:13:02 Tom: Does GDPR imply sensors in any way? 07:13:10 Maryam: It is unclear. I am not a lawyer. 07:16:02 scheib: Every company needs to make its own legal determination. I suspect that many companies would assume that sensor data is personal data to ensure compliance. 07:16:12 ... Within this group we should take the approach that this is personal data. 07:16:43 Maryam: If we are doing authentication using motion sensor data then this is personal data. 07:17:34 Slide: Research Questions 07:18:42 Maryam: Academia has come up with a number of attack. We don't know if these attacks are practical in a real world setting. 07:19:08 Anssi: We were unable to reproduce a number of these results, even in a controlled setting. 07:20:15 Maryam: Most of these papers and my own word use AI techniques. 07:23:21 ... I want to focus strongly on building solutions that provide a good UX. 07:25:43 Reilly: You mention cross-platform differences are frustrating? Do you see users using multiple platforms and devices? 07:26:04 Maryam: Yes, users may in use multiple browsers or have multiple mobile platforms in their family. 07:26:38 "TouchSignatures: Identification of User Touch Actions based on Mobile Sensors via JavaScript" https://arxiv.org/pdf/1602.04115.pdf 07:26:41 Anssi: The takeaway for this group is that the permissions UX is important across browsers. 07:26:47 Related: Privacy Threat Model proposed this TPAC: https://cryptpad.w3ctag.org/code/#/2/code/edit/NLylvy0EoY8ILUwfjq8wBOSQ/ 07:27:23 scheib: This group should be aware that the Privacy Threat Model is relevant. 07:27:41 ... From a research point of view it is an opportunity to contribute in a formal way. 07:27:54 RRSAgent, draft minutes v2 07:27:54 I have made the request to generate https://www.w3.org/2019/09/19-dap-minutes.html anssik 07:27:55 https://w3cping.github.io/privacy-threat-model/ 07:29:26 Privacy Budget: https://cryptpad.w3ctag.org/code/#/2/code/edit/5oNjMaFJJM3W8ar5LOiiLmZR/ 07:30:21 Deep link to the Explainer: https://github.com/bslassey/privacy-budget 07:31:34 Maryam: Do our current permissions actually empower users? 07:33:06 Slide: Safe-zone sensors sampling rates 07:33:56 Slide: Is AI a solution? 07:36:51 Reilly: What kind of data would be used to train such a system? 07:37:04 Maryam: We don't know at this point. It is just a suggestion. 07:37:24 Tom: Going back to "safe zone," it could probably still be used as a fingerprinting mechanism. 07:41:04 Balasz: It's unclear to us whether there is anything that is safe and also useful. 07:42:52 Balasz: Even a low-accuracy rate while delivered off would be in conflict with a user's preference if they select "off" for a given sensor. 07:43:44 Reilly: If we had low-acc and high-acc sensors we would still have an off mode that was really off. The default would just be low-acc. 07:43:50 s/delivered off/delivered when the permission is off/ 07:45:51 Balazs: Have you done research on the best tone to use when communicating risks to users? 07:46:01 s/Balasz/Balazs/ 07:46:30 Maryam: No, this is a future work item. I haven't seen any research that specifically looks at sensors. 07:46:42 Tom: There is research on certificate warnings by Emily Stark at Google. 07:46:58 https://acmccs.github.io/papers/p1407-acerA.pdf 07:49:43 scribeNick: anssik 07:49:58 WakeLock and Page Life Cycle 07:50:14 https://github.com/w3c/wake-lock/issues/139 07:51:07 anssik: As of currently spec'd, losing focus e.g. switching tabs will cause the screen wake lock to reject. 07:51:24 ... Options: keep current behavior, auto acquire when returning to the tab. 07:51:40 reillyg: connection with Page Life Cycle is a bit red herring 07:52:00 ... there are situations where wake lock is automatically released by the system, should also be acquired automatically? 07:52:30 I have created a quick demo that shows the behavior: https://wake-lock-demo.glitch.me/ 07:52:41 ... it adds complexity to API to acquire it but not really 07:53:27 rakuco: should discuss if it makes sense to add an option per kenneth's suggestion or keep current behavior 07:53:36 tom: pasted a demo link that shows the behavior 07:55:25 reillyg: there's a short period when it is invisible when transitioning to full screen, also when pulling out a tab from the tab strip 07:56:05 ... related to a bug filed against the Chromium implementation of this feature a few days ago 07:56:58 q+ 07:57:03 q? 07:57:28 Zakim has joined #dap 07:57:31 q+ odejesush 07:57:52 ack odejesush 07:58:17 Edit link: https://glitch.com/edit/#!/wake-lock-demo 08:00:06 reillyg: concern is, auto acquire mode means we have wake locks in this 3rd state that is "acquired, but currently released and waiting to be acquired" 08:04:22 Present+ Marcos_Caceres 08:09:41 anssik: are we optimizing for the common use case as we should? 08:09:51 ... Google Slides etc. 08:10:04 marcos: I'm not seeing the JS required as an issue 08:11:37 I want to discuss https://github.com/w3c/wake-lock/issues/226 08:11:38 PROPOSED RESOLUTION: Decided to keep the internal state of the API simple, tab change does release the lock (closes issue #139) 08:11:46 PROPOSED RESOLUTION: Keep the internal state of the API simple, tab change does release the lock (closes issue #139) 08:12:38 PROPOSED RESOLUTION: Keep the internal state of the API simple, tab change does release the lock, add informative prose to the spec to show how to reacquire the lock (closes issue #139) 08:12:51 [no concerns] 08:12:58 marcos: ship it! 08:13:04 RESOLUTION: Keep the internal state of the API simple, tab change does release the lock, add informative prose to the spec to show how to reacquire the lock (closes issue #139 08:13:28 RRSAgent, draft minutes v2 08:13:28 I have made the request to generate https://www.w3.org/2019/09/19-dap-minutes.html anssik 08:14:53 WakeLock.request() returns a promise that never resolves 08:16:15 i/WakeLock and Page Life Cycle/Topic: Wake Lock 08:16:23 RRSAgent, draft minutes v2 08:16:23 I have made the request to generate https://www.w3.org/2019/09/19-dap-minutes.html xfq 08:18:27 reillyg: I agree with marcos that we go back to the "old API-style", with single navigator.requestWakeLock() method, fires on all releases. 08:19:47 Present+ James_Hollyer 08:20:53 [reillyg shows another demo code on screen] 08:23:38 reillyg: I wanted the promise guide to give guidance when promises are used in connection with AbortController 08:27:03 [reillyg live-editing code on a big screen in search of a perfect API shape] 08:27:19 [it seems AbortController is now gone] 08:29:15 james: why we need lockId? 08:29:42 reillyg: we can have multiple locks, e.g. screen wake lock and system wake lock, maybe in the future "blue wake lock" that makes the screen blue 08:30:16 tom: can we have two wake locks of the same type? 08:30:25 reillyg: that'd not be useful 08:30:45 RRSAgent, draft minutes v2 08:30:45 I have made the request to generate https://www.w3.org/2019/09/19-dap-minutes.html anssik 08:33:15 reillyg: https://wicg.github.io/web-locks/ API shape does not work for the Wake Lock API 08:35:51 [a ton of API design happening on the big screen, scribe unable to capture the sausage-making process] 08:36:42 flaki: all locks regardless of type, need unique identifiers 08:46:11 the new API surface that the group came up with https://github.com/w3c/wake-lock/issues/226#issuecomment-533032056 08:49:46 rakuco: should the spec clarify how the locks have their ids allocated, or is it implementation specific? 08:50:05 marcos: implementation detail, look for other similar APIs 08:51:45 PROPOSED RESOLUTION: Update the spec per the new API proposal as described in #226 (fixes issue #226) 08:52:03 [any concerns?] 08:52:27 rakuco: kenchris asking about AbortController 08:52:33 marcos: I'll talk to him 08:52:59 In obtain permission: don't co-opt resultPromise - it's creating a custom permission model #198 08:53:04 https://github.com/w3c/wake-lock/issues/198 08:54:31 marcos: do we need permission for this API? 08:54:46 reillyg: we want to go through permissions flow, just in case the user wants to out-out 08:54:57 marcos: what invokes this algorithm? 08:57:07 marcos: step 6.1 of https://w3c.github.io/wake-lock/#request-static-method is in the wrong place 08:59:07 [no concerns recorded for previous proposed resolution, so making it a resolution] 08:59:17 RESOLUTION: Update the spec per the new API proposal as described in #226 (fixes issue #226) 09:01:23 s$marcos: step 6.1 of https://w3c.github.io/wake-lock/#request-static-method is in the wrong place$$ 09:01:37 rrsagent, make minutes v2 09:01:37 I have made the request to generate https://www.w3.org/2019/09/19-dap-minutes.html xfq 09:01:42 RRSAgent, draft minutes v2 09:01:42 I have made the request to generate https://www.w3.org/2019/09/19-dap-minutes.html anssik 09:02:30 s|s$marcos: step 6.1 of https://w3c.github.io/wake-lock/#request-static-method is in the wrong place$$|| 09:02:36 rrsagent, make minutes v2 09:02:36 I have made the request to generate https://www.w3.org/2019/09/19-dap-minutes.html xfq 09:04:22 Topic: Adjour 09:04:27 rrsagent, make minutes v2 09:04:27 I have made the request to generate https://www.w3.org/2019/09/19-dap-minutes.html anssik 09:05:51 s/Topic: Adjour/Topic: Adjourn/ 09:05:53 rrsagent, make minutes v2 09:05:53 I have made the request to generate https://www.w3.org/2019/09/19-dap-minutes.html anssik 09:08:17 dbaron has joined #dap 09:08:29 github-bot, end topic 09:08:37 dbaron has left #dap 09:09:20 yoshiaki has joined #dap 09:11:21 github-bot has joined #dap 11:02:28 zkis has joined #dap 12:33:27 Zakim has left #dap 12:38:19 engedy has joined #dap 13:23:47 satakagi has joined #dap 13:58:44 BitBot has joined #dap 15:05:39 xfq has joined #dap 16:34:57 zkis has joined #dap 20:26:48 zkis has joined #dap 20:42:26 satakagi has joined #dap 21:08:21 zkis has joined #dap 22:21:05 Ralph has joined #dap 22:21:10 rrsagent, bye 22:21:10 I see no action items