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?
Anssi: Any other agenda items?
Kenneth: Is WebHID under incubation?
Reilly: Yes, I can talk about it.
<xfq> github: 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
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
<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
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.
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?
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.
Satoru: Representing KDDI, a telecommunications company in Japan.
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.
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]
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: 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
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
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
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
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
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
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
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
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/wifi/wifi and gps/
Succeeded: s/or system/of system/
Succeeded: s/iframe/iframe support/
Maybe present: alex, Anssi, anssik, Ian, Kenneth, Reilly, reillyg, riju, Satoru, Tom, vincent