23:58:22 RRSAgent has joined #dap 23:58:26 logging to https://www.w3.org/2025/11/12-dap-irc 23:58:26 RRSAgent, make logs Public 23:58:27 please title this meeting ("meeting: ..."), anssik 23:58:27 Meeting: Devices and Sensors WG + WebApps WG F2F – 13 November 2025 23:59:38 Chair: Anssi, Reilly, Marijn, Diego 23:59:44 Agenda: https://github.com/w3c/das-wg/issues/76 23:59:44 https://github.com/w3c/das-wg/issues/76 -> https://github.com/w3c/das-wg/issues/76 23:59:48 Scribe: Anssi 00:00:09 scribeNick: anssik 00:00:22 Present+ Anssi_Kostiainen 00:00:29 Present+ Matt_Reynolds 00:00:34 present+ Marijn_Kruisselbrink 00:00:34 Present+ Reilly_Grant 00:00:38 Present+ Marijn_Kruisselbrink 00:01:09 Present+ Diego_Gonzalez-Zuniga 00:01:21 Chair: Anssi, Reilly, Marijn, Diego, Marcos 00:01:30 Present+ Vincent_Scheib 00:01:37 Present+ Mike_West 00:02:23 Present+ Marian_Harbach 00:02:33 Present+ Marcos_Caceres 00:02:40 RRSAgent, draft minutes 00:02:41 I have made the request to generate https://www.w3.org/2025/11/12-dap-minutes.html anssik 00:02:54 Regrets+ Leonie_Watson 00:03:02 RRSAgent, draft minutes 00:03:03 I have made the request to generate https://www.w3.org/2025/11/12-dap-minutes.html anssik 00:03:58 atsushi has joined #dap 00:03:58 Present+ Will_Morgan 00:04:57 Present+ Atsushi_Shimono 00:05:02 xiaoqian has joined #dap 00:05:03 RRSAgent, draft minutes 00:05:04 I have made the request to generate https://www.w3.org/2025/11/12-dap-minutes.html anssik 00:05:10 Topic: Welcome 00:05:35 -> Agenda https://github.com/w3c/das-wg/issues/76 00:05:35 https://github.com/w3c/das-wg/issues/76 -> Issue 76 Devices and Sensors WG - TPAC 2025 agenda (by anssiko) 00:05:39 -> IRC https://irc.w3.org/?channels=#dap 00:05:44 Anssi: Welcome to the Devices and Sensors WG and WebApps WG joint F2F! 00:06:51 antosart has joined #dap 00:07:03 Present+ Ananya_Kittane_Yogananda 00:07:19 Present+ Antonio_Sartori 00:07:40 present+ 00:08:05 Subtopic: Intros 00:08:14 Anssi: familiar faces, also new folks 00:08:30 ... joining as new Will from iProov and Ananya from Samsung 00:09:07 tidoust has joined #dap 00:09:14 Present+ Antonio_Sartori 00:09:23 ... Antonio from Chrome working on permissions 00:09:46 liminzhu has joined #dap 00:10:53 Topic: Geolocation permission element 00:11:15 tomayac has joined #dap 00:11:19 Maryan: we try to me UX better showing the prompt in context 00:11:27 Present+ Thomas_Steiner 00:11:30 ... site is able to control timing, but we don't want to overload the user with prompts 00:11:37 ... we're looking for a better signal to show prompts 00:11:46 ... we can get into and revisit 00:12:00 ... we believe the path forward is to get the signal upfront 00:12:11 ... people click on things all the time not connected with activity 00:12:21 ... user in the driver's seat 00:12:39 ... we propose geolocation element aka PEPC 00:12:52 ... discussed in Seville initially 00:13:28 ... geolocation element is a button on the page, when clicked it is equivalent of getGeolocation call 00:13:45 ... we prescribe the text and icon, allow some styling and want the signal to be of high quality 00:13:54 ... in essence the element is a functional part of the site 00:13:55 q? 00:14:11 ... developer get the element from the page 00:14:20 ... I share a code demo, how this could look like 00:14:43 ... inside the function we can access the position property, if unvailable, we handle that separately 00:14:52 ... for many use cases no need to call the JS separately 00:15:28 ... 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 00:15:58 RRSAgent, draft minutes, s'il vous plaît 00:15:58 I'm logging. I don't understand 'draft minutes, s'il vous plaît', tomayac. Try /msg RRSAgent help 00:15:58 ... real-life example of the UX in Chrome 00:16:21 RRSAgent, draft minutes 00:16:22 I have made the request to generate https://www.w3.org/2025/11/12-dap-minutes.html tomayac 00:16:29 ... this UX is in Chrome OT 00:16:57 q? 00:17:29 Dan: because you know the user understands what s/he is clicking, showing a prompt makes this less confusion? 00:17:37 Marian: right, we can do that in the moment 00:17:46 Dan: this raises your confidence there's no mistake this this UX 00:18:15 Marian: developers are excited about this, they don't need to design UI with arrows pointing to top left, for example 00:18:40 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 00:19:05 Reilly: this flow forces user to make a decision 00:19:32 Marcos: I Safari we did that 00:20:10 Mike: Chrome's position is it is sometimes better to make prompts quieter and sometimes louder, have a signal that informs us 00:20:11 q? 00:20:33 ... you can change Safari's signal I assume 00:20:39 Marcos: not necessarily 00:20:52 Present+ Daniel_Murphy 00:21:16 Marian: I mentioned there are some security or integrity guarantees we provide, the user saw a button "use location" in some form 00:21:27 ... we lock down the content 00:21:41 ... if the language is available we use that, otherwise browser locale 00:21:50 ... element is fully controlled by browser 00:22:06 ... in these cases we check the button is fully visible with adequate contract wrt background 00:22:13 q? 00:22:34 Anssi: do you handle non-trivial cases like transparency? 00:22:45 Mike: we map the rules we have 00:23:36 Intersection Observer v2: https://web.dev/articles/intersectionobserver-v2 00:23:51 Marcos: these are parts of intersection observer v2 that are unimplementable on the WebKit side or add more complexity we are willing to add 00:24:04 ... shadows and hit testing, for example 00:24:31 ... we want a simple model, on the iOS side there's occlusion and transparency and that has served the iOS platform well 00:24:37 ... we should start with a small set 00:24:46 Mike: I'm interested in finding a compromise here 00:25:36 ... 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 00:25:47 ... the path we plan to take is we start with vital restrictions 00:26:02 ... we are open to feedback and want to take any learnings into consideration we have now 00:26:25 Marcos: base styling and static elements put too many restrictions, given Geolocation API is the fallback 00:26:37 ... not much to add in terms of restrictions 00:26:50 Mike: we present the prompt in terms of the signal we get 00:26:56 q? 00:27:09 Marcos: significant issue of the design is to have an element on the page 00:27:09 q? 00:27:41 q? 00:27:56 kagami has joined #dap 00:27:59 MarianH has joined #dap 00:28:25 q+ 00:28:27 Marcos: example is Uber, with an order button in icon mode, when watching location and the element goes away, questions like that 00:28:29 q? 00:28:35 mkwst has joined #dap 00:28:53 q+ 00:29:07 antosart: I want to ask whether we do need to have the same restriction that behaves differenty 00:29:13 ... you can always fall back to the old prompt 00:29:13 q? 00:29:16 ack antosart 00:29:19 ack mkwst 00:29:27 Mike: it is possible to use the same prompt 00:29:49 ... the primary goal is to distinguish the cases, and make it easy for the user to grant permission to the site 00:29:54 ... we don't have that singla 00:30:03 s/singla/signal 00:30:15 Mike: current implementation does not allow the use of element when styling it 00:30:27 ... amazing presentaion 00:30:30 q? 00:30:35 q+ 00:30:35 s/presentaion/presentation 00:30:54 Mike: presence of the element on the page, there are two ways developers use this element 00:31:05 ... 1) gather the information in the moment and execute the task 00:31:17 ... 2) to gather the permission on an ongoing basis 00:31:29 ... there are a number of ways we can explore to use the API 00:31:49 Alvin-Ji has joined #dap 00:31:50 ... personal opinion is, good to encourage developers to make it visible on the page the location is being used 00:31:52 q? 00:32:17 ack kagami 00:32:40 kagami: intersection observer v2 usage, we have a popover there, can we do a similar thing for the element too? 00:33:02 Mike: yes, we rely on intersection observer as a runtime evaluation so the user can actually see it 00:33:12 ... we force the element to be on the top 00:33:14 q? 00:33:23 q+ 00:33:34 Mike: better to force the element be on top 00:33:34 q? 00:33:55 kagami: not sure how the intersection observer can show up in the spec...? 00:34:29 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 00:34:45 ... current implementation allows us to put something on top of the element 00:34:46 q? 00:35:25 Anssi: learnings? 00:35:32 Mike: great example to dig into more 00:36:06 ... 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 00:36:35 ... 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 00:36:48 ... the original proposal we talk about permission element is one-size-fits-all approach 00:37:00 ... generally any information we ask for, fits that model 00:37:08 ... more tailored to a specific thing we ask for 00:37:33 ... we have a different set of heuristics for geolocation, notifications, or getDisplayMedia 00:37:44 Marcos has joined #dap 00:37:44 ... we have more confidence for a picker style UI 00:37:46 q? 00:37:49 q+ 00:38:26 Marian: was restricted and geolocation element is more relaxed in terms of presentation 00:38:29 q? 00:39:07 Marcos: given it is the form, clicking on label triggers the form 00:39:28 Mike: we don't allow label clicking to trigger geolocation element 00:39:29 q? 00:39:31 ack marcos 00:39:59 q+ 00:40:03 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? 00:40:05 (But note that the label is _always_ directly included in the button.) 00:40:13 Marcos: it is still an element in the DOM then 00:40:20 tomayac: can remove it from the DOM? 00:40:30 Marcos: not attached to the DOM then 00:40:42 ... maybe the element should not be able to watchPosition 00:40:59 Reilly: you should give the user more explicit signal 00:41:10 tomayac: stop watching if the element is removed from the DOM? 00:41:42 Mike: excited about exploration 00:41:42 q? 00:41:52 Reilly: 5 min time check 00:41:54 q? 00:41:57 q+ 00:42:10 ack tomayac 00:42:19 ack Marcos 00:42:52 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 00:42:53 q? 00:43:15 ... no way to recover, must go to open settings 00:43:38 Mike: different platforms differ here 00:43:46 Marcos: API to go to settings page? 00:44:04 Mike: using such an API would be more palatable fi we know for sure what the user wants 00:44:37 Reilly: we need more steps on the OS level to guide, take responsibility, I understand iOS is more integrated 00:44:57 Marcos: can't be an expectation for the PEPC proposal, platform limitations need to be considerations 00:44:59 q+ 00:45:03 Mike: I understand these limitations 00:45:04 q? 00:45:11 q? 00:45:15 ack MarianH 00:45:46 Marian: OT participants are excited about the recovery bit, camera and mic, also for geolocation 00:45:46 q? 00:46:29 Mike: even when we cannot recover, the browser knows it has geolocation 00:46:31 q? 00:46:47 Marcos: ask is to consider installed app to be tightly integrated into the OS 00:46:48 q? 00:47:24 Mike: iOS is special, we are dependant on y'all to help here 00:47:36 willmorgan has joined #dap 00:47:41 Reilly: Chrome for Android we do something similar, we will consider this feedback in the design 00:47:42 q? 00:47:45 q+ 00:47:54 ... we are at the end of the timebox 00:48:04 Mike: we want more people to use this 00:48:24 Mike: kagami's intersection observer feedback is very helpful 00:48:47 Mike: if there are fundamental objections we need to proceed more carefully 00:48:48 q? 00:48:50 ack willmorgan 00:49:04 (If no fundamental objections, we want to ship.) 00:49:13 willmorgan: PWA use case, at the point of install, would be the right moment to ask for this permission and otherwise block 00:49:45 Marcos: design is for time of use 00:50:05 ... having said that, Uber app for example asks for location right when I start the app 00:50:35 Marian: runtime permissions where the Android model and it created some pretty serious privacy issues 00:50:37 q? 00:50:51 Marian: asking permissions as a requiment for installation did not work out well 00:50:52 q? 00:51:31 Topic: Approximate Geolocation 00:52:24 Marcos has joined #dap 00:52:36 gb, this is w3c/geolocation 00:52:36 anssik, OK. 00:52:56 Anssi: previous topic was issue #196 00:52:56 https://github.com/w3c/geolocation/issues/196 -> #196 00:52:57 Approx Geolocation slides: https://docs.google.com/presentation/d/1HRut4OLs6WRoINrzbrqSywVJtWs0F6GublKZxko_5nA/edit?slide=id.p#slide=id.p 00:53:17 Anssi: and this issue, approximate geolocation, is issue #195 00:53:18 https://github.com/w3c/geolocation/pull/195 -> Pull Request 195 Add support for approximate geolocation (by alvinjiooo) [TPAC2025] 00:53:57 Matt: working with Antonio and Alvin on approximate geolocation 00:54:19 ... we want to mitigate risk of exposing precise geolocation, want to make this safer, and comply with legal requirements 00:54:47 ... e.g. in California we have specific requirements, different in rural locations 00:55:15 ... we want to see if we can rely on platform location, most platforms where Chrome runs we pass flags to do this 00:55:32 ... e.g. iOS and Android have an approximate concept 00:55:48 ... Windows has an option to fallback with accuracy levels 00:56:19 ... does not work with WiFI AP, might be functional now? 00:56:32 ... on iOS there's a switch to enable and disable precise geolocation per app 00:56:34 Just for fun: early 2008 mock of approximate geolocation access: https://web.archive.org/web/20080512172655im_/http://azarask.in/blog/wp-content/uploads/2008/05/geolocation-security-mockup-export.png (Source: https://web.archive.org/web/20080512172655/http://www.azarask.in/blog/post/geolocation-in-firefox-and-beyond/). 00:56:52 ... we want to expose new permission level and allow users to downgrade 00:57:17 ... sites can function and request approximate geolocation, user agent can return and obfuscate the precise 00:57:42 ... geolocation approximate concept was introduced, not all combinations possible 00:57:55 ... if you grant precise you also grant coarse geolocation 00:58:19 ... new PositionOptions changes 00:58:28 ... accuracyMode 00:58:45 ... we have enableHighAccuracy, why not reuse it? 00:59:12 ... does not provide guarantees, many platforms will still try to use precise location 00:59:25 ... many sites pass false here, so we don't want to regress the apps 00:59:32 ... defaults to false 00:59:33 q? 00:59:51 Matt: what should the old do when the new feature is there? 01:00:18 Reilly: modern devices use more complex behavour, does not map to enableHighAccuracy 01:00:27 Marcos: on legacy system it does not matter? 01:01:10 Reilly: you propose to use the existing value but change to string? 01:01:29 Marcos: correct, stringifies to "true", "false" and "precise" 01:02:04 [ add Marcos' WebIDL gymnastics joke ] 01:02:20 q? 01:02:57 Matt: proposing GeolocationPosition changes 01:03:01 https://chromestatus.com/metrics/feature/timeline/popularity/5320 01:03:04 ... accuracyMode attribute 01:03:23 ... may not be the same as if user's downgrade 01:04:58 Reilly: 2.6% of pages using geolocation set enableHighAccuracy per Chrome metrics 01:05:26 Matt: Permissions API integration changes 01:05:59 antosart: getCurrentPosition prompts, then Permissions API query() returns "granted" 01:06:00 q? 01:06:28 antosart: if only approximate geolocation is granted, this returns "ask" or "deny" 01:06:34 ... open to revisit this 01:06:36 Marcos has joined #dap 01:06:48 q+ 01:07:13 ack Marcos 01:07:51 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 01:08:30 Reilly: key thing, browser tells I only give you approximate geolocation 01:08:42 Marcos: as a user I might not tell the truth 01:08:58 Reilly: user wants to lie to the site I'm precisely here even if I'm not 01:09:16 Present+ Vincent_Scheib 01:09:41 Marcos: my phone may not get a GPS lock, I might be revealing too much 01:09:51 Reilly: faking the location would not be a reliable privacy shield 01:10:29 Marcos: I want to further investigate accuracyMode in permission status 01:10:54 Matt: we get accuracy value in the object, can look at that, could look at that also 01:10:57 q? 01:11:52 Matt: what requirements we should have for the algorithm to generate estimated location 01:12:08 ... Mozilla has one algorithm implemented as an extension 01:12:17 ... Apple has its own algorithm 01:12:42 ... we don't know if these algorithms meet specific requirements, can't ask for implementers to do that 01:13:06 ... we can guarantee "coarsened position estimate" 01:13:28 ... multiple estimates collected over time can generate a more precise estimate 01:13:48 q+ 01:13:53 ... guarantees for developers, can satisfy some legal requirements 01:13:55 q? 01:14:13 ack Marcos 01:14:27 Marcos: the platform dependency is visible here 01:15:23 Matt: want to bring this feature to platforms that do not have support for approximate geolocation 01:15:43 ... precise location reconstruction, reduce time resolution 01:15:56 Marcos: standard per platform? 01:16:14 Matt: not fully researched yet 01:16:36 [ Matt shows a demo! ] 01:18:55 Marcos: WebKit is broadly excited about this feature 01:19:19 kagami has joined #dap 01:19:22 tomayac: Android allow precise and non-precise location, this UI demoed will not show you that option? 01:19:24 q+ 01:19:56 antosart: in page setting you see a message only approximate geolocation is allowed, a trade-off 01:20:10 ack kagami 01:20:22 kagami: a question about watchPosition and approximate geolocation 01:20:36 ... what is the expected UX there, what happens in native apps then? 01:20:52 Matt: watchPosition and approximate, not well defined yet 01:21:05 ... we are going to say you only get an estimate every one minute or so 01:21:07 q? 01:21:15 RRSAgent, draft minutes 01:21:16 I have made the request to generate https://www.w3.org/2025/11/12-dap-minutes.html anssik 01:21:22 side note: element slides: https://docs.google.com/presentation/d/1IzZDnW6-pQDMEaISkydhZKCupMQskQh_WUSujb6Y2go/edit?slide=id.p#slide=id.p 01:21:24 Marcos: we should investigate what the platforms are doing 01:21:25 q? 01:22:09 Reilly: watchPosition has to make sense in context of loop-calling getPosition 01:22:28 ... the discussion we've had here, the desire is if the user does not move outside the course region, the value should not change 01:22:38 ... we can still provide the value repeatedly 01:22:42 q+ 01:22:59 ... interesting question is how far the user has to go to trigger a new location update 01:23:23 ... e.g. on a train, you get period updates that maintain privacy principles while give you an approximate location 01:23:43 q? 01:23:46 ack Marcos 01:24:24 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 01:24:44 ... good exercise, some platforms use the browser implementation, not platform-provided coarse-location 01:24:56 Matt: we want to allow implementations to innovate here 01:24:58 q? 01:25:21 Reilly: any upcoming shipping plans or last-minute feedback from implementers? 01:25:21 kagami has joined #dap 01:25:58 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 01:26:07 now in Beta, going to Stable for a small test group 01:27:08 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 01:27:08 q? 01:27:58 RRSAgent, draft minutes 01:27:59 I have made the request to generate https://www.w3.org/2025/11/12-dap-minutes.html anssik 01:34:51 RRSAgent, draft minutes 01:34:53 I have made the request to generate https://www.w3.org/2025/11/12-dap-minutes.html anssik 02:04:16 Matt_Reynolds has joined #dap 02:04:21 Topic: Confusion about geolocation emulation in two specs 02:04:36 Anssi: issue #212 02:04:37 https://github.com/w3c/geolocation/issues/212 -> #212 02:05:01 Reilly: this was per the preference of WebDriver authors, prefer to close this issue 02:05:21 Marcos: I was confused because this issue did not link back to WebDriver 02:05:21 q? 02:05:31 kagami has joined #dap 02:06:42 big-screen has joined #dap 02:06:42 willmorgan has joined #dap 02:07:02 MarianH has joined #dap 02:07:19 RESOLUTION: Keep the split and add a non-normative reference from Geolocation to WebDriver for the automation section, for issue #212 02:07:46 Topic: Better integration with testing framework 02:07:54 Anssi: issue #193 02:07:55 https://github.com/w3c/geolocation/issues/193 -> Issue 193 Better integration with testing framework (by marcoscaceres) [TPAC2025] 02:08:14 matatk has joined #dap 02:08:17 Marcos: testing framework has a virtual location, but in theory in browser you set a location and browser gives back what you have 02:08:19 m-alkalbani has joined #dap 02:08:23 Reilly: this is push model, not pull 02:08:27 present+ Matthew_Atkinson 02:08:37 ... I think we resolve this making those changes 02:09:29 RESOLUTION: Make the changes suggested by Marcos in issue #193 02:10:06 Topic: Improve position accuracy definition 02:10:11 Anssi: issue #206 02:10:11 https://github.com/w3c/geolocation/issues/206 -> Issue 206 Improve position accuracy definition (by marcoscaceres) [TPAC2025] 02:10:39 Marcos: I did archeology, confidence level is 95% baked into the spec, wishful thinking at the time this was specified 02:10:53 ... was 67% on Android, and on iOS 65-75% or so 02:11:03 ... we return null on Apple platforms 02:11:22 Reilly: the additional context is, it is better to define accuracy, does the spec say accuracy must be something 02:11:57 ... 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 02:12:08 ... centre of the oval and the probability the user is inside it 02:12:12 ... I did research 02:12:36 ... GPS receivers, with user in that 3d space, 65% 02:12:47 s/GPS/for GPS 02:13:31 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 02:14:06 ... at the risk of making the API more complicated, we could make the API more complicated adding the confidence to the API 02:14:44 Marcos: I like the idea of revealing it is 65% or so, it complicates things yes 02:15:06 Reilly: you need mapping libraries on top 02:15:16 [ Reilly pointing at the UX person in the room ] 02:15:34 Marcos: not to reveal a lot, it is OS-level information, nice to reveal on the location object 02:15:43 Reilly: nice standards position from WebKit 02:17:19 https://github.com/w3c/geolocation/issues/206 -> Issue 206 Improve position accuracy definition (by marcoscaceres) [TPAC2025] 02:17:25 q? 02:19:20 RESOLUTION: Draft a PR to remove any specific confidence value and attribute, and clarify the meaning of the accuracy value (issue #206) 02:20:03 kagami: I'm fine with this resolution 02:20:44 Topic: The timeout option doesn't make sense for watchPosition 02:20:51 Anssi: issue #184 02:20:52 https://github.com/w3c/geolocation/issues/184 -> Issue 184 The `timeout` option doesn't make sense for watchPosition (by saschanaz) [TPAC2025] 02:21:31 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 02:21:58 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 02:22:19 ... timeout is not meaningful in this context 02:22:41 ... I think the proposal is to clarify the timeout only applies to the first fix deadline 02:22:44 q? 02:23:07 Marcos: we should say what timeout 0 means here 02:23:27 Reilly: now the default value is Infinite that's kind of 0, but we should encourage Infinity proper 02:23:49 ... why we have differentiation between 0 and Infinite is that 0 means check cached position 02:24:26 ... 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 02:24:56 ... 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 02:25:14 ... in Chromium we have a cache, there are bugs so we have considered removing that code path 02:25:24 ... another parameter I'd like to get rid off 02:25:49 ... it does not reflect the 2025 reality of geolocation capabilities in devices 02:26:01 ... return the cache or throw a timeout immediately 02:26:12