Tom: I would like to add the one remaining Wake Lock issue to the agenda this morning
Anssi: Do we want to describe the API change to Wake Lock discussed yesterday?
Kenneth: Yes.
Anssi: Any other agenda items?
[None heard.]
Kenneth: Is WebHID under incubation?
Reilly: Yes, I can talk about it.
<xfq> github: https://github.com/w3c/wake-lock/issues/226
<anssik> https://github.com/w3c/wake-lock/issues/226
reillyg: #226 is a reaction to earlier API changes to remove WK instances and use single instance of a WakeLock object, minimal API that takes wake lock type and AbortSignal
tom: awaiting a promise that never resolves is an uncommon design pattern
reillyg: API was unintuitive, the issue #226 contains a number of examples of code developers would write and would expect to works based on other promise-using APIs
tom: async/await pattern does not work too
reillyg: the proposed fix was to build a mode intuitive API for developers and it fixes the ergonomics issues enumerated in #226
… had marcos in the room to speak how to use AbortController the right way
… AbortController was not the right tool for this task
… we'd instead use a pattern of an id, similarly to setInterval/setTimeout()
tom: should rename "lockId "into "wakeLockID"
reillyg: updated the proposal in #226
kenneth: it's not constructible?
reillyg: yes, since it's an attribute on navigator
tom: use cases do not mention system, Google Maps could be a system use case, turn-by-turn navigation
… other use cases are for foreground
<tomayac> https://w3c-webmob.github.io/wake-lock-use-cases/#google-maps for turn-by-turn navigation
reillyg: question, is there a non-geolocation use case for system wakelock
kenneth: WebNFC could be one such use case
tom: flashing Android devices using WebUSB, make sure flash does not stop using system wake lock
… the screen might turn off, but system should be active
<riju> https://w3c-webmob.github.io/wake-lock-use-cases/#keeping-the-system-awake
Flaki: acquire both system and screen locks together?
tom: system implies also screen wake lock
reillyg: are there other system lock use cases beyond background geolocation which has its own privacy implementations, and may or may not be the right solution for that API
… maybe WebUSB flashing, importing photos, other CPU intensive processing, uploading and downloading
riju: OK Google or Hey Siri as a use case?
reillyg: privacy concerns there
tom: system-level indicator, how that should be specified?
reillyg: implementer guidance only, we cannot mandate a particular UI in specs
Flaki: from end-user POV, prefer if the site keeps my site from sleeping to have a persistent notification for that
<scheib> Please remind me where agenda link is?
reillyg: my thinking around system lock use cases are around progress
… it may be useful for implementations to provide progress indication along with its request for system wake lock to be used as a progress so could show a progress bar or some such to the user
Flaki: we want our portable device battery last for the day, allowing some crucial components remain active rather than going to deep sleep mode important; baseline assumption, screen and system wake locks are distinct, maybe these heuristics can be extended, example: "just want to play music via HDMI, nothing more" -- could this be UA heuristics or an explicit API?
reillyg: there's room to improve things like media playback etc. so they can take wake lock
<tomayac> FirefoxOS wake lock types: https://developer.mozilla.org/en-US/docs/Archive/B2G_OS/API/Navigator/requestWakeLock#Parameters
<riju> Processing (photos , media), playing music (spotify) in the background using say hdmi may need system wakelock
reillyg: maybe for WebUSB, we could pass info that this is time-sensitive, cannot let buffer go down
tom: issue here is people can always lie when requesting a wake lock with a reason
FirefoxOS had wake locks types for screen, cpu, wifi and gps
anssik: how much mobile platforms provide such wake lock APIs for native developers?
… this constrains us what we can do
reillyg: Android has only 4 wake lock types: partial wake lock aka system, screen dim wake lock, screen bright wake lock, full wake lock
anssik: are the Android abstractions good for the web?
reillyg: that's basically what we now have for the web with screen and system wake lock
<riju> granularity of screen lock is supported in Android, but looks like Android as of now has no way to provide granularity of System lock
<satakagi> minute
<tomayac> Proposal for how to integrate with system indicators: https://medium.com/dev-channel/experimenting-with-the-wake-lock-api-b6f42e0a089f#ddd0
tom: anything that turns the screen off, we should add a non-normative suggestion to the spec that system-level indicator needs to be concrete
[looking at iOS and Android background activity notifications at https://medium.com/dev-channel/experimenting-with-the-wake-lock-api-b6f42e0a089f]
riju: just asking, since you feel system wake lock is more powerful tool than screen wake lock, you want this indicator?
anssik: is the reason you cannot "see" a system wake lock
reillyg: yes
tom: probably for system we should add a requirement that the indicator MUST be seen by the user?
reillyg: because there's a strong connection with progress signal, we should be able to notify the system behind that action, think spinner as an analog of system being active
tom: are PWAs integrated with Android's battery reporting so that you get info per PWA on energy consumption
<riju> systemWakelock can have a non-mandatory hasProgress which can be shown to user on the LockScreen (ambient mode)
<riju> something better than native
PROPOSED RESOLUTION: User gesture is required for system wake locks along with an activity indicator and optional progress indicator from the application.
PROPOSED RESOLUTION: User gesture is required for system wake locks along with an activity indicator and optional progress indicator from the application, releasing does not require user gesture.
PROPOSED RESOLUTION: User gesture is required for system wake locks and implementation are encouraged to show an activity indicator and optional progress indicator from the application, releasing does not require user gesture.
[no concerns]
Resolved: User gesture is required for system wake locks and implementation are encouraged to show an activity indicator and optional progress indicator from the application, releasing does not require user gesture.
<anssik> github: https://github.com/w3c/battery/pull/13
Anssi: In Chrome the battery status API is currently available in cross-origin iframes.
… Mozilla had concerns about this API and dropped it a long time ago.
Tom: Looking at stats on HTTP Archive ads are the biggest user of this cross-origin.
Reilly: It doesn't seem like we've seen a clearly articulated reason not to land this PR.
<tomayac> Usage stats: https://chromestatus.com/metrics/feature/timeline/popularity/2198
Anssi: The issue is breaking sites.
flaki: If you have metrics for APIs like this then from a standardization point of view we should provide more restrictive versions of these APIs.
… For example, "is on battery power" vs. "what is the current battery level"
Anssi: In retrospect, agreed.
… The current usage is very high for taking this API away for cross-origin contexts.
Reilly: Ian, do we have exerience taking away APIs like this with FP in other contexts?
… What has been the reaction?
Ian: Geolocation is currently under feature policy.
Tom: We didn't hear massive outcry.
Ian: It's easy to fix in legitimate use cases.
Anssi: Do we know what will break?
Reilly: chromestatus.com includes top URLs using the API.
<tomayac> The post from geolocation days: https://developers.google.com/web/updates/2016/04/geolocation-on-secure-contexts-only
Reilly: We should post an Intent to Implement/Deprecate and just do it.
Ian: Some people think we should just cut it down to a small number of buckets.
Reilly: I think we should do both.
<tomayac> Intent to deprecate: insecure usage of powerful features: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/2LXKVWYkOus/gT-ZamfwAKsJ
Ian: Is the proposal still to never resolve the promise?
Reilly: Why not reject with NotAllowedError?
Anssi: For compatibility with existing content.
Reilly: Shouldn't script have already been written to handle other failures?
Ian: We could browse the web with canary running with this disabled and see how bad it is.
Reilly: Both mechanisms will break content but never resolving will break content in weirder ways.
<tomayac> and wronger ways
Reilly: The current PR text rejects with a SecurityError. It should be a NotAllowedError but otherwise is the right behavior.
PROPOSED RESOLUTION: Replace SecurityError with NotAllowedError and merge existing PR.
PROPOSED RESOLUTION: Replace SecurityError with NotAllowedError and merge #13.
PROPOSED RESOLUTION: Replace SecurityError with NotAllowedError in step 2 of getBattery() algorithm and merge #13.
Anssi: Any concerns given wide-scale implications?
[None heard]
Ian: Are there other interfaces in the Battery API which should be gated by FP?
Anssi: getBattery() is the only entrypoint.
Resolved: Replace SecurityError with NotAllowedError in step 2 of getBattery() algorithm and merge #13.
<satakagi_> xhttps://github.com/satakagi/TPAC2019-docs/blob/master/WebGPIO_I2C.md
https://github.com/satakagi/TPAC2019-docs/blob/master/WebGPIO_I2C.md
Satoru: Representing KDDI, a telecommunications company in Japan.
<satakagi_> https://github.com/satakagi/TPAC2019-docs/blob/master/WebGPIO_I2C.md
Tom: What is GPIO?
… and I2C.
<xfq> Web GPIO API
<xfq> Web I2C API
Satoru: It is an industry-standard low-level I/O interface.
flaki: GPIO is the lowest-level interface you could get to, controlling individual pins.
… I2C and other protocols build on top of that
… In some of these polyfills you can use WebUSB to talk to something that can drive GPIO.
Kenneth: I don't see a general way of supporting this.
Reilly: For programming environments with high-level programming languages like JavaScript this could be useful.
anssik: thank you for the presentation!
reillyg: it seems unlikely browsers would implement this low-level APIs, BT and Serial are already low-level but provide a bit more identification of purpose what permissions to be granted are
… not really possible with GPIO, these APIs see hardware-targetered APIs, standardization of some sort for modules and polyfills would be helpful
… question is whether that should be done within W3C or this group
Flaki: possible overlap with Web of Things standards effort at W3C, that is a W3C standards effort that has overlap with controlling devices on the low level, not on a hardware level, but fine-granularity, even on a pin-level
… no 100% overlap certainly, but raises a lot of issues on value of built-in API features
… reillyg: not familiar with WoT work, what level of abstraction is presented to the end-user through the browser? Is it pins?
Flaki: can describe pins but also high level concept of devices coupled together, similarity with WebBT
… based on taxonomy of descriptors what is on a particular device, more flexible version cf. WebBT endpoints
Flaki: CHIRIMEN has/had a Boot2Gecko implementation
… Mozilla moved on to exposing hardware devices built on web principles but not build on web browser
reillyg: Chromium probably has no plan to implement WebGPIO or WebI2C
… some Chromium embedders might find this useful though, e.g. Chromecast type of devices
kenneth: we've updated the API significantly over the last year or so, now in scope for Project Fugu
… people with existing implementation of NDEF can use this API is a target
… there are also non-standard alternatives to NDEF, we don't support those currently, but given good use cases we could add support for those formats
… NFC specs are hard to read in general, native implementations have not all figured out fully
… native NFC APIs are not user friendly, suspect the reason for lack of uptake in NFC ecosystem
… re WebNFC spec, in a good shape
… let's look at open WebNFC issues
[issue list open on a big screen]
https://github.com/w3c/web-nfc/issues
riju: NDEF records are in scope of Origin Trial, other type of records not supported
… for security people, we don't need explicit permission prompt, user gesture is enough that shows a heads-up notification NFC is in use and usage notification
issues we want to fix before Origin Trial: https://github.com/w3c/web-nfc/issues?q=is%3Aissue+is%3Aopen+label%3A%22Origin+Trial%22
issues we want to fix before shipping: https://github.com/w3c/web-nfc/issues?q=is%3Aissue+is%3Aopen+label%3AMVP
<flaki> https://github.com/mozilla/standards-positions/issues/198
Flaki: there used to be WebNFC-like API for FirefoxOS, now discontinued, not speaking on behalf of Mozilla
riju: any NFC specific feedback or concerns from Mozilla?
Flaki: personally not aware, but not a security researcher, I have followed WebNFC from FirefoxOS times
… implementing this API goes with the same resource constraints, so probably no rush in Firefox to implement this API
… not surfacing explicit security prompts might be ok here since you need close proximity with an NFC tag to interact with it
riju: use cases and security question, do you foresee WebNFC to be used in an iframe?
reillyg: payments situations?
… official payment standards do not use WebNFC since they do not use NDEF, could replace QR Codes instead, used in AliPay for example
anssik: can we expose this to iframe in the future if we decide to do so without breaking content per how this API is now specified?
kenneth: yes, this is future-proof
<riju> Looks like webNFC has use cases for iframe, else main page will just postMessage to shuttle data back and forth
alex: suggest you go to Origin Trial without iframe
<riju> so we should add Feature policy for iframe support usage as MVP
alex: we can add iframe support question to the Origin Trial survey that goes out to folks enrolled to WebNFC OT
ian: with iframe, both origins would need to enroll to the OT
reillyg: Feature Policy token only works in top-level if also that is enrolled into OT
reillyg: any other high-level WebNFC issues or questions?
kenneth: issue #350 https://github.com/w3c/web-nfc/issues/350
reillyg: unable to make a recommendation on #350 right now
https://github.com/w3c/web-nfc/pull/282
The link to 'focus' is not appropriate #282
kenneth: I'm hearing we should do the same as with Wake Lock, abort if losing visibility
https://github.com/w3c/web-nfc/issues/225
Consider using AbortController rather than a stop() method #225
tom: we only use AbortController due to Wake Lock using it, how now that we dropped that from Wake Lock?
reillyg: NFCReader not strictly required to have AbortController, NFCWriter we don't need an event because it returns a promise and AbortController makes sense there
<kenneth_> I am suggesting that someone files an issue on the TAG design principles and preferable also a PR
<kenneth_> (about when to use AbortController and when not to)
reillyg: I'll file an issue on TAG design principles
<kenneth_> added comment about visibility https://github.com/w3c/web-nfc/issues/282#issuecomment-533389319
https://w3c.github.io/wake-lock/#handling-document-loss-of-visibility
reillyg: subtopic, WebUSB
… continues to gain adoption, usage on page loads is up, vincent to provide data
… Ovidio shipped WebUSB
<tomayac> USB Device Open stats https://chromestatus.com/metrics/feature/timeline/popularity/1521
reillyg: subtopic, WebBT
<scheib> https://www.chromestatus.com/metrics/feature/timeline/popularity/1890
reillyg: continues to be shipped in Chrome, working on a number of projects, BT scanning, integration with Permissions API and getAvailability()
reillyg: subtopic, WebSerial
… incubation started on WebSerial, based on FirefoxOS proposal
reillyg: subtopic, WebHID
<scheib> https://wicg.github.io/serial/
reillyg: WebHID is a new spec, both WebSerial and WebHID fill in gaps left between WebUSB and WebBT
… they're currently implemented behind flag in Chromium browsers
<scheib> https://wicg.github.io/webhid/index.html
reillyg: and Origin Trials are planned for the coming quarter / year
reillyg: that's it, any questions on these incubations?
Flaki: a lot of developer interest in WebSerial
… hobbyists
reillyg: cryptocurrency people like WebUSB, interaction with hardware wallets
tom: Lars Knudsen is doing work with WebBT and WebUSB in enterprise
vincent: when to consider these to be official work items of this working group?
… had discussions with Jeff the W3C CEO about this topic
… WebBT is in its own standalone CG, for BT we have no process whatsoever
… according to Jeff not required to have two implementers for a feature to enter a WG
alex: yes, existing requires two interoperable implementations
anssik: our charter ends 2020-06-30 so Q1 2020 would need to have a good idea what new APIs we want to graduate from incubation into this group, if any
https://www.w3.org/2019/03/devices-sensors-wg-charter.html
reillyg: I don't see other implementers interest appear in the next 6 months
anssik: Chris Wilson's talk from AC meeting on Wed relevant to our discussion: https://www.w3.org/2019/Talks/TPAC/incubation
Succeeded: s/beed/need
Succeeded: s/wifi/wifi and gps/
Succeeded: s/or system/of system/
Succeeded: s/iframe/iframe support/
Succeeded: s/Capabilities/getAvailability()
Maybe present: alex, Anssi, anssik, Ian, Kenneth, Reilly, reillyg, riju, Satoru, Tom, vincent