Meeting minutes
Welcome
<gb> Issue 76 Devices and Sensors WG - TPAC 2025 agenda (by anssiko)
Anssi: Welcome to the Devices and Sensors WG and WebApps WG joint F2F!
Intros
Anssi: familiar faces, also new folks
… joining as new Will from iProov and Ananya from Samsung
… Antonio from Chrome working on permissions
Geolocation permission element
Maryan: we try to me UX better showing the prompt in context
… site is able to control timing, but we don't want to overload the user with prompts
… we're looking for a better signal to show prompts
… we can get into and revisit
… we believe the path forward is to get the signal upfront
… people click on things all the time not connected with activity
… user in the driver's seat
… we propose geolocation element aka PEPC
… discussed in Seville initially
… geolocation element is a button on the page, when clicked it is equivalent of getGeolocation call
… we prescribe the text and icon, allow some styling and want the signal to be of high quality
… in essence the element is a functional part of the site
… developer get the element from the page
… I share a code demo, how this could look like
… inside the function we can access the position property, if unvailable, we handle that separately
… for many use cases no need to call the JS separately
… this way the user does not see the prompt, clicking on the element allows users to grant permission even if they ignored an earlier request
… real-life example of the UX in Chrome
… this UX is in Chrome OT
Dan: because you know the user understands what s/he is clicking, showing a prompt makes this less confusion?
Marian: right, we can do that in the moment
Dan: this raises your confidence there's no mistake this this UX
Marian: developers are excited about this, they don't need to design UI with arrows pointing to top left, for example
Mike: the reason we use this presentation is we have a strong signal, APIs currently can be cannot for any reason and don't have this signal
Reilly: this flow forces user to make a decision
Marcos: I Safari we did that
Mike: Chrome's position is it is sometimes better to make prompts quieter and sometimes louder, have a signal that informs us
… you can change Safari's signal I assume
Marcos: not necessarily
Marian: I mentioned there are some security or integrity guarantees we provide, the user saw a button "use location" in some form
… we lock down the content
… if the language is available we use that, otherwise browser locale
… element is fully controlled by browser
… in these cases we check the button is fully visible with adequate contract wrt background
Anssi: do you handle non-trivial cases like transparency?
Mike: we map the rules we have
<tomayac> Intersection Observer v2: https://
Marcos: these are parts of intersection observer v2 that are unimplementable on the WebKit side or add more complexity we are willing to add
… shadows and hit testing, for example
… we want a simple model, on the iOS side there's occlusion and transparency and that has served the iOS platform well
… we should start with a small set
Mike: I'm interested in finding a compromise here
… it seems easier to remove restrictions than add them, and the set of things we're working on is the max set of restrictions, and as we learn what developers want and intersect with heuristics
… the path we plan to take is we start with vital restrictions
… we are open to feedback and want to take any learnings into consideration we have now
Marcos: base styling and static elements put too many restrictions, given Geolocation API is the fallback
… not much to add in terms of restrictions
Mike: we present the prompt in terms of the signal we get
Marcos: significant issue of the design is to have an element on the page
Marcos: example is Uber, with an order button in icon mode, when watching location and the element goes away, questions like that
antosart: I want to ask whether we do need to have the same restriction that behaves differenty
… you can always fall back to the old prompt
Mike: it is possible to use the same prompt
… the primary goal is to distinguish the cases, and make it easy for the user to grant permission to the site
… we don't have that signal
Mike: current implementation does not allow the use of element when styling it
… amazing presentation
Mike: presence of the element on the page, there are two ways developers use this element
… 1) gather the information in the moment and execute the task
… 2) to gather the permission on an ongoing basis
… there are a number of ways we can explore to use the API
… personal opinion is, good to encourage developers to make it visible on the page the location is being used
kagami: intersection observer v2 usage, we have a popover there, can we do a similar thing for the element too?
Mike: yes, we rely on intersection observer as a runtime evaluation so the user can actually see it
… we force the element to be on the top
Mike: better to force the element be on top
kagami: not sure how the intersection observer can show up in the spec...?
Mike: only thing that occurs to me is we have a case where developers render a button and search has a popup, and regulators want to have a popup
… current implementation allows us to put something on top of the element
Anssi: <input type=file> learnings?
Mike: great example to dig into more
… wrt the thing that happens when you click on that element, I suggest the prompt mechanism we have in place, prompt mechanism is a sufficient bar to abuse, the file picker dialog
… there are a lot of capabilities on the web that have a lower bar to entry and in those cases having high quality signal is useful allow us to represent
… the original proposal we talk about permission element is one-size-fits-all approach
… generally any information we ask for, fits that model
… more tailored to a specific thing we ask for
… we have a different set of heuristics for geolocation, notifications, or getDisplayMedia
… we have more confidence for a picker style UI
Marian: <input type=file> was restricted and geolocation element is more relaxed in terms of presentation
Marcos: given it is the form, clicking on label triggers the form
Mike: we don't allow label clicking to trigger geolocation element
tomayac: for Marcos' point element consuming space, I think would be possible to remove the element if the prompt action happened, so that it is only shown when needed?
<mkwst> (But note that the label is _always_ directly included in the button.)
Marcos: it is still an element in the DOM then
tomayac: can remove it from the DOM?
Marcos: not attached to the DOM then
… maybe the element should not be able to watchPosition
Reilly: you should give the user more explicit signal
tomayac: stop watching if the element is removed from the DOM?
Mike: excited about exploration
Reilly: 5 min time check
Marcos: the original PEPC had a notion of recoverability, not possible to do that on Apple's platform. when installed it becomes part of the OS
… no way to recover, must go to open settings
Mike: different platforms differ here
Marcos: API to go to settings page?
Mike: using such an API would be more palatable fi we know for sure what the user wants
Reilly: we need more steps on the OS level to guide, take responsibility, I understand iOS is more integrated
Marcos: can't be an expectation for the PEPC proposal, platform limitations need to be considerations
Mike: I understand these limitations
Marian: OT participants are excited about the recovery bit, camera and mic, also for geolocation
Mike: even when we cannot recover, the browser knows it has geolocation
Marcos: ask is to consider installed app to be tightly integrated into the OS
Mike: iOS is special, we are dependant on y'all to help here
Reilly: Chrome for Android we do something similar, we will consider this feedback in the design
… we are at the end of the timebox
Mike: we want more people to use this
Mike: kagami's intersection observer feedback is very helpful
Mike: if there are fundamental objections we need to proceed more carefully
<mkwst> (If no fundamental objections, we want to ship.)
willmorgan: PWA use case, at the point of install, would be the right moment to ask for this permission and otherwise block
Marcos: design is for time of use
… having said that, Uber app for example asks for location right when I start the app
Marian: runtime permissions where the Android model and it created some pretty serious privacy issues
Marian: asking permissions as a requiment for installation did not work out well
Approximate Geolocation
Repository: w3c/geolocation
Anssi: previous topic was issue #196
<gb> #196
<mattreynolds> Approx Geolocation slides: https://
Anssi: and this issue, approximate geolocation, is issue #195
<gb> Pull Request 195 Add support for approximate geolocation (by alvinjiooo) [TPAC2025]
Matt: working with Antonio and Alvin on approximate geolocation
… we want to mitigate risk of exposing precise geolocation, want to make this safer, and comply with legal requirements
… e.g. in California we have specific requirements, different in rural locations
… we want to see if we can rely on platform location, most platforms where Chrome runs we pass flags to do this
… e.g. iOS and Android have an approximate concept
… Windows has an option to fallback with accuracy levels
… does not work with WiFI AP, might be functional now?
… on iOS there's a switch to enable and disable precise geolocation per app
<tomayac> Just for fun: early 2008 mock of approximate geolocation access: https://
Matt: we want to expose new permission level and allow users to downgrade
… sites can function and request approximate geolocation, user agent can return and obfuscate the precise
… geolocation approximate concept was introduced, not all combinations possible
… if you grant precise you also grant coarse geolocation
… new PositionOptions changes
… accuracyMode
… we have enableHighAccuracy, why not reuse it?
… does not provide guarantees, many platforms will still try to use precise location
… many sites pass false here, so we don't want to regress the apps
… defaults to false
Matt: what should the old do when the new feature is there?
Reilly: modern devices use more complex behavour, does not map to enableHighAccuracy
Marcos: on legacy system it does not matter?
Reilly: you propose to use the existing value but change to string?
Marcos: correct, stringifies to "true", "false" and "precise"
[ add Marcos' WebIDL gymnastics joke ]
Matt: proposing GeolocationPosition changes
<tomayac> https://
Matt: accuracyMode attribute
… may not be the same as if user's downgrade
Reilly: 2.6% of pages using geolocation set enableHighAccuracy per Chrome metrics
Matt: Permissions API integration changes
antosart: getCurrentPosition prompts, then Permissions API query() returns "granted"
antosart: if only approximate geolocation is granted, this returns "ask" or "deny"
… open to revisit this
Marcos: an idea, related to the problem around precision, what if we fix that and get half off way from the circle, that tells you how close you are
Reilly: key thing, browser tells I only give you approximate geolocation
Marcos: as a user I might not tell the truth
Reilly: user wants to lie to the site I'm precisely here even if I'm not
Marcos: my phone may not get a GPS lock, I might be revealing too much
Reilly: faking the location would not be a reliable privacy shield
Marcos: I want to further investigate accuracyMode in permission status
Matt: we get accuracy value in the object, can look at that, could look at that also
Matt: what requirements we should have for the algorithm to generate estimated location
… Mozilla has one algorithm implemented as an extension
… Apple has its own algorithm
… we don't know if these algorithms meet specific requirements, can't ask for implementers to do that
… we can guarantee "coarsened position estimate"
… multiple estimates collected over time can generate a more precise estimate
… guarantees for developers, can satisfy some legal requirements
Marcos: the platform dependency is visible here
Matt: want to bring this feature to platforms that do not have support for approximate geolocation
… precise location reconstruction, reduce time resolution
Marcos: standard per platform?
Matt: not fully researched yet
[ Matt shows a demo! ]
Marcos: WebKit is broadly excited about this feature
tomayac: Android allow precise and non-precise location, this UI demoed will not show you that option?
antosart: in page setting you see a message only approximate geolocation is allowed, a trade-off
kagami: a question about watchPosition and approximate geolocation
… what is the expected UX there, what happens in native apps then?
Matt: watchPosition and approximate, not well defined yet
… we are going to say you only get an estimate every one minute or so
<MarianH> side note: <geolocation> element slides: https://
Marcos: we should investigate what the platforms are doing
Reilly: watchPosition has to make sense in context of loop-calling getPosition
… the discussion we've had here, the desire is if the user does not move outside the course region, the value should not change
… we can still provide the value repeatedly
… interesting question is how far the user has to go to trigger a new location update
… e.g. on a train, you get period updates that maintain privacy principles while give you an approximate location
Marcos: during the breakout, we talked about how on Apple platform geolocation attaches to a point of interest, underlying platform knows how to do that
… good exercise, some platforms use the browser implementation, not platform-provided coarse-location
Matt: we want to allow implementations to innovate here
Reilly: any upcoming shipping plans or last-minute feedback from implementers?
antosart: we have implemented the permission prompt flow, we are trying to ship an experiment to small amount of users for changing to approximate location to see how the understand
now in Beta, going to Stable for a small test group
Reilly: part of this is motivated on every platform has this feature of coarse geolocation, and the site only functions with approximate, this leads to site not working and can't tell the user what needs to be done because it doesn't know enough
Confusion about geolocation emulation in two specs
Anssi: issue #212
<gb> #212
Reilly: this was per the preference of WebDriver authors, prefer to close this issue
Marcos: I was confused because this issue did not link back to WebDriver
RESOLUTION: Keep the split and add a non-normative reference from Geolocation to WebDriver for the automation section, for issue #212
Better integration with testing framework
Anssi: issue #193
<gb> Issue 193 Better integration with testing framework (by marcoscaceres) [TPAC2025]
Marcos: testing framework has a virtual location, but in theory in browser you set a location and browser gives back what you have
Reilly: this is push model, not pull
… I think we resolve this making those changes
RESOLUTION: Make the changes suggested by Marcos in issue #193
Improve position accuracy definition
Anssi: issue #206
<gb> Issue 206 Improve position accuracy definition (by marcoscaceres) [TPAC2025]
Marcos: I did archeology, confidence level is 95% baked into the spec, wishful thinking at the time this was specified
… was 67% on Android, and on iOS 65-75% or so
… we return null on Apple platforms
Reilly: the additional context is, it is better to define accuracy, does the spec say accuracy must be something
… 3 values you get: position, fixed position, circle around the position, and what the system believes is the user is in that circle, or 3d oval in fact
… centre of the oval and the probability the user is inside it
… I did research
… for GPS receivers, with user in that 3d space, 65%
Reilly: I assume the GPS receivers on Apple devices do the same, complexity here is we get position from various places, not sure if all those services standardize on a particular value
… at the risk of making the API more complicated, we could make the API more complicated adding the confidence to the API
Marcos: I like the idea of revealing it is 65% or so, it complicates things yes
Reilly: you need mapping libraries on top
[ Reilly pointing at the UX person in the room ]
Marcos: not to reveal a lot, it is OS-level information, nice to reveal on the location object
Reilly: nice standards position from WebKit
<gb> Issue 206 Improve position accuracy definition (by marcoscaceres) [TPAC2025]
RESOLUTION: Draft a PR to remove any specific confidence value and attribute, and clarify the meaning of the accuracy value (issue #206)
kagami: I'm fine with this resolution
The timeout option doesn't make sense for watchPosition
Anssi: issue #184
<gb> Issue 184 The `timeout` option doesn't make sense for watchPosition (by saschanaz) [TPAC2025]
kagami: watchPosition, if the user does not receive error, this should not say anything, now it somehow times out with an error, does not make sense for watchPosition
Reilly: developer cares about I'm I going to get location at all, I want to update the UI, if I get no value my UI will do something different and I want to know
… timeout is not meaningful in this context
… I think the proposal is to clarify the timeout only applies to the first fix deadline
Marcos: we should say what timeout 0 means here
Reilly: now the default value is Infinite that's kind of 0, but we should encourage Infinity proper
… why we have differentiation between 0 and Infinite is that 0 means check cached position
… I think the cache position concept is legacy of how location systems used to work, in modern devices the OS has a cached position, a decreasingly sized circle-ish location
… the idea of cached location is a little weight, the maxAge idea is also a little weight, we don't know how old that is
… in Chromium we have a cache, there are bugs so we have considered removing that code path
… another parameter I'd like to get rid off
… it does not reflect the 2025 reality of geolocation capabilities in devices
… return the cache or throw a timeout immediately
Marcos: we are not partitioning the cache, right
<gb> Issue 184 The `timeout` option doesn't make sense for watchPosition (by saschanaz) [TPAC2025]
Marcos: I added a comment in the issue, it is rather long
Reilly: I think I agree with the comment
RESOLUTION: Change the watchPosition steps so that timeout is a deadline to an initial fix and that there's no deadline for returning an additional geolocation results after the initial fix (issue #184)
Remove the default value of timeout in PositionOptions
Anssi: issue #185
<gb> Issue 185 Remove the default value of `timeout` in `PositionOptions` (by saschanaz) [TPAC2025]
Reilly: the question is, if we remove the default value, the timeout becomes nullable, then is using a null timeout instead of this large value be the same behaviour
… alternatively, we could remove the clamp and use Infinity
kagami: the implementation could check for either
Reilly: implementations may end up checking some very large threshold
… not a developer visible change, timeout behaviour will be the same regardless
… unsigned long can take Infinity, do we want to make this nullable unsigned long, this is a dictionary, in terms of C++ has a null check
Marcos: effectively what kagami proposed
Reilly: clamp in unsigned long is undefined and not set to specific value
RESOLUTION: Remove the default value because we believe it does not have any developer visible impact (issue #185)
Specify frame destruction behavior
Anssi: issue #192
<gb> #192
Reilly: Marcos asks if we don't spec this behaviour, and the frame is destroyed, we should have the steps
… however the question is it becomes non-active while the operation is in progress
… we don't have cleanup on not active, browser implementations do that
Marcos: I wasn't sure if there's a check for destruction for the script execution context
Reilly: I don't think the spec has one
… we can add on document not becoming fully active and that's good
RESOLUTION: Add steps to on document becoming non-fully active clean up all watch operations (issue #192)
AbortSignal integration
Anssi: issue #179
<gb> Issue 179 `AbortSignal` integration (by jimmywarting) [Feature request] [TPAC2025]
Reilly: about modernization, use promises for abort signals
… can I add an abort signal to the API to allow clearWatch with an abort signal
… clear watch when the signal happens vs immediately
… watchPosition is another place where we can put this
… my perspective is, we can add it, this is one of the things where developers will need to polyfill their way around this until implementations pick this up
… it is nice but feels low value
Marcos: to mitigate the problem, to implement this in the spec we implement at the same time
Reilly: not opposed, but I don't think this is useful
Marcos: I don't hate it, "cool feature bro"
Reilly: easy to polyfill on top of the current API
… take the abort signal and add clearWatch
<gb> Issue 192 Specify frame destruction behavior (by marcoscaceres) [TPAC2025]
RESOLUTION: Consider this feature in a future version of the specification (issue #192)
Promisify getCurrentPosition()
Anssi: issue #174
<gb> Issue 174 Promisify `getCurrentPosition()` (by lukewarlow) [Feature request] [TPAC2025]
Reilly: nice API but I don't think it is worth it to add this complexity because developers will need to polyfill for a number of years
<gb> Issue 196 <geolocation> element (by MinhAnhL) [Feature request] [TPAC2025]
RESOLUTION: Due to added complexity, close the issue after confirming with the original author of the proposal, new proposal for better ergonomics, see geolocation element #196 (issue #174)
<tomayac> Node.js solved the transition from callbacks to promises by introducing new names (`fs` → `fsPromises`), so we _could_ do the same here, but it wasn't deemed worth it, especially since `<geolocation>` is the promising (no pun intended) new way.
<tomayac> People have been commenting on w3c/
<gb> Issue 22 Support geolocation (especially geofencing) in the "background" (by kenchris) [geo-background-fencing] [geo-background-tracking] [use-cases]
Screen Wake Lock API
Remove permission check
Repository: w3c/screen-wake-lock
Anssi: issue #366
<gb> Pull Request 366 Remove permission check (by marcoscaceres) [TPAC2025]
Marcos: we designed this around powerful features, we don't need screen wake lock
… in WebKit we implemented it as a bunch of dead code to pass the tests
… by default in Chrome we have a checkbox but it is on by default
… you don't prompt for it
… we can probably remove the permission check
Mike: we have the setting for this, however?
Vincent: this is in Safari, what is the motivation for removing this?
Marcos: we have fake implementation for this
Vincent: that is a very minor issue, we have an implementation for this that's real
… why should we drop it?
Marcos: no one uses a permission prompt
Marian: you can go to settings and turn it off
Reilly: I asked Mike about this before the meeting, he mentioned there's a bunch of powerful features without corresponding permission UI
… we use the machinery without prompting users, example we use this as a way to control the feature
Mike: we allow require delegation, and delegate it
… in this case we don't prompt unless delegated
… I don't know if this is the case here
Marcos: could keep that aspect
Mike: we keep the check
Marcos: add stuff that never got implemented, indicators and such
Reilly: only thing we could remove, if we remove prompt-related text, couple of steps request permission to use
… request permission to use
Marcos: permission policy makes sense, we massage the other things
Reilly: question, if a browser has a setting to disable the API, would that fall in which category, policy-controller or not?
Marcos: policy-controlled
Mike: I don't think this distinction makes a lot of sense, the feature can always be available and be in a weird state
… I don't remember the permission feature on top of my head
<scheib> https://
Reilly: if there's a way to specify a powerful feature check and the permissions feature check in a single check, it'd resolve Marcos' concern
<scheib> https://
Reilly: with the spec algorithms available to us those need to be two separate steps I believe
… we want a simpler way of checking
antosart: in Chrome this may not be the case, we have setting in Chrome not related to permissions
Reilly: then the behaviour is implementation-defined
Marcos: I want to remove the line "request for permission to use screen wake lock"
Mike: what is the web-facing implementation you need to fake in the tests
… please note prompt the user is not web visible
<reillyg> https://
<tomayac> `await navigator.permissions.query({name: 'screen-wake-lock'})` returns always 'granted'
Reilly: if we change the algorithm here, it removes the request permission
Marijn: no way to request permission in this case
Marcos: we don't have code to fake ask
Reilly: precludes us from ever prompting
Mike: confused on what you're faking here for tests
<gb> Pull Request 366 Remove permission check (by marcoscaceres) [TPAC2025]
RESOLUTION: Replace "request permission to use" with "get the current permission state" (issue #366)
Require transient activation
Anssi: issue #351
<gb> Pull Request 351 Require transient activation (by marcoscaceres) [TPAC2025]
Marijn: you can require transient activation without consuming it
Vincent: can you require activation types and not consume and check more than once
Marcos: check for sticky activation is a reasonable ask
Marijn: sticky is whether the page has ever had transient activation
tomayac: invisible video is the workaround to this issue, with media autoplay
Reilly: media autoplay requires some signal I believe
… a legitimate concern that if we require activation developers will play a silent video
… Screen Wake Lock API was created to not need to use autoplay video for this purpose
… that concern is not something we worry about, we don't take away a thing people would use
Mike: Screen Wake Lock API has been out these for a long time
Marcos: not so long time for WebKit
Reilly: do we need to increase user activation requirements, or is sticky activation good enough?
… I proposed sticky because we proactively take away the wake lock so reacquiring is a consideration
… using sticky the site is allowed to reacquire
… some other complicated edge cases
<gb> Pull Request 351 Require transient activation (by marcoscaceres) [TPAC2025]
kagami: why require transient first?
Reilly: if you run an operation, you want it to complete, say file upload, if I switch tabs, we implemented this so the page is invisible so hand hold the lock
kagami: can we pretend it has a lock?
Reilly: can automatically acquire the lock
kagami: what needs to be reacquired?
Marcos: that's not how it works today unfortunately
Reilly: forces developers to explicitly decide
RESOLUTION: Require transient activation for the first, and allow subsequent requests (issue #351)
<tomayac> /
<anssik> s/\/join wicg//
<anssik> s//join wicg//
<anssik> s|join wicg||
Charter & roadmap
Anssi: we will review our roadmap and discuss rechartering
https://
https://
Anssi: Atsushi has kindly opened PR for the charter updates and a strategy issue where the W3C team will assess the issue
<gb> https://github.com/w3c/charter-drafts/pull/720
<gb> Issue 530 [wg/das] Devices and Sensors Working Group 2026 Charter (by himorin) [charter]
Anssi: We need to start soon on rechartering or extending.
… Anssi would like to contribute demos on behalf of Intel.
… Specifically talking about the Motion Sensors repo
… intel/
RESOLUTION: DAS WG will host demos that support explainers and spec work in the WG's repos
Atsushi: The charter needs updating starting from 2024
… following the new charter template
… spec status needs to be updated.
… The WG may want to discuss about the scope or modify some text to align the current interests
… There is a recommendation to update the roadmap section in the charter and ask for horizontal review
Anssi: No substantial changes, but the boilerplate text. The end date is end of February.
… we can extend by default about 2 months.
… Legal people in each company want to review this.
<atsushi> 2026 rechartering strategy issue
<gb> Issue 530 [wg/das] Devices and Sensors Working Group 2026 Charter (by himorin) [charter]
Anssi: There is a heavier process for substantial changes.
Atsushi: The template includes text about the scope.
Anssi: It would be helpful to have checkbox items we need to work down
… We are use case driven and security and privacy focused. We work on real world use cases with developer demand.
… Background geolocation has tons of use cases, but some challenges with security
… Hardware security is exclusively out of scope
… Coming to the deliverables. This is stuff the group _can_ work on.
… Many haven't changed much and we haven't pushed for new features
… Battery status is one of them
… Screen wake lock was discussed in the morning
… System wake lock is on the agenda
… We can keep it in scope and if Reilly wants to work on this, we can
… Generic Sensor API is the abstract class for many concrete sensors.
… We're hearing that Will has product requirement for ALS for example
… The geolocation sensor has developer and use case demand, but we don't know what the solution is.
<Zakim> DKA, you wanted to ask about scope
Dan: Wanted to ask about scope?
… How does DAS think about scope? Can we only work on things on the deliverables list? Or is there some flexibility? What model do you work under?
Anssi: We say something about this. The WG will not adopt new proposals until they have gone through the WICG or similar. There needs to be initial consent.
… Otherwise the charter would be open-ended
Dan: This is interesting. Just noting that in Web App Sec, they have taken the view
… that they adopt things on a case-by-case basis
… as long as it fits their scope
Anssi: Does Dan recommend us we do it this way?
Dan: Not recommending. Just asking.
… would that approach be useful for you? Have you run into roadblocks?
… Like when you want to work on something, but that something isn't on the charter.
Reilly: My perspective is that the process for incubation is mature enough that I haven't felt an urgency to accept something into the WG than usual.
Anssi: Maybe some might push back on adopting something too early
… If there's a best practice emerging, we want to adopt it
… We want to minimize friction
… If it upsets someone, it's not worth it
… ALS is where Will had use cases
… DeviceOrientation is the old spec
… Geolocation Sensor is an idea where we don't know if it's feasible
… Contact Picker is a bit different. Compute Pressure.
… Then we have tentative deliverables: Network Information API is too soon to make it a WG deliverable. Same with Idle Detection.
… Then we have maintenance issues: Geolocation, Vibration, Media Capture.
Reilly: Only a few of the deliverables get active participation from the implementers
… Particularly geolocation. Privacy has been very actively looking at this.
Anssi: We have this text: If additional in-scope Recommendation-track deliverables need to be added…
Dan: You have this in the charter, but you have never used it?
Anssi: We haven't.
… One thing I want to mention: Reilly, implementation-wise: Generic Sensor has been implemented by reusing existing code?
Reilly: The answer is true that the API is polyfilled on top of the old APIs.
… It's implemented as a JS polyfill, but you can think of it like this. It's actually C++.
… It's not exactly on top, these APIs use different units.
Anssi: Geolocation Sensor needs the use cases to be discussed
… Device Posture will be discussed after Sam's presentation
… Contact Picker is implemented by Google and WebKit behind a flag
Anssi: CPU Performance API points back at Compute Pressure. Reilly, are you working with the person?
Reilly: No
Anssi: Do you want to update the PR Atsushi?
Anssi: The PR is already merged.
Dan: Your current charter talks about proposed recommendations, but there are none.
Anssi: The charter is connected to device capabilities or sensors
Anssi: Is anyone aware of other work?
Mek: We could mention stuff as tentative
Anssi: Not a lawyer, but...
Anssi: Is Huawei interested?
Wei: We need to clarify internally
… That's a maybe, speaking as a guest and might want to propose new deliverables.
<Zakim> Will_Morgan, you wanted to discuss suggested proposals in advance of rechartering
Reilly: Time check? Anything else we need to discuss?
Will: iProov is in a similar position as Huawei, we may want to propose new stuff
<Will_Morgan> iProov
Anssi: Do you need to be member to suggest new stuff?
Dan: No
Dan: Anybody can help write the charter. But you need to join the WG to contribute.
Atsushi: For some WG, there are some tentative specs in a CG
… If you have a specific item, you can push it in the CG
Anssi: Let's conclude this and send a note to the list
Freeform Window Hints
Sam: Convertibles are devices that can behave both like a tablet and desktop device. Lots of chromebooks do this, surface tablets, detachables
… : other devices that do similar things, even though not convertibles. I.e. plug phone into external monitor that various phones support
… a lot of other stuff on the web that let devices adopt to them, media queries, input devices. Can adopt to lot of things. One thing we don't have signal for is how user is using device, user posture rather than device posture.
… a focused app mode vs a desktop windowing mode, users use devices differently in the different modes
… in focussed app mode more in consuming mode while in windowed mode more in a heavy productivity mode
… other thing we noticed between these modes is windows opening popups behave differently in these modes, but behave consistently in the same mode across devices and operating systems
… in focussed mode window popup opens a tab, while in multi window mode opens a new window. devs need to be aware of this to adapt flows
… payment flow in a popup stays in context, while in a new tab would lose context and people might forgot why they are there
… knowing if your popup is going to open a popup vs a tab might make you want to perhaps use an iframe instead of a popup
… So what do we do about that? Impossible to feature detect today, since window.open does work but you don't know if it created a tab or a popup. So need to detect that before opening the popup.
… Rough proposal of two pieces: one is hanging something of ScreenDetails that says supports free form windows or similar, also in a media query
tomayac: there is a property in css for cursor, hover, fine, etc is that usable?
Sam: Unfortunately not. Windowing mode has nothing to do with coarseness of input device. Also is screen specific rather than device specific, so can change
… can switch between desktop and windowed mode with same coarseness, but still change modes
… can drag a window from phone over to desktop/to phone, and everything will change. So not tied to input modality or device
… so need a runtime thing with event listeners for changes etc, so not a client hint or device type
anssik: is this more like extension to window management spec?
Sam: yeah, talked to mike wasserman yesterday about this. Think hanging something of ScreenDetails seems right. Only downside is permissions needed for screen details, for opening a popup shouldn't need to show scary permission prompt
… looking at a readonly permissionless screen details api that might work. Would have some fingerprinting entropy, but shouldn't be a lot more than you can get today
anssik: good news, we're also rechartering the Second Screen WG soon and this feature could be in scope
reillyg: a reason this needs to be on ScreenDetails and not on Screen?
Sam: No, original thought was for Screen. But want to expose this for all attached screens, so also need it on ScreenDetails
reillyg: Screen only gets you info for current window, but that is probably what apps mostly cares about, so could add it to Screen without limiting use cases
Sam: Main reason for Screen Details was because we were talking to the authors of that. But screen could also work
… noticed this on Chrome on macOS, varies between browsers. If you use macOS's fullscreen to fullscreen the app it behaves the same as focused app mode and opens a tab. Web fullscreen API behavior is differently. Knowing what is going to happen can extend to multi-desk/space scenarios on desktops as well
reillyg: Yeah, macOS effectively has this focused mode, would be good for sites to be able to detect that there as well to avoid kicking you out of fullscreen
tomayac: question for implementer interest. Samsung/meta both have VR, is this particularly important in the VR context?
Baran: There are overlaps between spacial browsers and this kind of focused view. With one click can enter focused view in VR, also in other modes where we don't want to break you out of a tab.
Ananya: Very relevant problem for us as well
… there is no way to detect if your galaxy phone is docked/using Dex and if multiwindows are suddenly supported
mek: Do you think this would also apply for PWA windows?
Sam: Isn't this what navigation capturing is for?
… I think this could be used as part of deciding whether or not to open a new PWA window.
… I can see a scenario where a PWA in focused-app mode might prefer to open links in a CCT in focused app mode and be okay opening them in new tabs in a windowing mode.
<scheib> (CCT: Chrome Custom Tabs == Android Custom Tabs)
Reilly: to wrap discussion, initially forgot Device Posture API is foldable related, I think given the discussion on use cases this seems to fit in Second Screen WG as an extension to Window Management API
RESOLUTION: The DAS WG proposes the Second Screen WG to adopt the Freeform Window Hints proposal into its charter, given it is an extension to the Window Management API
Screen Brightness API & Biometric Liveness Detection
Screen Brightness API & Biometric Liveness Detection
[Slide 1]
Will_Morgan: We are a liveness provider that has been recently been certified by FIDO.
… This is a complementary technology to Passkeys and Digital Credentials.
… The goal is to determine that the user is a real person and not a deepfake.
… We've been working on this for the last 6 years.
[Slide 2]
[Plays a demo of identity verification by taking a video of the user's face.]
Will_Morgan: Modern deepfakes threaten to invalidate this process.
[Slide 3]
[Shows a demo of a deepfake being used to fake identify validation.]
Will_Morgan: This is an ongoing challenge that the industry has been having.
… This isn't for general authentication but for high-value ceremonies such as filing tax returns.
[Slide 4]
[Slide 5]
Will_Morgan: There are other companies in this space.
[Slide 6]
Will_Morgan: Since we've gotten involved in the W3C the industry has continued to grow. ~2 billion transactions per year.
… My job has been to get to native success rates in a web browser.
… Trust model and a large diversity of devices are difficulties.
[Slide 7]
[Slide 8]
Will_Morgan: Fingerprinting protections are a challenge for us because we want to fingerprint but not for the purposes perhaps that others like advertisers do.
… Our use case is ephemeral.
[Slide 9]
Will_Morgan: I'd like to see if there's any interest in the room for any of these areas.
[Slide 10]
Will_Morgan: What I'm trying to focus on are usability and increasing completion rates.
… Our challenges are user abandonment and false rejects due to poor lighting.
[Slide 9]
[Slide 18]
Will_Morgan: Ambient light sensor is going to make the most difference for us.
… We don't need much granularity.
https://
Will_Morgan: There have been interesting papers on attacks against the high-resolution API.
… and again we don't need all that.
[Slide 19]
Will_Morgan: Our proposal is to bucket into dark, fair, good and bright buckets.
anssik: Are these specific lux values examples?
Will_Morgan: Yes, I don't have specific data on which values lead to be the best photo performance.
anssik: Are you interested in particular steps like "dark" to "fair"?
Will_Morgan: What we decide to do as developers really depends on what we're allowed to collect and correlate.
anssik: Would a boolean work?
Will_Morgan: I'm hesitant to say yes because we'd like to know if it's too dark, too bright or in between in a range where we think things would work.
… I'd like to go to privacy experts to see what they think of this.
tomvg: I think here fingerprinting is not too much of a concern because brightness is temporal.
… IIRC those attacks were cross-site leakage.
Will_Morgan: We take the refresh rate down to twice a second to reduce the rate at which data can be leaked.
… Is a signal like it going from light to dark when you go outside leaking privacy?
tomvg: I don't see that being abused.
… I think cross-site exposure is the main concern.
Reilly: in cross-site leakage, you take cross-origin iframe and using JS you make the iframe change color from black to white, and readback the illuminance reflected from a surface such as the person's face
… if you can only read at a rate of 2 Hz it seems to mitigate this pretty well
Vincent: in the paper, I don't think this is a much of an attack
… holding an object near the device not very practical
Will: but on a phone it is different, there is so much environmental noise it might remove the noise
Anssi: we couldn't reproduce the attack in a lab setup when we initially tried using the setting described in the initial paper
Will_Morgan: Third mitigation is indicating that ALS is in use.
[Slide 20]
Will_Morgan: We're less interested in this because if we understand the lighting conditions then we probably don't need it.
[Slide 21]
[Slide 22]
Will_Morgan: We are considering proposing a "spectrum mode" media stream constraint.
… We have ideas for more building access type scenarios where the application could be a PWA and getting access to the front-facing infrared camera would be helpful for liveness detection.
… TAG feedback yesterday during the breakout mentioned that we should consider in permissions how infrared allows you to see through things that are not transparent in the visible spectrum.
… We might treat that as a separate permission.
[Slide 23]
Will_Morgan: Bringing back face detection would be helpful.
… Sites today ship ML models to do this but it's a waste of bandwidth because all operating systems have this built-in.
Reilly: the concern earlier was that OS built-in Face Detection implementations were different across platforms
Will: common denominator?
Reilly: what is the minimum capability that'd be useful for your app?
Will: bounding box, eyes and mouth points
Reilly: you will still run complicated algorithm on the server side
Will: you only send the minimum required to the server to improve privacy
… this also will mimize the time-to-interaction metric
Reilly: arbitrary UVC is harder, PTZ is in the spec already
Will: for focus would need manual controls
Reilly: you can manually focus with Image Capture spec
[Slide 25]
Will: suggested next steps
… in order of importance
… 1) Revive ALS
… 2) Drop Screen Brightness unless other UCs emerge
… 3) Introduce spectrumMode in getUserMedia
… 4) Revisit Face Detection API
Will: I feel ALS is the low-hanging fruit
Anssi: would be happy to let Will to edit the ALS API spec to update it to meet these requirements
Background Geolocation
Repository: w3c/geolocation-sensor
Use cases for background geolocation
Anssi: issue #22
<gb> Issue 22 Support geolocation (especially geofencing) in the "background" (by kenchris) [geo-background-fencing] [geo-background-tracking] [use-cases]
Anssi: this issue has been the go-to place for the community to share their use cases for this feature
… there's currently ~80 comments, up 28% YoY
… I asked Claude for a summary to see if it surfaces some new perspectives
<gb> Issue 22 Support geolocation (especially geofencing) in the "background" (by kenchris) [geo-background-fencing] [geo-background-tracking] [use-cases]
scheib: Implementers are currently saturated with other work.
… We shouldn't land a prototype unless there's a viable path to shipping.
… Is it a priority right now to do the work? No, Chrome doesn't have a partner for this.
https://
PROPOSED RESOLUTION: Move discussion of Background Geolocation use cases into the Geolocation API repo.
RESOLUTION: Move discussion of Background Geolocation use cases into the Geolocation API repo.
RESOLUTION: Discuss publishing a Discontinued Draft of the Geolocation Sensor API and removing it from group deliverables during rechartering.