Meeting minutes
Repository: w3c/devicesensors-wg
<plh> Philippe Le Hegaret, W3C
<Penelope> + Penelope McLachlan
Welcome
anssik: Welcome to Devices and Sensors WG F2F!
anssik: IRC https://
anssik: Zoom https://
reillyg: we'll use queuing system on IRC, we don't use Zoom chat
Charter update
Repository: w3c/das-charter
anssik: WG chartered until 2024-11-30
Devices and Sensors Working Group Charter
anssik: Apple has shared it is interested in contributing to a subset of the WG's deliverables, so in order to get Apple onboard we are looking to recharter earlier than that
… Apple has indicated it is unable to join the DAS WG at this time
… a proposed solution is to broaden joint deliverables with WebApps WG
anssik: summary of proposed changes:
… New joint deliverables:
… - Screen Wake Lock API
… - DeviceOrientation Event
… - Geolocation API
… open issue, "joint deliverable" not defined
https://
<plh> w3c/
<marcosc> w3c/
<plh> (#754 links to w3c/
<gb> Issue 754 [not found]
hober: We haven't defined joint deliverables in the process but we've been doing them for 20 years.
… plh, have there been any problems doing joint deliverables?
plh, No, we have not had any issues but there was an issue back in 2014 which was postponed in 2016.
… As I understand it the current issue is not patent issue, but a decision policy+success criteria issue.
hober: I don't think we need to block rechartering on the process cg resolving this issue. I trust the chairs of both groups and there's an escalation path if we do have a problem.
anssik, I agree there hasn't been a problem in the past but I see that there are disagreements in this group which may require resolution.
… I propose that we integrate this work into our charter and it can then be brought into the W3C Process after being tested here.
hober: Do you want to bring those two issues: exit criteria and scope, up for discussion now?
hober: Straw person: Narrower scope wins, stronger exit criteria wins.
anssik: Example: WebApps WG may have a stricter scope for Geolocation API.
hober: Specifications don't have scope, working groups do.
… If one WG has a proposal for a spec that is out of scope for the other WG then it can't go into the joint deliverable.
… That is defined based on the current W3C Process requirements for a Working Group.
anssik, I think the same principle applies for scope as well.
… For out of scope as well. The narrower scope wins.
plh, It might be defined in the Process but it could be a Guide issue.
hober: (Looks at plh) If only someone in this room could update the guide.
… Each group is responsible for upholding its own exit criteria.
anssik, To pass the joint deliverable success criteria it must pass both.
hober: If the two group's criteria are in conflict then we do have an issue.
anssik, If one group decides to drop a deliverable, then which success criteria does the remaining group have to satisfy?
hober: Only the criteria of the remaining group, since only one group is chartered to produce the deliverable.
anssik, We will make the decision policies the same if there are different but they appear to be the same between the two proposed charters.
plh, The lesson seems to be that the W3C should not charter WGs with joint deliverables with conflicting success criteria or decisions policies.
hober, the two groups don't need to send CfCs at the same time that's great but it's not required.
… If one group does not find consensus on an issue while another does then we need to go through the escalation path.
… To conclude I believe we've addressed each of these concerns in this discussion.
anssik: What follows is that it is undefined what happens if the two WGs, for example:
disagree on whether a proposed new feature is in scope (or out of scope) of a joint deliverable,
disagree on whether the joint deliverable meets (or not) the success criteria for advancement on the Rec Track,
disagree on which decision policy is used for the joint deliverable
plh, If you want to transition to CR then each working group needs to agree to transition to CR and if there are disagreements they need to be resolved before the document can transition to CR.
… The guide would be a good place for this guidence.
… I'm documenting this in issue 754 now.
anssik, Do we need to ask for legal advice on the Patent Policies?
<plh> w3c/
hober:
plh, I would welcome feedback on this before we submit the charters to the AC.
anssik, Any objections to linking to the guide in the charter?
… No objections heard.
marcosc: Do we have agreement to submit these charters to the AC?
plh, As the next step we need to start horizontal review.
<plh> w3c/
plh, We haven't started horiz review for WebApps either.
<scheib> scheib: The draft charter geolocation entry doesn't seem to be marked as a joint deliverable? https://
<Zakim> charter, you wanted to discuss geolocation?
marcosc, I think the Geolocation API should be listed in the normal deliverables section.
anssik, Should we move everything in the maintenance section?
marcosc, Let's make no changes if we don't have to.
anssik, Agreed.
rakuco, From an editor point of view, what changes should I made when sending a PR?
… What IPR applies? Should I file two issues?
plh, As a general principle both charters apply, including the Patent Policy.
… There can't be conflicts in the Patent Policy or Decision Policy because they are the same.
… If they weren't then those need to be resolved before chartering.
… If there are conflicts in scope the narrower scope applies.
PROPOSED RESOLUTION: The proposed update to the Guide resolves the open questions on the joint deliverables process and both Working Groups may proceed to begin horizontal review for their proposed charters.
atsushi, Do we need to do a CfC?
plh, It is immaterial to me.
PROPOSED RESOLUTION: The proposed update to the Guide resolves the open questions on the joint deliverables process and both Working Groups will proceed to begin horizontal review for their proposed charters.
<marcosc> MC: 👍
RESOLUTION: The proposed update to the Guide resolves the open questions on the joint deliverables process and both Working Groups will proceed to begin horizontal review for their proposed charters.
anssik, We are taking a break for 30 minutes.
Privacy & Security
anssik: This WG is chartered to develop secure and privacy-preserving specifications
… we have a good collaboration going on with TAG and PING on privacy, most recently met with PING to discuss our privacy mitigation success for the Compute Pressure API
… I want to bring to the WG's attention substantial piece of work, Privacy Principles, delivered by TAG and PING
Privacy Principles
… "This document provides definitions for privacy and related concepts that are applicable worldwide as well as a set of privacy principles that should guide the development of the Web as a trustworthy platform."
Heads up: Privacy Principles nearing end of wide review
anssik: principles on a topic-level:
… - Data Minimization
… - Information access
… - Consent, Withdrawal of Consent, Opt-Outs, and Objections
… - Notifications and Interruptions
anssik: Example of principles we've applied in our work:
… Data minimization, e.g. https://
… Consent "It should be as easy for a person to check what consent they have given, to withdraw consent"
… this doc also defines privacy-related concepts that could be referenced by web spec, examples:
anssik: this doc is "W3C Group Draft Note" but the intent of this is to become a W3C Statement
reillyg: I was going to bring this up later in the Geolocation API discussion, but an area where there is possible future work on Geolocation relates to data minimization
… geolocation works on native platforms as such there's split between coarse and fine-grained geolocation
… W3C Geolocation API provides highAccuracy flag, but the definition is not clear
… we don't have a set of incentives for web developers to request coarse geolocation
… the WG should define the highAccuracy flag properly
… and incentives to provide to sites to only provide coarse geolocation, to get the data that they need and only that
anssik: any other topics re Privacy and/or Security?
tomayac: it is a really good doc
Permissions
anssik: I wanted to share the key takeaways from a W3C Workshop on Permissions workshop relevant to this WG.
… held 5–6 December 2022 at Google Munich office
… I sat on the Program Committee and felt we had a good discussion, participation from all browser vendors, other key contributors, researchers, but importantly UX/UI design experts
Workshop report
… Some key takeaways:
… - significant interest in non-prompt, contextual permission UIs
… - “user-pull” model instead of the “developer-push” model
… - User agents could surface additional signals to support informed user choices e.g. purpose declarations by developers
… - research needed: effectiveness of browser-owned UI that crosses the so-called line of death to mitigate spoofing risks
… - agreement that getting the UX of permission flows right is a core aspect of making capabilities work well
… - desire to better incorporate considerations around UX into standardization work
… API design: tension between being known-use-case driven vs. generic-purpose APIs
anssik: reillyg you want to share something about <permission> element?
reillyg: the proposal from penny is a HTML element to combine the current way we suggest developers to implement permission prompts to have a button somewhere to trigger a permission UI
… web developers can request a permission in response to click, sometimes page load etc.
… this element creates that UI, a browser controller element
[ MarianH explaining the UI concept of the element ]
MarianH: want to mitigation clickjacking
… if the button moved, it is not clickable for 500 ms
… if any CSS attributes are manipulated, we also make it unclickable
… this is desktop only for now, OT late/early next year
… doing this for gUM first and then Geolocation API
… icon is tailored to the capability, implementation-defined icon
… the button text and icon is provided by the platform, localized
… dev trial late Oct, then it is available to play it
rakuco: is there one button for each permission?
… one for motion sensor, one for gUM etc.?
MarianH: that is correct
anssik: bundling and <permission> element, are these related?
MarianH: trying to keep them separate for now
anssik: user studies?
MarianH: synthetic experiment with Google Meet with good results
mattreynolds: this is probably out of scope, in context of device APIs, WebUSB etc. with permission prompts
… how to support that?
MarianH: not discussed that yet
… we're not changing the trusted UI, omnibox and picker hanging off of it stays as is, this button is placed in the center of the screen
anssik: is size and/or position of the button customizable?
MarianH: little bit of sizing option
anssik: similar <input type=file>?
MarianH, File picker is our original inspiration for this.
Test automation
anssik: A session to discuss the WG's approach to test automation using WebDriver and recent progress in this space.
rakuco, The goal is to test the sensor APIs without depending on the presence or behavior of the device's real sensors.
rakuco: We added WebDriver integration to the specification after discussing at TPAC 2018.
… For various reasons neither an implementation nor WPT updates did not land.
… Instead the current tests depend on Chrome-specific technology.
… The tests end up relying on some implementation-specific behavior because of that.
… This architecture also means that not all of the implementation backend is exercised by the tests.
rakuco: Goals:
… - Have an implementable spec
… - Implement the spec
… - Reduce adoption barriers by having web tests that use the WebDriver endpoints
… - Make WebDriver available to any other developers writing tests
… - Learn how to do this so we can add WebDriver interfaces to more specs
rakuco: Status:
… - Specification concepts have been cleaned up.
… - Main PR is under review.
… - Implementation is under review.
rakuco: It is not currently possible to test some cross-origin scenarios because of how set_permission() is defined by test_driver.
rakuco: There is some overlap with the DeviceOrientation Events spec, but it doesn't define how the API maps to underlying sensors.
reillyg: do we think we're able to write implementation tests for DeviceOrientation Events API using this new WebDriver API?
… maybe we pull in WebDriver stuff into a virtual sensor spec to be referenced by both? Is that the right interface for testing?
rakuco: I don't see why that wouldn't work for the DeviceOrientation Event
… more of a spec questions, would duplicate a lot of the information we already have for Generic Sensor API
… from spec editing perspective, WebApps may be inclined to add a dependency to Generic Sensor API for test automation bits
reillyg: proposal to write these WPT tests in terms of WebDriver interface
… next step for the joint working group tasks is to start the CR process for DeviceOrientation Event
… includes interop and test coverage work
… good starting point for discussion with other implementers, others may propose simplification to make it applicable for DeviceOrientation Event but may not work for Generic Sensor-based APIs
… DeviceMotion is a fusion of accelerometer+gyroscope data, it makes sense considering how this is implemented to make the test API for both these low-level APIs separately and bubble that up
rakuco: from process perspective, if we use the existing tests in WPT, wouldn't that require change to the spec for that first?
reillyg: nothing that says how your tests should work, wide review looks for interop
… only concern is if interop with other vendors have objections to the WebDriver API shape we use now, probably not a real issue
… WebDriver is a dependency for the tests
… it will be interesting
<scheib> Want to extend Web Driver BiDi with w3c/
vincent: small addition, WebBT has pursued some testing work as well, we want to extend the WebDriver bi-dir spec
… the need here is a user with WebBT, the user needs to be populated and simulated
reillyg: we're the first WebDriver extension that use bi-dir feature
vincent: proposal is from Bocoup, GH issue mentioned above has the contact
Generic Sensor API
Repository: w3c/sensors
Modernization
anssik: Raphael is modernizing the spec with the new best practices w3c/
rakuco: filed issue #463 based on what I was working on WebDriver and found areas where to modernize things, improve
<gb> Issue 463 [Meta] Proof-read and modernize spec (by rakuco)
rakuco: we did wide review for this spec some time ago and wanted to refresh for the best practices, e.g. privacy considerations split from security considerations
anssik: any PRs open?
rakuco: no open PRs to be looked at by the WG
anssik: concrete sensors to be refreshed?
rakuco: some references could be tweaked a bit, mostly editorial stuff simple to solve
reillyg: re timeline for wide review, consensus from other implementers is the Generic Sensor API family does not provide adequate value to replace the DeviceOrientation Event so not recommending a complex wide review at this time
… want to wait on wide review until there's clearer buy-in from other vendors
… we have a lot of specs on our plate, and asking wide review on many of those at the same time would clog the review pipeline
… rather, we initiate wide reviews in phases, first with DeviceOrientation Event
… getting DeviceOrientation Event to Rec would be important step
Factory calibration and fingerprinting
<gb> Issue 404 device fingerprinting may also refer to the factory (or other) calibration of the device (by npdoty) [privacy-tracker]
anssik: SensorID paper discusses how factory (or other) calibration of the device could contribute to a device fingerprint
… I recall SensorID paper was discussed in more detail in w3c/
… based on this data we are not clear whether Sensor Calibration Fingerprinting proposed in the SensorID paper is working on current mainstream devices
… should we cite SensorID paper in the Generic Sensor API as suggested in #404 even if results are not consistent? We could simply add [SENSORID] as a new citation to this existing list in https://
"These manufacturing variations and imperfections can be used to fingerprint the device [ACCELPRINT] [MOBILESENSORS]."
reillyg: we did add a normative requirement to DeviceOrientation Events spec
JensenPaul/
reillyg: a Chromium developer documented a mitigation and the proposal was to round the values to the nearest 0.5 degrees
reillyg: this change was merged into the DeviceOrientation Event and we merged a mitigation match to Chromium and bugs were opened for Gecko and WebKit and both are still open
… summary of the current state is, we have specified to mitigations for this issue in DeviceOrientation Events spec, 1st is to have permissions specified, 2nd we have rounding of the values to mitigate against factory calibration to be detected by web sites
anssik: did we port these over to the Generic Sensor-based specs?
reillyg: I think the open issue is to port over to Accelerometer and Gyroscope spec, I believe the Chromium implementation does implement the mitigations defined in DeviceOrientation Events?
rakuco: I think so, Chromium implementation of Generic Sensor-based APIs is fine and mitigations are in place
… we have to update the Generic Sensor-based specs similarly to match the implementations
reillyg: I think we want to share the recommended values with DeviceOrientation Event, Orientation Sensor is more complex because we use quartenion
… what type of rounding is appropriate for quartenion, need to be addressed
… the other thing, hardware vendors have mitigated this either on HW or OS-level with additional mitigations in place
proposed RESOLUTION: Ensure Generic Sensor-based specs have mitigations normatively defined for factory calibration device fingerprinting
rakuco: in implementation we do rounding at the Euler angles level
… there should be rounding on all the levels
reillyg: fusion concept is not fully defined in the spec, in implementation we can have software sensors based on multiple hardware sensors
… fusion sensors get raw values and individually round the values
… you get from the platforms these values in Euler angles and then convert to quartenion
… this conversion is implementation-specific
… we could add a note "if you convert, please do not round twice"
… if there's an impact on tests we could be testing our fusion sensors with the infra we're adding
proposed RESOLUTION: Ensure Generic Sensor-based specs have mitigations normatively defined for factory calibration device fingerprinting matching existing normative mitigations in the DeviceOrientation Events spec
RESOLUTION: Ensure Generic Sensor-based specs have mitigations normatively defined for factory calibration device fingerprinting matching existing normative mitigations in the DeviceOrientation Events spec
Accelerometer
w3c/
anssik: would it be better to discuss generic types of privacy and security threats in the Generic Sensor API and not duplicate this information to concrete sensor specs? Thoughts?
https://
reillyg: This was discussed previously and we resolved to file and fix this issue across each of the sensor specifications.
We say at the end: "These mitigation strategies complement the generic mitigations defined in the Generic Sensor API [GENERIC-SENSOR]."
reillyg: if we normatively define the mitigations, we have to reference something, either the paper directly or Generic Sensor API section that has the reference
Gyroscope
anssik: no issues
Magnetomer
anssik: none issues to discuss
anssik: Web dev req for >>60 Hz sampling
Orientation Sensor
Head orientation tracking w3c/
anssik: wanted to revisit for new information from an expert in this domain
… problem statement reads: "one or two companies "define spatial audio" as a proprietary feature instead of releasing tools to let everyone access orientation from devices and handle multichannel audio in a more agnostic fashion"
… what would be required to pull this off AFAICT would be a HeadOrientationSensor that could be used with the Web Audio API's AudioListener interface https://
… based on comments it looks like one can already use WebXR to pass head orientation to WebAudio to get VR headsets support spatial audio
… thoughts? It's been a while since touching this issue, but wanted to do a pulse check
reillyg: WebXR is a better place for these integrations, because you're in XR context so can get higher resolution readings
… device question is another angle, this is not using laptop or phone, you need a spacial headset, or an XRs-style device
… thinking this as an audio only XR experience
reillyg: there's opportunity to share the API shape even if it'd be only available in XR context
DeviceOrientation Events
anssik: WebApps WG https://
… - Priv/Sec issues
… - Spec maintenance
… - aligning with Permissions spec
reillyg: interest to take this through the Rec Track
… some of the to be addressed issues listed above
… wondering what is the state of the permissions implementation in Chromium
… requestPermission() method, we didn't implement a prompt, we report the method is used
… we didn't figure out a way to change this without breaking existing content
… this is new feature in Safari, we can maybe make a breaking change in Chromium
rakuco: per Chrome Status requestPermission() usage is very low
… that would raise some feathers?
reillyg: any site that has legit interest in using the API will have migrated to requestPermission()
… the remaining usage of permission-less is from unsupported use cases such as fingerprinting
… from spec perspective, we should let Antifraud CG know we're planning to do this change
rakuco: if we make this change in Chromium it would mean we'd do this for Generic Sensor-based APIs also
… Permissions Policy, should we discuss that? WebKit does not implement that spec.
reillyg: Permission Policy checks are implemented in Chromium, not WebKit
… but WebKit implements permission checks
… if WebKit does that, it is an area that overlaps with Generic Sensor API, names used by WebKit are from gyro and accelerometer
… the enum values are shared
Repository: w3c/deviceorientation
rakuco: Permissions API integration is blurry
reillyg: what powerful feature name WebKit uses?
reillyg: we don't need to investigate this at this meeting, we can move toward resolution on the work we want priortize here
… two spec changes that we want to make are to specify integration with Permissions Policy and replace the bespoke permission concepts from DeviceOrientation Event spec and reference the Permissions API
anssik: we have some PRs that are awaiting joint deliverables being operational
PROPOSED RESOLUTION: Resolve the blockers to beginning the Recommendation process by resolving issue #64 and #70, and work with implementations to resolve interop issues in these areas.
<gb> Issue 64 Add integration with Feature Policy (by reillyeon)
<gb> Issue 70 Add integration with the Permissions API (by reillyeon)
rakuco: Was there an issue discussing removal of deviceorientationabsolute?
reillyg: after solving the fingerprinting question we are better informed on this issue
… I'd like to seek input from other implementers if absolute is worth keeping
RESOLUTION: Resolve the blockers to beginning the Recommendation process by resolving issue #64 and #70, and work with implementations to resolve interop issues in these areas.
Ambient Light Sensor
rakuco: not much progress since last year's TPAC
Repository: w3c/ambient-light
rakuco: This bundling is quite novel and we're not quite sure how to do it.
… There is also a question of priority.
tomayac: We considered the ALS to be a 1x1 camera.
… There was no use case which wouldn't be resolved by this model.
rakuco: The initial problem was how do you explain what an ALS is, so the proposal was to integrate it with camera permission.
… The issue was that the camera capture system is complex.
… But also if this is combined with a camera can you satisfy these use cases with only the camera and not the ALS.
reillyg: from talking to Invited Expert from last year is, it is valuable to have ALS in addition to camera, can be used to improve camera image with additional information about the surroundings
… summary, we did not have time to follow through the details of this
Proximity Sensor
anssik: no issues to discuss
Geolocation Sensor
Repository: w3c/geolocation-sensor
anssik: a vocal group of web developers has been asking us to do "background geolocation" and or "geofencing" API for many years
… our standard response has been, it would be easy mechanically to pull those off but there's no consensus on how to do that in a privacy-aware way
… I understand the frustration of web developers because we've circled around this API for many years
… Tom formalized the use cases a few years back and we parked them in the Geolocation Sensor spec that is "all things v2 geolocation"
Use cases
… the web developers are mostly asking for these background operations:
- Getting continuous geolocation updates (aka. background geotracking).
- Getting a one-off geolocation fence alert (aka. background geofencing).
reillyg: we are bound by implementers moving together with this
… background geolocation or geofencing enables interesting use cases
… Use case contributions since last discussion:
Repository: w3c/geolocation-sensor
- Geolocating sports event competitors #50
<gb> Issue 50 Use Case: Geolocating sports event competitors in real-time (by fadarnell)
- Taxi ride share https://
- Insurance prices and coverage level based on the country w3c/
- Notify the driver when arrive at a location w3c/
- A bike ride tracking app w3c/
- A mountaineering app which keeps track of your movements even while the phone is locked w3c/
- A driver app for a taxi provider w3c/
- Another tax app w3c/
… Workarounds:
… - Capacitor web location tracking capacitor-community/
… Proposals:
… - Simple UX: allow only 1 website to track location in the background with an always-on UI to disable/view status w3c/
… - Wake Lock + Background Geolocation (@tomayac) w3c/
<gb> @tomayac
Screen Brightness API
Repository: WICG/screen-brightness
anssik: this API was actively discussed at TPAC 2022, minutes https://
… our consensus was to explore a declarative approach for allowing web developers to ask the browser to increase the screen brightness
… we also received a request from Apple to move this API proposal to WICG to allow Apple contributions, this migration was done:
anssik: since this WICG migration Apple has been unable to contribute at all
… this does not need to block our progress on this proposal
… iProov has been a strong supporter of this feature
reillyg: I think this is a great idea, we just don't have enough bandwidth on the implementation side to look into this
rakuco: I haven't been involved since this moved to WICG, I created the initial explainer and Francois took that work over
… this originated from WICG, moved to DAS, then back again
[ breaking for 23 minutes until 16:00 ]
Screen Wake Lock API
Repository: w3c/screen-wake-lock
reillyg: not so much to discuss here, Apple filed these issues we listed on the agenda
… we're awaiting joint deliverables operationalization on these
… then resolving these is easy
… #352 is about what names we should use for error conditions
<gb> Issue 352 Distinguish exceptions on .request() (by marcoscaceres)
reillyg: we think we can resolve this once we get to work on this
reillyg: #350 is more interesting
<gb> Issue 350 Require transient activation to request lock (by marcoscaceres)
reillyg: I've seen a proposal for sticky activation and it was discussed in WebApps meeting on Monday
… Chromium has data showing a large number of requests don't have user activation
System Wake Lock API
reillyg: at TPAC 2022 I noted a proposal how we could support System Wake Lock API
… the interesting thing is that this proposal would suffice for use cases beyond System Wake Lock
… the problem we solved with Screen Wake Lock was there are cases where the browser had to keep the screen on, show video or keep WebRTC connection
… Screen Wake Lock is appropriate for those use cases
… there are other scenarios where additional hints are necessary for the site to communicate to the browser to understand that the site is doing something that it cares about, and for example, with system wake lock, a long-running compute task needs to not be interrupted
… but there's no way to tell inappropriate use e.g. a timer that runs on a tight loop from e.g. file upload
… this applies to both the cases where the site might acquite a system wake lock
applies to site acquires a system wake lock and the site is in the background
reillyg: in the case of background, UAs throttle resource consumption in most cases
… there is a need for an API where the site can tell the browser I do something the user cares about
… I don't have folks working on this but there are good use cases, an opportunity for us to look at System Wake Lock in the future
anssik: do you have a customer for this?
reillyg: yes
Repository: w3c/compute-pressure
Contact Picker API
reillyg: not aware of recent work for this API
<tomayac> tomayac: It's implemented in Android and behind a flag on iOS for a long time now.
anssik: nothing more to discuss at this time
Battery Status API
Repository: w3c/battery
anssik: these was a long-standing feature request by web developers to allow detect power saving mode that gardened substantial support signals w3c/
… I drafted an explainer to synthesize the discussion:
Energy Saver Mode explainer
… anssik: Problem:
… The end user expects modern web applications to use less energy when the OS-level energy saver mode setting is turned on. Web authors have currently no means to apply such optimization on demand informed by this signal because it does not exist.
… Proposed solution:
… API to expose the OS-level energy saver mode state and a corresponding signal.
… This is a read-only boolean, so data minimization principle applies.
… No way to toggle the power saving mode, only using OS controls.
… Platform support:
… - Android isPowerSaveMode boolean
… - Windows EffectivePowerMode* enum values
… - macOS and iOS lowPowerModeEnabled boolean
… Current status: Web developers want this API, minimal privacy impact, implementable on major platforms.
… Up for grabs?
tomayac: I've seen a "user preference" media feature and "prefers reduced data"
<tomayac> This could be modeled like `prefers-reduced-energy-consumption` https://
Device Posture API
anssik: first Alexis to give us an update on the implementation and the remaining spec work
… then I'd like to discuss if we're ready to kick off wide review
[ alexis presenting slides ]
alexis: market update on foldable devices, two Samsung phones, Chinese OEMs with foldables, Google Pixel Fold, three new foldables PCs in 22/23
… fixing usability issues such as seam causing image distortion when placed where the seam is
… dialogs are hard to interact with when placed at the center of the foldable screen
… browsers can fix this for build-in dialogs but not for UI frameworks
… examples clipchamp from Microsoft, web video editor with video placed above the screen seam and controls below
… split UX for common apps such as email, video streaming service, video games
… what the browser needs: top segment in px, fold size in px, bottom segment in px
… non-symmetrical usage where the keyboard slides away
… Device Posture API in Chromium, partial implementation, Android and Windows backends expected
… implementation challenges:
- Windows, no Windows OS API, OEMs have a preinstalled software that provides this information
alexis: - Android, no Chromium upstream implementation, blocked on androidx.window dependency
alexis: current implementation status, behind a flag in Chrome and Edge on Windows
… Android implementation
… CSS media feature and JS API defined in the Device Posture API
… TAG review completed in 2020, suggest to start wide review to capture wider feedback, e.g. privacy
… next steps, proposal to move forward in W3C process, WPT, devtools support, some implementation work for fullscreen video player
anssik: thanks for the demo!
anssik: proposed next step to start wide review
tomayac: cool demo! angles are no longer exposed through the API?
alexis: true, angles removed per TAG feedback abstracted into a set of posture modes
tomayac: use case, you see advertisements when on a stadium with perspective correction when the side walls are tilted
reillyg: nothing to add to what Anssi said
… I think this is ready for wide review, given this exists in Windows and Android ecosystem, we should ask what is Mozilla's position and multi-vendor position
… if no obvious blockers then we can move forward
alexis: that prevents Mozilla to implement this API
<tomayac> One use case for fine-grained angles would be perspective correction similar to cam carpets in stadiums (example: https://
){kind=link}
reillyg: no standards position filed for Mozilla?
alexis: correct, I'd like to start Origin Trial
reillyg: I'd prefer to ask Mozilla's position now
alexis: Viewport Segment API is complementary so working on that in parallel
reillyg: these reviews are non-blocking can request them in parallel
reillyg: the Chromium fullscreen video issue, you can fix that by CSS
Repository: w3c/compute-pressure
Compute Pressure API
Wide review and PING feedback
anssik: wide review #177 has been completed, I'd like to discuss what changed and what we learned
<gb> Issue 177 Wide review tracker (by anssiko)
anssik: for testing the implementation, Chrome Origin Trial is available until 5 Jan 2024 https://
… most substantial wide review contributions came from PING and APA WG for privacy and accessibility respectively
… we had F2F discussion this Tue with PING for privacy and APA for accessibility considerations
… for privacy we received a contribution for a possible cross-site covert channels attack #197
<gb> Issue 197 Feature can be abused to create cross-site covert channels (by pes10k) [privacy-needs-resolution]
anssik: we addressed this by describing this attack in prose: https://
… and by defining the mitigation normatively, changes summary: w3c/
kenneth: We went ahead and prototyped the side-channel attack and I have some slides about that.
[ kenneth presenting slides ]
kenneth: Compute Pressure exposes global state and that can be used to create a side-channel.
… For example a site could artificially create a pattern of compute pressure that is visible to another site and thus communicate a value.
… We found that there were machines where we couldn't reproduce this, for example if there were background apps.
… Our demo is not perfectly reliable but it works.
… We worked with the PING to develop mitigations.
… We provide additional data at random which breaks the calibration of the attacker.
… We also manipulate the observation window when we detect that pressure state changes suspiciously frequently.
kenneth: Open question: Should apps be told that the penalty is in place?
<Zakim> sangwhan, you wanted to ask about how mitigation affects usability after presentation
sangwhan: Adding mitigations will likely add a tradeoff in the usefulness of the API because we're adding noise.
… TAG had similar concerns to PING but we dismissed these concerns because there are other ways of observing this side channel. e.g. creating CPU pressure and observing frame times.
kenneth: When experimenting with this we found that it is very noticeable when this is being abused.
… This really shouldn't be an issue for regular applications.
<sangwhan> TAG discussion from the past: https://
kenneth: If you want to do this attack and not have anyone notice then you have to do it very slowly.
sangwhan: I'm concerned that we've sacrificed usability for an unnecessary mitigation.
… Is there a general distaste for permissions here?
kenneth: Conferencing applications already have to ask for a lot of permissions.
sangwhan: You could enable the API with the mitigation when the site doesn't have permissions.
reillyg: I think I agree with Sangwhan's perspective
… now the API is available in OT developers can use it and tell and prove to us it helps them
sangwhan: We have two other resources where there would be pressure: memory and storage
… We should distill best practices from this work to apply to this future work.
Proposed v2 issues
anssik: we have a number of v2 features proposed by the community:
#228 Catch-all source that considers global thermal and power constraints
<gb> Issue 228 Does compute pressure reflect OS-level speed limit changes due to throttling? (by brycepj) [question] [V2]
#211 Automated performance regression testing
<gb> Issue 211 Use Case: Automated performance regression testing in Utopia (by Rheeseyb) [V2]
#120 Memory stalls
<gb> Issue 120 Use-case: Memory stalls (by kenchris) [V2]
#119 Optimize for long battery life
<gb> Issue 119 Use-case: optimize for long battery life (by kenchris) [V2]
#8 Current process contribution
<gb> Issue 8 Use-case: Current process contribution (by alexcyn) [V2]
reillyg: Suggestion on #8, a single "it's you" flag when the current document is responsible for > 50% of resource consumption.
Geolocation API
anssik: WebApps was interested in this proposed joint deliverable, had proposals for:
… - WebDriver Testing API
… - toJSON()
reillyg: Geolocation API is a Recommendation
… I think Geolocation API is in a relatively good shape
reillyg: WebDriver would probably be simple from Chromium implementation perspective
… another proposal is toJSON() to return a JSON serialization of geoposition
… also third idea for coarse location option, today we have highAccuracy flag that turns on GPS receiver, in general in native platforms have separate UI permissions for coarse and fine-grained permission
… we should follow suit there, the challenge is on figuring out the incentives for developers to not to choose the high accuracy geolocation
anssik: Less friction for coarse geolocation could be an incentive.
… But developers can also already do GeoIP without prompting and that is coarse location.
reillyg: implementations have shipped one-time permission for Geolocation API
… the most common one-time grant on the platform
Wrap up
anssik: Time for synthesis of key outcomes, next steps