Devices and Sensors WG TPAC F2F - Day 1/2
22 October 2018
anssik: Welcome everyone!
anssik: Hopefully you have time to discover the city before the meeting begins
… now it's the time to focus the time for important stuff
… I'm Anssi Kostiainen from Intel
… the co-chair of the WG
… the other co-chair, Reilly, will join tomorrow
… I'll help with the logistics, letting you better focus on the technical stuff
xfq: I'm Fuqiao from W3C, team contact of the group
Ian: I'm Ian Clelland from Google
cwilso: Chris Wilson from Google
Mounir: Mounir Lamouri from Google
Lars: I'm Lars Knudsen, Invited Expert of the group
Bryan: Bryan Bernhart from Intel
Raphael_Kubo_da_Costa: I'm Raphael Kubo da Costa from Intel
Tatsuhiko_Hirabayashi: I'm Tatsuhiko Hirabayashi
Udana_Bandara: I'm Udana Bandara from @1
Paul: I'm Paul, from Korea
Junghun: I'm interested Junghun, interested in autonomous driving cars
Daniel_Peintner: @2
ThomasTheDane: I'm Thomas Dane from Google
<anssik> Charter
anssik: Nowadays all the scope of the WG is related to the browsers
… let's go to the Deliverables directly
… we have Battery Status API, Wake Lock API, etc.
… for specs in Candidate Recommendation, we're waiting for another implementation, since W3C process requires two independent implementations for a spec to get to REC
… if you scroll down a bit more, we just added Geolocation Sensor to the deliverables of our working group
… later today we'll discuss the Geolocation Sensor spec
… if you scroll down, we need to specify a roadmap of the group (Timeline)
… it's not fixed tho, it is our "wishlist"
… we follow a test as you commit approach
https://github.com/w3c/testing-how-to/#test-as-you-commit
... Network Information API was in DAS (or DAP), but was moved to WICG afterwards
... it's implemented in Chrome currently, and we're waiting for another impl
Lars: @@
<anssik> Roadmap
anssik: this is the roadmap of the group
… it's better to refer than the charter since it's dynamic
… w3.org/das is our homepage
Mounir_Lamouri: most of the specs are in CR
… how many of them are implemented by Chrome
anssik: most (if not all) of them
… please talk to your friends in other orgs to implement the specs, like Mozilla/Microsoft/Apple
<anssik> Agenda
anssik: Do you have any modification to the agenda?
Lars: one of the approaches I'm interested about discovery is in Web NFC
… we can discuss that jointly with WoT people
anssik: Generic Sensor Level 1 is finished (in one browser), we will discuss Level 2 issues
… in the last part of Tuesday, we have DeviceOrientation Event
… it's an old spec, but we still have a few issues, to make it match implementations better
… then we can call this spec done
anssik: There hasn't been much happening in this spec for some time
<anssik> Battery Status API
anssik: Mozilla had concerns regarding fingerprinting
… security researchers found out we can use the API as supercookies
… we had discussion with Mozilla, then Feature Policy came out
<anssik> https://github.com/w3c/battery/pull/13
anssik: I'm drop the link to the diff
… adding the Feature Policy integration section
… in § 5. The Navigator interface, with this proposal, only the top-level origin can access the battery status
… if you want other origins to access it, you need to use Feature Policy
Ian: I reviewed the PR
anssik: Mounir/Ian, I think you have some use counters about this?
anssik: it would be great if someone could check it
anssik: if users embed YouTube as an iframe, there might be problems
Mounir: maybe a large portion of the deprecated usage is fingerprinting
Lars: what YouTube need is if processing power is available
Mounir: that's not the case, it's more like A/B testing
anssik: anyway we need to be good citizens and mitigate the concerns
Mounir: @@
… changing codec might be a valid use case for the API
Resolved: Ian to add telemetry for Battery Status API in Chrome, then talk to YT people
<anssik> Battery Status API v2 issues
https://github.com/w3c/battery/issues/9
anssik: This issue about power saving mode
… does this sound like a useful thing to do? Any concern?
Lars: I think it makes most sense to integrate it with the service worker
<anssik> Expose getBattery to ServiceWorker #4
anssik: we have this long-time issue about background battery
… are you aware of this kind of request from web developers? Any valid use cases?
… do we expose this to other device-ish APIs currently?
… in the workers case, we don't have this issue, since if the tab closes, the worker goes away
… let's break for now and come back in 10:45
[Break]
What if WakeLockRequest is garbage collected?
mounir: there's a spec-compliant implementation in Chrome
https://w3c.github.io/sensors/#sensor-garbage-collection
<mounir> proposed solution: https://github.com/w3c/wake-lock/issues/128#issuecomment-412148397
<kenneth> https://w3ctag.github.io/design-principles/
rakuco: problem similar to Generic Sensor, but in Wake Lock the effect is visible
kenneth: please open an issue against TAG design-principles for the generic CG issue
PROPOSED RESOLUTION: ask TAG for advise regarding the generic CG behavior, open an issue in TAG design-principles
https://w3c.github.io/wake-lock/#managing-wake-locks
<larsgk> In section 6, there is a note that wake lock is applicable if sufficient battery is available - but no mention of bailing out if depleting battery during wake lock
https://w3c.github.io/wake-lock/#dfn-the-wake-lock-is-applicable
anssik: it appears "The wake lock is applicable" https://w3c.github.io/wake-lock/#dfn-the-wake-lock-is-applicable is not referred to from the requesting the wake lock algorithm https://w3c.github.io/wake-lock/#dfn-requesting-the-wake-lock
… that seems to be a spec bug, should open an issue for that
bryan: system level setting for low battery not usually exposed by platform APIs
kenneth: if the wake lock gets released due to device going into power saving mode, need to get notified
<rakuco> TAG design-principle issue filed on behalf of kenneth: https://github.com/w3ctag/design-principles/issues/102
PROPOSED RESOLUTION: invoke onactivechange and set the active attribute to false when the wake lock is not applicable
... (the reason for not being applicable could be low battery, or any other implementation-specific reason)
Resolved: ask TAG for advise regarding the generic CG behavior, open an issue in TAG design-principles
Resolved: invoke onactivechange and set the active attribute to false when the wake lock is not applicable
anssik: is the polyfill using 1x1 autoplay video still working?
mounir: yes it is
<xfq> [Lunch]
[tom presenting slides on Geolocation Sensor]
Geolocation Sensor API Use Cases
[tom walking us through the use cases document]
McCool: question about floorLevel proposal, how do I find out which floor I am on?
kenneth: prefer giving more access to the web developer than the old Geolocation API
bryan: in Edge implementation, we look for the epsilon value to figure out what constitutes a significant change
… this is to save battery life
tom: question on how to signal that the device cannot fulfill the accuracy and/or latency requirements
… think the developer should be informed if the requirements cannot be satisfied
ThomasTheDane: we in Chrome think being installed is one possible signal to consider whether a permission should be persistent, e.g. reopen PWA if granted permission previously, no permission grant
https://w3c.github.io/permissions/#implicit-signals
guido: in sports tracker apps you do not need an UI at all necessarily
tom: one option is to expire permissions after some predefined time
Alex: iOS does provide a banner to revoke permission if an app is using e.g. geolocation in the background
… this banner appears after the app is still using the geolocation after it has been backgrounded
alex: one option would be to show the user a (web) notification if within a geofence, and only expose the coordinates to the web app if the user gives consent via the notification prompt
guido: I think moving this spec forward it is important to have good use cases that cannot be done with the old API
anssik: the group agrees, and that's why the group started with soliciting new use cases
… and then do a decision whether to advance with the solution i.e. the API
alex_turner: maybe it makes sense to make distinction between allowing a session vs. background geolocation access
Resolved: editors continue to refine the use cases document, derive key requirements
anssik: the Web NFC API is potential future work for the DAS WG, not in scope currently
kenneth: spec implemented in Chrome, web developers asking for it, used in production even
… API has been refined over the last year or so, few changes can be made easily to modernize the API
… some IDL issues to fix, otherwise basically done what comes to r/w tags
… p2p not implemented due to platform limitations on Android, should we remove it from the spec?
tom: what are the p2p use cases?
kenneth: not that many use cases for p2p, any data exchange using NFC from device to device
Resolved: remove unimplemented p2p prose from the specification, make it a v2 feature
Create error message when using proprietary tags #160
[reviewing the list of open issues on the screen]
anssik: any other issues that'd benefit from group review
[hearing none]
Alex_Russell: is there a path to an Origin Trial?
Alex_Russell: talk to ThomasTheDane regarding the Origin Trial
[end Day 1]
anssik: thank you everyone, Day 2 starts 9:00
Succeeded: s/tiem/time/
Succeeded: s/forcus/focus/
Succeeded: s/I'm Lars/Lars Knudsen/
Succeeded: s/Lars Knudsen/I'm Lars Knudsen/
Succeeded: s/waiting another/waiting for another/
Succeeded: s/ other orgs/ other orgs to implement the specs/
Succeeded: s/found our /found out /
Succeeded: s/PROPOSED RESOLUTION: Ian to add telemetry for Battery Status API in Chrome, then talk to YT people//
Succeeded: s/any concern?/Any concern?
Succeeded: s/alex/alex_turner/