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