– DRAFT –
Devices and Sensors WG + WebApps WG F2F (Part 1) / Devices and Sensors WG F2F (Part 2) – 24 September 2024

<gb> Issue 69 Devices and Sensors WG - TPAC 2024 agenda (by anssiko)

Welcome

anssik: Welcome to the Devices and Sensors WG and WebApps WG joint F2F!

Agenda bashing

anssik: we have 4 joint deliverables on the agenda today:
… - Screen Wake Lock API

<HowardWolosky> present

anssik: - Device Orientation and Motion (was DeviceOrientation Event specification)
… - Geolocation API
… - Contact Picker API
… any last-minute issues to bring to the agenda?
… note for Contact Picker API we did not have any specific issues

Charter update

anssik: at last year's TPAC we establish guidelines for joint deliverables and initiated rechartering of both the DAS WG and WebApps WG to ensure both the charters are aligned and adhere to the principles we laid out in the W3C Guide for joint deliverables
… both the groups successfully rechartered Feb 2024

Screen Wake Lock API

Repository: w3c/screen-wake-lock

anssik: we had two issues on our agenda

Distinguish exceptions on .request()

anssik: issue #352 opened by Marcos

<gb> Issue 352 Distinguish exceptions on .request() (by marcoscaceres)

anssik: this issue is about what names we should use for error conditions

reillyg: figuring out what errors to use with request() method

Olli: we should not use specific messages

reillyg: trying to figure out what are the areas where we don't yet disagree
… two situations are: fully active check, visibility check, which can fall in invalid state

marcos: security error or not?

reillyg: there's four checks: fully active, visibility state, permission policy check, permission check

marcos: for fully active and focused, and visible there's a nice hook in HTML, "fully active traversable", we can capture all these additional checks in a single statement

<Marcosc> " fully active descendant of a top-level traversable with user attention "

<Marcosc> https://html.spec.whatwg.org/#fully-active-descendant-of-a-top-level-traversable-with-user-attention

marcos: covers a lot of cases, does not yet address the main issue
… not allowed generally for permissions is good
… visibility state for user attention

reillyg: important for the spec to use NotAllowedError consistently, we change fully active check to invalid state check
… Chromium willing to accept web compat impact for the change

marcos: another thing, require the doc to be visible, does that have significant web compat impact?

reilly: posted a proposal to the issue as a comment

Require transient activation to request lock

anssik: issue #350 and PR #351

<gb> Pull Request 351 Require transient activation (by marcoscaceres)

<gb> Issue 350 Require transient activation to request lock (by marcoscaceres)

anssik: discussion on what user activation state to use.
… - transient activation i.e. user currently interacts with the page, has two flavours:
… -- "use" transient activation to allow multiple calls per user activation
… -- "consume" to prevent multiple calls per user activation
… - sticky activation i.e. check if the user has ever interacted with the page
… Reilly provided data from Chromium Dec 2022: "about 80% of screen wake lock requests do not have user activation" and Apr 2024 "Chromium's metrics look better for [sticky activation] and it means that a site can reacquire a lock if it had one before but lost it due to visibility changes

w3c/screen-wake-lock#350 (comment)

<gb> Issue 350 Require transient activation to request lock (by marcoscaceres)

w3c/screen-wake-lock#351 (comment)

<gb> Pull Request 351 Require transient activation (by marcoscaceres)

reillyg: use case is to be able to reacquire wake lock as needed
… screen off site loses the wake lock
… if the site becomes visible again should be able to reacquire
… you may be looking at a recite and have the same expectations you see what the page was representing you
… if we do require any user activation at all it needs to be sticky so the site can reacquire the clock
… proposing a more complex approach in the issue
… that is to require transient activation first

w3c/screen-wake-lock#350 (comment)

marcos: a pointer the current WebKit implementation:

w3c/screen-wake-lock#350 (comment)

<gb> Issue 350 Require transient activation to request lock (by marcoscaceres)

reillyg: we have some data on Chromium usage
… requiring an activation is going to have an impact, we have to consider a migration path to minimize web compat impact

Olli: marcos do you know of any web compat issues from WebKit?

marcos: I think out our implementation is different
… it makes sense to have this in place, this is powerful and would be a great thing

Olli: we should have a warning in console "this will change soon"

reillyg: what error should we throw when we don't have transient activation state?

marcos: I'll check what others go in a similar situation,

reillyg: a possible scenario: user decided to not click, you just called it at the wrong time?
… one example is a security error
… there should be a standard algorithm step for this we should reuse for consistency
… if the proposal is to throw an error I can formulate that into a GH comment

marcos: LGTM

Olli: LGTM, but some sites might be broken, need to figure out what to do

anssik: anything else to discuss for Screen Wake Lock today?

marcos: permission prompt issue status?

reillyg: if the screen is on then the API is active and you can close down the API by turning off the screen?

marcos: the concern from the WebKit side is we now fake the permission
… it does not meet the conditions of it being a powerful feature to require prompting
… we should remove dependency on the Permission API

reillyg: in the latest version of the Permissions API, policy control is integrated

Should this prompt

anssik: issue #324

<gb> Issue 324 Should this prompt? (by marcoscaceres)

marcos: Firefox shipped without permission prompt
… having a setting so the user can disable the API

reillyg: if the setting would be toggled it makes sense to expose that to the site via .query()
… we would reject the promise, but it would also mean developers understand why the site is not working

marcos: it would be good for us to see what permission policy needs from an iframe
… WebKit has specific code to handle this case currently
… you never prompt
… screen wake lock is not a powerful feature, it is a policy controlled feature
… get rid of permission and user prompts

marcos: proposing we tweak the wording, the UI presents some kind of thing such as a camera, indicator of sorts what wake lock is on for this particular tab

reillyg: nobody implement that currently
… this feels like a different thing, the questions is should we have Permissions API integration
… Mozilla considers using this for the user setting

reillyg: permissions that don't prompt and provide settings -- any examples of that usage?
… are you OK with the proposed resolution being drafted in the GH comment?

marcos: will took a time to review this proposal after the meeting

Device Orientation and Motion

Repository: w3c/deviceorientation

CR Snapshot publication

anssik: CfC to publish CR Snapshot passed on March 2024

https://lists.w3.org/Archives/Public/public-device-apis/2024Mar/0000.html

anssik: after CfC we received feedback that we should identify "at risk" features, the "at risk" features are annotated in the spec, changes in PR #149.

<gb> MERGED Pull Request 149 editorial: Identify at risk features and their causes (by reillyeon)

anssik: the following features were identified as "at risk"

https://www.w3.org/TR/orientation-event/#permissions-integration

https://www.w3.org/TR/orientation-event/#deviceorientationabsolute

https://www.w3.org/TR/orientation-event/#automation

anssik: we also have "what's new since previous CR:"

https://www.w3.org/TR/orientation-event/#sotd

anssik: it's now 6 months since the CfC passed, so I'd like the groups to advance with the CRS publication and continue work in subsequent updates. The most recent CR is from 2016.

reilly: I'm happy with the document as is

marcos: I don't have any concerns

reillyg: WebKit implement the permissions integration, Chromium has not had time to do that yet
… automation is good to have and improves the testing story
… the only truly "at risk" feature is the deviceabsoluteorientation
… WebKit has its own version of that

anssik: we did an issue triage on Feb 2024 in preparation for the CRS publication

DeviceOrientation Event issue triage - 12 Feb 2024 - minutes

anssik: we have 4 open issues from that triage that are also considered non-blocking for the CRS publication
… do we want to discuss any of them today?
… they are #87 #91 #118 #137

<gb> Issue 137 Guidance needed: how to acquire compass headings in a future-compatible manner? (by juj) [question]

<gb> Issue 118 Behavior when event data cannot be provided is underspecified (by rakuco)

<gb> Issue 91 DeviceMotionEvent atttributes can't be null per current IDL (by saschanaz)

<gb> Issue 87 Device motion sampling frequency (by marcoscaceres) [privacy-needs-resolution]

marcos: still surprising we have 3 permissions policies for this API

reillyg: more recent changes have moved permissions policy concepts into this spec and we think those issues are not resolved
… I want to publish this CR Snapshot, given that issue is marked as "at risk"
… permissions and automation are good to have, agree Marcos

Marcos: absolutely yes
… only concern with automation it ties into the automation model based on Generic Sensor API, it may be a great model, however

proposed RESOLUTION: Publish a Candidate Recommendation Snapshot of Device Orientation and Motion with "at risk" features as identified

<scheib> +1

RESOLUTION: Publish a Candidate Recommendation Snapshot of Device Orientation and Motion with "at risk" features as identified

Geolocation API

Repository: w3c/geolocation

WebDriver Testing API

anssik: #146 and draft PR #170

<gb> Pull Request 170 Add test automation support via Web Driver (by marcoscaceres)

<gb> Issue 146 A means to test the API via Web Driver (by marcoscaceres)

anssik: Marcos proposed an API for a WebDriver extension for emitting a GeolocationPosition
… what would you like to bring to the groups' attention?

marcos: wanted to introduce this extension
… reilly pointed out a few concerns
… I looked at how to do this in WebKit, using a mock API that sets a location for an origin

reillyg: we'd set a mock location for a top-level traversable, this gives developers what developers expect, applies to the entire page for its lifetime

marcos: we wanted for WebDriver and BiDi, we'd set and get an ack it is set
… it was cool that the same API surface can clear, and generate errors
… I think it covers all the cases the developers would need
… for folks in the groups, please take a look
… if you have knowledge of WebDriver BiDi contributions welcome!

Learnings from the updatable Recommendation journey

anssik: after an evaluation of available options for revising the W3C Recommendation Geolocation API, the joint groups decided in May 2024 to advance with the "Revising a W3C Recommendation" mechanism defined in the W3C Process

https://lists.w3.org/Archives/Public/public-device-apis/2024May/0012.html

https://www.w3.org/TR/geolocation/

anssik: the editors have annotated the Geolocation W3C Recommendation with "purple boxes" that present a diff to the previous Recommendation:
… a "candidate addition" proposes a new feature
… a "candidate correction" proposes an error correction
… new features:
… - toJSON()
… - Define units for accuracy
… corrections:
… - Update acquisition algorithm to define data types and handle cached positions
… - Check for non-secure contexts
… - Clarify units and reference geodetic system for latitude and longitude
… - Use null instead of NaN when stationary

https://www.w3.org/TR/geolocation/#sotd

anssik: "candidate corrections" and "candidate additions" are collectively known as "candidate amendments", and these "candidate amendments" are only made normative when the "purple boxes" are integrated into the spec spec per "Incorporating Candidate Amendments"

Incorporating Candidate Amendments

marcos: OK to amend the changes to Recommendation now and then go to CRS and iterate at CR

reillyg: would we want to add the automation parts into the Recommendation?

<scheib> example changes in purple boxes: https://w3c.github.io/geolocation/#latitude-longitude-and-accuracy-attributes

proposed RESOLUTION: Incorporate Candidate Amendments into the Geolocation API, then do another Recommendation with automation parts integrated

RESOLUTION: Incorporate Candidate Amendments into the Geolocation API, then do another Recommendation with automation parts integrated

Integrating features from the Generic Sensor API

anssik: on the agenda we have "integrating features from the Generic Sensors API"

marcos: WebKit implements older specs such as Geolocation API
… can we bring some of the features from the new specs into the older specs?

reillyg: there's been a lot of discussion around Geolocation Sensor, background geolocation has had a lot of discussion
… would like to discuss recasted Sensor APIs that offer interesting new features over the older APIs
… e.g. Permissions API integration, the API has a clear sensor initialization process and can signal errors, can integrate permissions and communicate failure
… that does not work with older API attached to the window object
… another improvement is that the API provides reading attribute, integrates with rAF and event loop similarly Gamepad API

marcos: you have the details, the ask is is there appetite for us to step back and consider these
… we acknowledge the use cases

reillyg: the question is can be bring them over?
… being able to read an event during rAF may not be technically possible

marcos: I think myself and other people need to look at all the possible solutions so we can better debate the merits

reilly: developers want to be able to ask for the sensor polling rate, they can ask for less than 60 Hz
… feedback from Mozilla or WebKit?

reilly: are you interested in solving these problems?

marcos: we haven't had an opportunity to look at the use cases you're proposing
… sell us the thing and show what developers made with it and what Safari users are missing out

Olli: might be useful to have a list of things Generic Sensor APIs provide and see how we could implement that based on other APIs

reilly: action on DAS WG to put together an implementation report and/or explainer, list of improvements this API provides so that other browser implementers can consider whether they're interested in the improvements and the improved API

Devices and Sensors WG F2F (Part 2)

<engedy> Regarding the agenda, did we discuss system level permissions (e.g. https://github.com/w3c/geolocation/issues/107) in the morning? I am not seeing notes in the minutes about that.

<gb> CLOSED Issue 107 Specify behavior for operating system permissions (by reillyeon) [bug]

Accelerometer

Repository: w3c/accelerometer

Disable Accelerometer use while Vibration API is in use

anssik: #69

<gb> Issue 69 Disable Accelerometer use while Vibration API is in use (by MrBrain295)

anssik: quoting: "The accelerometer could be used to fingerprint people if it is used at the same time as the vibration API. This could be prevented by having the accelerometer disabled or collecting data at a lower accuracy when the vibration API is in use."
… Reilly notes there's two normative requirements in place in both the Vibration API and Accelerometer (via Generic Sensor API) to mitigate this threat:

Vibration API: "If the document's visibility state is not visible, then return false and terminate these steps."

Generic Sensor API: "The user agent can expose sensor readings to a Document document if and only if all of the following are true: [...] document’s visibility state is "visible". [...] The focus and origin check on document returns true."

anssik: these checks ensure only the same document that is also "visible" can access both the APIs at the same time
… "focus and origin check" ensures third-party site from within iframe cannot use Accelerometer:

Focus and origin check

reillyg: the original author did not come back to us, theoretically possible, but we haven't seen researchers validating this attack vector
… mitigation we have in place for Accelerometer should limit to the being able to measure only the strength, is the amplitude enough to fingerprint the device you have?
… how your holding the device could impact
… Balasz, is this a side-channel we have received data on?

Balasz: no
… proposed approach added to the GH issues

Define normative privacy mitigation

anssik: #57

<gb> Issue 57 define normative privacy mitigation (by samuelweiler) [privacy-needs-resolution]

anssik: the ask is to normatively specify mitigations suggested in the research papers referenced in the security and privacy considerations

https://www.w3.org/TR/accelerometer/#security-and-privacy

reillyg: for Device Orientation event we do have rounding requirement

reillyg: we should port the Device Orientation mitigations over the the Generic Sensor specs

anssik: given Chromium already implements that mitigation for Generic Sensor APIs, this would be just a spec change
… applies to Accelerometer and Gyroscope

Device calibration of accelerometers may reveal precise hardware fingerprint

anssik: #54

<gb> Issue 54 device calibration of accelerometers may reveal precise hardware fingerprint (by npdoty) [privacy-needs-resolution]

anssik: I'm interested in feedback from Device Orientation that spec'd Paul Jensen's recommendation of rounding to 0.1 m/s^2:

If acceleration’s x axis acceleration is not null, limit its precision to no more than 0.1 m/s2.

If acceleration’s y axis acceleration is not null, limit its precision to no more than 0.1 m/s2.

If acceleration’s z axis acceleration is not null, limit its precision to no more than 0.1 m/s2.

anssik: and similarly for accelerationIncludingGravity and rotationRate
… IIRC on Chromium this rounding mitigation is already applied to readings exposed through Accelerometer, LinearAccelerometer, GravitySensor

anssik: there's a "reading quantization algorithm" defined by the Generic Sensor API for this:

Generic Sensor API: reading quantization algorithm

anssik: and this algorithm is used by ALS currently:

Ambient light reading quantization algorithm

anssik: if the Accelerometer implementations already "limit precision to no more than 0.1 m/s2" then an "Accelerometer reading quantization algorithm" would likely fix this issue

Gyroscope

Repository: w3c/gyroscope

Gamepad API gyro support

anssik: issue w3c/gamepad#211

<gb> Issue 211 Add device orientation support (by jdarpinian) [feature request] [TPAC2024]

matt: we extended Gamepad API with pose to include this information, that never got implemented in Chromium
… only Firefox has it for VR gamepads, WebXR has its own XRPose interface
… going forward gamepads still have motion sensors, doing it with gamepad not the best interface
… because gamepad API is poll-based not good to motion sensors
… a good opportunity to leverage work se did for Generic Sensor-based Gyroscope API
… remaining concern no permission model on the Gamepad API
… we don't necessarily want to expose sensor data via Gamepad API without user consent

reillyg: conversation earlier today was what Device Orientation spec can learn from Generic Sensor APIs
… we took an action to list the differences, one of the things the new API does better is support for multiple sensors
… you can have Gyroscope on the Gamepad API, expose that through an attribute on Gamepad API, or have multiple Gyroscopes per Gamepad
… the fact that Generic Sensors support multiple sensors of the same type is really good
… the other is to say, what if we take the Device Orientation model, fire an event on the gamepad object
… the difference is whether you want to do polling or not
… no conclusion, but we have a space of solutions, whether to use the new surface or the old one

matt: using eventListener we couldn't add any permission prompt

<sebastian> presence+ sebastian_kaebisch

reillyg: using event-based, it would need to be a global permission, not specific to Gamepad API

reillyg: is WebApps looking at this?

matt: not much progress there

Magnetometer & Proximity

reillyg: both are in a similar state, specced but not shipped, one implemented behind a flag, another not implemented
… should we update the status of the specs?

anssik: we have requested web developer feedback as follows

"This specification is looking for developer feedback and high value use cases. Please provide your feedback via GitHub."

anssik: but we did get some feedback #59 for high frequency sampling but no new use cases

<gb> MERGED Pull Request 59 editorial: Use permissions and permissions-policy dfn's from DEVICE-ORIENTATION (by rakuco)

Repository: w3c/magnetometer

#59

<gb> Issue 59 Request for Magnetometer web developer feedback (by anssiko)

anssik: the spec documents a set of use cases: sensor fusion, VR/AR, gesture recognition, indoor navigation, metal detection, compass

Use Cases and Requirements

reillyg: I propose we very clearly mark this spec as not actively worked on, we leave the GH repo in place to gather feedback from web developers

anssik: many web developer articles mention mapping app/compass use case for Magnetometer:

https://mobiforge.com/design-development/the-generic-sensor-api

anssik: what are the best ways to gather helpful feedback from web developers?

reillyg: state of HTML has been good to us

Repository: w3c/proximity

anssik: recent updates to the IEEE 802.11 wireless standards enable Wi-Fi Sensing in mainstream devices

IEEE Xplore: Wi-Fi Sensing Based on IEEE 802.11bf

arXiv: An Overview on IEEE 802.11bf: WLAN Sensing

anssik: with 802.11bf Wi-Fi-connected devices can be turned into proximity sensors that detect human presence, broadening the installed base of devices capable of supporting this API
… we might be doing some prototyping in this space and will look at the use cases #4 to identify intersection with the web

<gb> Issue 4 Generic Proximity sensor or UserProximity sensor (by tobie)

anssik: this tech support a range of use cases, room sensing, gesture recognition, health care, 3D vision
… positive privacy properties in certain scenarios over camera-based implementations

reillyg: Idle Detection API is another API surface that could expose similar information
… currently that API relies on HID input, this kind of proximity sensor technology could provide a better signal
… seems like a good way to expose user detection without any of the sensor data

anssik: we can update the status text similarly to magnetometer

Geolocation Sensor

Repository: w3c/geolocation-sensor

Rescope to address background/geofencing use cases only

anssik: #17

<gb> Issue 17 Next-gen geolocation use cases (by tomayac) [geo-background-fencing] [use-cases]

reillyg: we should clarify we do not intend to duplicate anything

anssik: Mozilla's position via Marcos from 2018 was to decouple Geolocation API from background/geofencing
… I recall Apple had a similar position

reillyg: use cases seem mainly fully background geolocation focused
… one specific use case is a fleet management situation
… someone doing deliveries is using for business reasons where they are, you don't want the system to go to sleep or the user switching to another task/app so you lose location when you switch context
… this use case really requires explicit background location with some frequency, possibly via ServiceWorker

Mek: use cases for batched updated vs. real-time updates?

reillyg: we have a good list of use cases, right no browser implementer is trying to solve the related privacy issues

anssik: can we better crowdsource solutions to the privacy issues from the broader community?

Marian: Chrome would need a permission from the OS, right?

reillyg: yes, it would be a lot of work, but it would be possible, for installed web apps we can attribute the permission to the application

Evan: are most of the use cases for installed PWA?

reillyg: seems so, would be reasonable to restrict this to installed PWAs outside the browser tab that have an installation requirement
… use cases such as fitness tracker, driver tracking app fall in this category
… one of the comments imply they'd trust PWA and not the browser, can you just grant the permission to PWA and not the browser?

reillyg: developer feedback suggests, they'd trust an installed PWA and not generically to the browser
… implementation-wise, if you trust a PWA you truist the browser too

reillyg: permissions UX for installed apps is better than tabs because you can ask for permission in the context of the installed app
… a possible next step would be to add this feature to the next "State of HTML" survey to understand relative priority

<scheib> example survey results https://2023.stateofhtml.com/en-US/features/mobile-web-apps/

System Wake Lock API

reillyg: the next falls under the topic of System Wake Lock, we split "Wake Lock" into Screen Wake Lock and System Wake Lock

Progress Notification API

Progress Notification API

Ayu: scenarios: backgrounding a tab
… e.g. long download
… scenario 2: keeping a tab open for a task
… users forced to keep the tab open
… some APIs require screen wake lock by playing video or audio
… scenario 3: tasks when a site isn't open, e.g. cloud file service
… all scenarios have in common that the user needs to complete an important task
… use cases: 1) providing hints to the browser, 2) extend the lifetime of a service worker, 3) extend the lifetime
… proposal: a generic API
… security and privacy considerations, must provide UI to inform users of background tasks, provide options for controls, present developer-specified messages in context
… API shape
… current state, explainer published, Intent to Prototype for Blink, Getting feedback and other use cases

Evan: naming the API?

reillyg: we want sites to use this often to report to the browser what they're doing
… I'd limit sites using this all the time
… it is useful to know if the site is "done" with its task

Balasz: alternative UX options to use to indicate to the user there's background processing happening?

Ayu: if installed we use a different UI

Balasz: interested in a variant that can be exposed on a drive-by web
… string to describe what type of processing is happening

reillyg: we might show the string in the tab title
… to use as a replacement for onbeforeunload, need to consider malicious use, is it safe to show the user a string or a progress bar
… for installed apps, there might be a place to allow a version of this to be notification based, enable more background activity, ability have the tab closed

Balazs: one option is more discrete UI

LuHuang: I looked at a similar problem for installed web apps
… web apps sometimes want to close the app windows, scenario 3, for some apps it is useful to run the logic in the background
… we have a breakout session tomorrow for minimized to system tray concept
… haven't decided yet, should convince users to keep the ServiceWorker open or have associated logic running

reillyg: apps running in the background even if closed, web apps don't have a good concept for that -- figuring out what things you can do in that state
… when in that state you get Service Worker events, resources constrained
… user agent can populate the tray with more information

<NatashaGaitonde> Lu mentioned this Breakout session on Wednesday (System Tray Icon Support for PWAs) https://www.w3.org/events/meetings/c7122995-e333-461d-81a5-eb16b5a98d64/

LuHuang: I don't think we should go to a direction that SW is short-lived

Vincent: hidden page vs Service Worker, this is a good topic
… Chrome extensions used a hidden documents for a while and the general approach wasn't good
… heavy weight, poor practices
… with ServiceWorker we're careful to allow only execution required by the task

Mek: for SW, single thread not great for long-running tasks

Evan: tab with controlled text in the browser UI, gmail is using that for things that are not really titles
… a good API to give them a more standardized way to edit tab notification or status indicator

anssik: can you script favicon for a similar experience?

reillyg: that has some side-effects, not reliable

Compute Pressure API

Repository: w3c/compute-pressure

anssik: we completed the wide review #177 for the Compute Pressure API

<gb> Issue 177 Wide review tracker (by anssiko) [w3c-process-steps]

anssik: a Chrome Origin Trial ran during Q4'23 - Q1'24.
… we received feedback from early adopters of the Compute Pressure API:

Origin Trial feedback

<gb> CLOSED Issue 795 Compute Pressure Specification Review (by arskama) [Progress: review complete] [Venue: WICG] [privacy-tracker] [Venue: Devices & Sensors WG] [Missing: Multi-stakeholder support] [Resolution: satisfied with concerns]

anssik: quoting "100% of the respondents are extremely likely to continue using the API."
… this feedback suggested the current version of the API is addressing real customer needs
… the Compute Pressure API shipped in Chrome 125 Stable release Q2'24.
… as suggested by Atsushi, the next step for the spec is to advance toward CR
… I asked the editors to do a triage to identify "V2" and "bug" issues
… "V2" issues are out of scope for CR, non-blocking
… "bug" issues to be discussed whether they're CR blockers

arnaud: we have 3 items for the spec
… one was solved #291

<gb> Issue 291 "Rate-limiting change notifications" section is confusing (by rakuco) [bug]

arnaud: this can be solved before CR
… there's a log of discussion mitigations and we need to clear that

arnaud #281

<gb> CLOSED Issue 281 "Current pressure state" definition and cardinality are confusing (by rakuco) [bug]

#243 is trickier

<gb> Issue 243 Permission policy needs to be checked when owner set changes (by kenchris) [bug] [V2]

arnaud: these are the two remaining issues to be addressed

arnaud: not sure about issue #243 when and how to solve it

reillyg: are developer using this API is Shared Workers?

arnaud: we had a feature request from web developers for shared workers

reillyg: it would be nice to get general advice from WebAppsSec on how to use Permissions Policy in Shared Workers
… this might be a case where we need to get feedback from another WG
… as Kenneth says, we probably need to monkey-patch the spec to specify the behaviour
… the current behaviour might be correct
… this is a known issue with Shared Workers, if any page has a capability it can share it with any page
… I think we need to reach out to WebAppSec WG that works on the Permissions Policy, how to do these checks in Shared Workers, then follow their guidance

anssik: https://www.w3.org/TR/compute-pressure/#dom-pressuresource-thermals is proposed as "at risk" feature for CR

atsushi: we just mark it as "at risk" in the specification, we keep it in the CR

arnaud: #233

<gb> Issue 233 Use-case: Analytics / RUM (by nicjansma) [V2]

arnaud: buffer compute pressure values before we start the observer

reillyg: is the goal to provide small amount of history?

arnaud: yes

reillyg: I understand the use case, when the page loads, understand if the system is under high pressure
… what is the cost of monitoring system pressure is the question
… the issue is if the code monitoring the page loads late in the process, they can't get analytics from the loading process
… if we can record analytics earlier and report the history that'd be helpful

Vibration API

Repository: w3c/vibration

Wide review feedback: TAG

anssik: #69

<gb> Issue 69 not found

w3ctag/design-reviews#971

<gb> Issue 971 Vibration API (by anssiko) [Progress: pending external feedback] [Venue: Devices & Sensors WG] [Focus: API design (pending)] [Focus: Privacy (pending)] [Focus: Accessibility (pending)]

anssik: TAG asks "would enough use cases be served if browsers could treat the device they're running on as a gamepad?"

GamepadHapticActuator

matt: I don't think that's possible, you can't access any gamepad without it being attached
… talked about his a little bit, will discuss this more in a specific session, can ask OS to draw an overlay of a gamepad, could in theory design the API to turn the device into a sort of a gamepad, that's seems reasonable, but the issues are how to trigger vibration without any overlay, would need the overlay to be hidden

reillyg: haptics with virtual gamepad is a great idea, but it is unclear whether that is reusable for apps that don't want to use the gamepad part that includes e.g. buttons
… are there use cases that do not deal with gamepad? I think there are
… what the developers try to do is neither notification nor gamepad, should provide these as examples in the specification
… we should author an explainer with alternatives considered, focus on use cases that are not achieved by gamepad API or notifications

anssik: Vibration API is currently reused by the Notifications API and that integration would not work with the Gamepad API

https://notifications.spec.whatwg.org/#create-a-notification

anssik: I think the Gamepad generalization and repurposing idea is an interesting idea, but would need that API to change quite a bit

Wide review feedback: Privacy

anssik: #42 is about Permissions API integration

<gb> Issue 42 Integration with permissions API (by pes10k) [privacy-needs-resolution]

anssik: "Both to address the potential misuse of the API to create a cross-device / cross-context covert channel (and to standardize the behavior of the discussed cases of when the user agent might want to deny access to the API to prevent user annoyance), the API should integration with the permissions API (even if the expected UX for access / denial of that permission isn't a standard permission dialog)"
… I responded that Permission integration was considered in #10 but after implementation experience user activation-gating #29 was selected as a mechanism instead and that is what the latest editor's draft now reflects

<gb> CLOSED Issue 29 Require user activation for navigator.vibrate (by johannhof)

<gb> Issue 10 Vibration should require user's permission (by andrey-logvinov) [v2]

reillyg: similar to Screen Wake Lock question, we don't intend to implement a permission for this, other mitigations are considered sufficient
… there's no Permissions Policy integration, we don't have implementation experience for permissions
… Permissions Policy integration seems useful
… could improve the metrics, add a new use counter after checks
… #43 is about non-privacy related concerns

<gb> Issue 43 Misc non-privacy concerns with the API (by pes10k)

reillyg: - ask to make this an async API instead
… - comment on informative notes that contain extensive advice to implementers, and expand on normative prose
… I responded that making the API async at this point has web compat impact
… for informative content, pointed out there's single normative step to bail out:

An implementation MAY return false and terminate these steps.

reillyg: the action to take on this feedback is about consistency, do a pass that our guidance is consistent

Wide review feedback: Security

w3c/security-request#71

<gb> Issue 71 Vibration API 2024-06-28 > 2024-09-20 (by anssiko) [REVIEW REQUESTED] [WD]

anssik: received suggestions, proposing to incorporate applicable mitigations
… Standardize of Max Length and Duration

reillyg: Chromium hardcodes certain limit, unless platform API is stricter
… we could say only 10 entries allowed in vibration pattern
… 10 seconds seems to be the max duration for many Android devices
… Include Random Vibration

reillyg: we could add random variation, but don't want the app to feel unreliable because of vibration constantly changing
… adding 10 ms at the end could mitigate the problem

Mek: IPC could already add some randomness and act as a mitigation
… Request User Consent

anssik: the spec says "[T]he user agent SHOULD inform the user when the API is being used and provide a mechanism to disable the API (effectively no-op), on a per-origin basis or globally"

reillyg: I disagree with the premise of this threat, the premise is that by vibrating the phone you can emulate system UI, but any app can already vibrate your phone

Vincent: Vibration as a concept is understandable, users would understand what they are granting permission to if asked

anssik: Minimize Information Disclosure in Error Handling

reillyg: in order to prevent information disclosure, the API behaviour should be well specified and consistent
… Limit API Usage

anssik: proposal to add to Security and privacy considerations: "The use agent should employ global rate limiting to restrict the number of vibration requests made within a certain period (e.g., per minute or hour) to prevent excessive use."

reillyg: we can come up with some specific values
… based on experience and data collected

CRS plan, obsoletion request

anssik: the WG wants to refresh the spec at /TR to do so we need to publish a CR Snapshot given Process 2015 does not enable revising a Recommendation
… the process provides us means to obsolete the Recommendations that we cannot update in place, and I'd recommend we do that when we publish the CR Snapshot

proposed RESOLUTION: Request AC to publish the current Vibration API Recommendation as Obsoleted Recommendation and the group will publish a new CR Snapshot with the latest changes incorporated.

RESOLUTION: Request AC to publish the current Vibration API Recommendation as Obsoleted Recommendation and the group will publish a new CR Snapshot with the latest changes incorporated.

Device Posture API

Repository: w3c/device-posture

anssik: Origin Trial active

Trial for Foldable APIs

Wide review feedback

anssik: wide review #146 nearly completed

<gb> Issue 146 Wide review tracker (by anssiko) [process]

anssik: one a18y issue open #151

<gb> CLOSED Issue 151 Device posture and direction interaction (by aphillips) [i18n-needs-resolution]

anssik: special thanks for a11y for Accessibility Considerations

https://www.w3.org/TR/device-posture/#accessibility-considerations

alexis: no Mozilla or WebKit position
… for testing, we have w-p-t landed

Candidate Recommendation plan

anssik: with wide review completed, wpt testing story in place, and no blocking open issues, we've be ready for CR
… do we want to await for Origin Trial feedback prior to making a decision?

alexis: I would think of sending Intent to Ship in the coming weeks

alexis: #111

<gb> Issue 111 Should Device Posture API be exposed to iframes (JS or CSS) (by darktears)

alexis: CSS exposes this same information to iframes already

anssik: we are ready for CR transition request?

atsushi: I will check with the privacy colleague to confirm PING review status
… if the WG is fine I'd like to submit the request for publication

proposed RESOLUTION: Start CfC to publish CR of Device Posture API

RESOLUTION: Start CfC to publish CR of Device Posture API