Meeting minutes
Device Posture API
Kenneth: had some difficulties in exposing the fold, privacy issues and upcoming devices not ready yet
… we're considering on postures driven by key use cases, spec renamed to Device Posture API to reflect the new tighter scope
… waiting for more devices to come to the market
… Alexis has been implementing this API on Windows and can give an update
Alexis: in Chromium some bits are landing, including Media Query parts
… Samsung has submitted a patch for IDL parts in review as of now
Alexis: next step Android and Windows backend implementations
… Android backend implementation expected to be more straightforward
… on Windows no official API to access hinge angle so a bit challenging
… some devices exposing a custom sensor, working with Intel's fw team to improve reliability of readout to meet the requirements
… in the future we expect an OS level support on Windows, considering other factors e.g. keyboard attached etc.
lgombos: thanks for the update, you mentioned adding support for Windows
… any information, which actual browsers on Windows would support that?
Alexis: from Intel's POV we're indifferent
… working to get the feature behind flags on all Chromium-based browsers
lgombos: any feedback from Microsoft?
Kenneth: positive
Alexis: OEMs such as Lenovo are extremely keep and eager to get something on the web, not just web sites supporting new form factors, but making the browser a better citizen
lgombos: the API doesn't depend on a foldable device
Alexis: you could retrofit the API in a 2-in-1
anssik: any high priority open issues for the spec?
Alexis: more open discussion on the posture computation in which case we return which posture
anssik: that is mapping of angle range to postures?
Alexis: correct
Laura: to clarify, in the short term we can discuss how to define the "posture", that is missing
… should be a quick fix
Reilly: looks like the spec had been recast from the Fold Angle to Device Posture API
… mitigates privacy and fingerprinting concerns
… what is the current privacy review status?
Kenneth: PING has not looked at this, TAG has and the new scope seems good for the TAG
proposed RESOLUTION: Initiate PING review for the Device Posture API
Reilly: PING review can happen in parallel with Origin Trial
… the number of bits of entropy are the minimum necessary to implement the use case
… seems to mitigate most of the concerns of sharing device state between the pages, hopeful this gets through PING review
Alexis: not too many foldable devices at this moment, so could help narrow down on devices of this class, but time will take care of this as more devices become available
Vincent: the more explicit use cases we can provide, the easier it is to reason about them
… the current spec explains the concepts, but should add some easy to understand use cases to the spec
proposed RESOLUTION: Refine use cases and then initiate PING review for the Device Posture API
Resolution: Refine use cases and then initiate PING review for the Device Posture API
Screen Wake Lock API
<anssik> Screen Wake Lock API
<anssik> Recent updates to modernize the spec language e.g. https://
Raphael: I'm happy to report that nothing too exciting or controversial has been happening.
… Since TPAC there's been cleanups and tidying of spec language.
<tomayac> Usage overall goes slowly up: https://
Raphael: Improved "in parallel", added a task source, fixed up permissions API integration.
… Most of these changes don't have user-visible effects.
… Chromium is in sync with the current version of the specification.
… Not much future work in the queue. Screen brightness could be added as an extension. Will discuss on Thursday.
… There are implementation details which could be improved. For example, Anssi's request to integrate with user proximity detection.
<anssik> editorial: Remove the "obtain a permission" algorithm
Raphael: The spec has a custom model for obtaining permissions. There is an open question about whether it should be removed and/or this logic merged into the Permissions API.
Anssi: Do you see any other specs that should be similarly refactored?
Raphael: It is worth taking a look at those specs. I will take that AI.
Action: Raphael to check if other DAS WG specs are doing "in parallel" properly
Lars: Maersk is using User Presence for dashboard applications.
<anssik> larsgk: we use Screen Wake Lock API for our use cases for mission critical monitor
Lars: We use the Screen Wake Lock API for mission critical monitors.
System Wake Lock API
Reilly: Last TPAC resolved to write new explainer. Separated repositories from screen lock.
… No recent movement on use cases or pressure to implement.
Anssi: Dev rel folks, have we heard anything?
Tom: There was a partner with geo-tracking use case which considered keeping phone active. However, noting this would have poor power impact.
<anssik> TPAC 2020 resolution
Reilly: From TPAC resolution, noted we shoujld find non-geo-tracking usecases.
<tomayac> GeoMover: https://
Reilly: Nascent use-cases of large operations, e.g. compute, are in progress and the system should stay awake.
Anssi: Situation similar to last TPAC then, awaiting further clarifying motivating use-cases.
Battery Status API
<anssik> Battery Status API
<anssik> Assess compatibility risk of using [SecureContext] (issue #15)
Anssi: This is an old API which could use improvements.
… This is one of the rare APIs with custom/explicit SecureContext checks vs current IDL constructs.
… Chrome implementation did not use this custom spec wording. Wording has been removed from spec with reference to issue #15.
… Seeking implementor to update e.g. chromium and spec. Raphael might do so.
Raphael: Might be a smaller/moderate change.
Reilly: Support for Deprecating, with measurement of usage etc. Might frame this as an intervention for privacy. Step 1 is to measure.
Anssi: Use counters are in place.
<anssik> Non-secure HTTP usage is now at ~0.38% per https://
<tomayac> https://
Reilly: Since measurement exists, then next chromium step is Intent to Deprecate
… Create a chrome status entry, send Intent with links to spec discussions.
<anssik> proposed RESOLUTION: Advance with deprecation of non-secure usage of the Battery Status API in coordination with implementation
<anssik> scheib: we should circulate the intent to deprecate within a group of involved people to ensure it is well crafted, include measurements
scheib: Noted current shipping status is Chrome only, other chromium browsers e.g. Samsung, Edge, not indicated as shipping on https://
<anssik> proposed RESOLUTION: Advance with deprecation of non-secure usage of the Battery Status API in coordination with implementation
Resolution: Advance with deprecation of non-secure usage of the Battery Status API in coordination with implementation
scheib: Apologies, that information is wrong, was looking at wrong API. Battery: https://
Geolocation API
Explicitly limit permission lifetimes
Pete: Explicitly limit permission lifetimes #69
Pete: this issue is a result of PING review, geolocation information is very sensitive, so privacy considerations need to be carefully reviewed
<tomayac> FWIW, Chrome now has a new "Only once" option
Pete: the issue is the fire and forget permission grant for the Geolocation API
<tomayac> We now have [On every visit] [Block] [Only this time]
Reilly: wanted to ask Pete, what language you'd like to see added to the Geolocation API assuming Permissions API includes language for session or time limiting grants
Pete: I'm intentionally not suggesting UI related prose
… such as the like characters appear in the UI
… I would expect Geolocation to say this permission must include option scopes A, B and C
Proposal for normative changes
anssik: Pete's strawman proposal:
9. The Geolocation API MUST allow users to specify whether the
requesting site has access to geolocation data for
(i) the length of the frame,
(ii) for the length of the session, or
(iii) any number of longer periods of time, which can be decided by implementors.
larsgk: question, often you don't care about geo tracking when at home?
<pete_snyder> (i dont think it is correct that many people don't care about geolocation tracking in their home, though i appreciate its a different category of concern)
Reilly: I'd love to see more informative text in the spec to describe guidance to implementers how to implement such UX/UI
Pete: I agree this discussion comes up often in privacy review
… as normatively as we can often can we can should define UI and UX behavior
<pete_snyder> https://
Pete: specs often do specify UI or UX behaviour
Reilly: I think I agree with Pete's comment on specs implicitly defining UX
… over time a number of specs have defined things in ways that even though not mandating UI it can be inferred
… newer specs have tried to spec permission hooks in such a way that there's room to ask the user without blocking
… Geolocation spec is an example that predates this more recent permission work
<larsgk> (clarification on my comment: perhaps if transitioning to roaming, revoke geo permission/ask user - not "don't care when home")
Reilly: maybe we'll add a new API that'd allow the sites to ask for much more restricted permissions
… can we change the compatibility requirements, or is the current shape of the API fine and all we're talking here is recommendation on the mitigations
… there are examples such as Gamepad API, a sync API does not allow browsers to offer a prompt, the platform needs to respond immediately
… that we got wrong in the past in some specs, not the case with Geolocation API that is async and offers means to hook in permission UI
Pete: I see there's a feature that's specified very tightly(?)
Reilly: is there a change to the API itself or implementation that'd mitigate your concern?
Pete: I don't have a strong opinion about that
Reilly: the developers aren't going to call a method that will give the geolocation but only for 5 minutes, otherwise it'll break their app
… it is in the developers' interest to get the permission as long as possible
… developers have to handle the case when the permission goes away
Reilly: there's room for the spec to offer implementer guidelines to help surface these privacy concerns more clearly
<pete_snyder> for example, WebXR says "The user agent MUST use trusted UI to show permissions prompts." (https://
<pete_snyder> ie +1 to Reilly
Privacy and security considerations
Reilly: question to Pete, I'd like to see developer interest in a version of the API that offers less information
<scheib> https://
Vincent: I think the desired outcome is the browsers facilitate more privacy-aware enviroment
… some of that happens in spec, some outside the spec work
… e.g. high accuracy is one considerations of the spec
… temporal capability of the API, another dimension controlling how much information is exposed
… how precision is currently handles is complicated, nothing stops an implementation to provide a mm accuracy
… for some APIs we quantize the precision of orientation sensors, a valid mitigation
… should think of the temporal nature, also think of non-temporal
anssik: noting a bunch of these issues have been discussed in the next-gen Geolocation Sensor spec https://
<pete_snyder> Update spec to include ability to restrict lifetime and scope of geolocation capabilities, and include S&P guidance on UI and UX
Reilly: agree on "include S&P guidance on UI and UX" portion
… would like to see the references Pete provided earlier on developers looking for ways to ask for restricted lifetime and scope
proposed RESOLUTION: Update spec to include ability to restrict lifetime and scope of geolocation capabilities per gathered developer feedback, and include S&P guidance on UI and UX
Pete: ability to allow well-behaving sites to ask for less, then limit ability of malicious sites to ask too much
Pete: some issues have been closed without my consent
anssik: comment on issues you feel have been closed prematurely
<pete_snyder> the request is for normative changes though
Reilly: it seems we're going back and forth on the normative aspects for UX, that is up to the implements to decide how they present those things to users
… changing spec does not change that
Pete: the ask is to allow browser vendors to do that
… there must be a way for users to grant permission for a day, a week, a month
Resolution: Expand Privacy and Security considerations with discussion of privacy harms from long-lived permissions and Gather developer feedback on restricted lifetime and scope of geolocation capabilities.
Network Information API
Reilly: nothing new to report, focus now on Compute Pressure API that is somewhat related
HTML Media Capture
FYI, this is being integrated into HTML Living Standard per W3C/WHATWG Update