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