Add support for approximate geolocation by alvinjiooo · Pull Request #195 · w3c/geolocation

alvinjiooo · 2025-09-05T01:37:19Z

Closes #182

This commit introduces the ability for users and developers to request a less precise, privacy-preserving "approximate" location.

Key changes include:

A new accuracyMode option in PositionOptions to request either "precise" or "approximate" location.
A new "Geolocation permissions" section, which include new "geolocation-approximate" powerful feature and custom precise permission query or request algorithm.
Updated "Request a position" and "Acquire a position" algorithms to handle the new accuracy levels and new emulation change (feat: add accuracyMode to emulation.setGeolocationOverride webdriver-bidi#1105).
The GeolocationCoordinates interface now includes an accuracyMode attribute to reflect the accuracy of the returned position.
Expanded the introduction with a non-normative description of what an "approximate location" is.
Added a normative privacy requirement for user agents to mitigate precise location reconstruction by caching approximate locations for a period of time.
Updated

The following tasks have been completed:

Modified Web platform tests (link to pull request)

Implementation commitment (and no objections):

WebKit
Chromium (https://bugs.chromium.org/p/chromium/issues/detail?id=)
Gecko (https://bugzilla.mozilla.org/show_bug.cgi?id=)

Documentation (new feature):

Updated implementation report
Pinged MDN
Added example to README or spec

For documentation, either create an issue or pull request in MDN's Content repo - providing as much information as you can. PR is prefered.

Approximate Geolocation explainer

Preview | Diff

reillyeon · 2025-09-09T22:59:16Z

For readability as you iterate on this proposal it's okay for this PR to directly change the specification text however to land this change the changes need to be enclosed in the correct candidate additions/corrections/deletions syntax.

marcoscaceres · 2025-09-11T09:43:50Z

@reillyeon if it's ok, let's move this to CR first (i.e., let's not waste time with the ins/dels). We are close to publishing as CR again.

Copilot

Pull Request Overview

This PR adds support for approximate location positioning to the Geolocation API specification. It introduces a privacy-preserving alternative to precise location sharing, allowing applications to request coarse-grained location data when high accuracy is not needed.

Key changes:

Introduces accuracyMode option with "precise" (default) and "approximate" values
Adds new "geolocation-approximate" permission alongside existing "geolocation" permission
Implements separate caching for precise and approximate positions
Updates permission request flows to allow users to choose between precise and approximate location sharing

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

antosart

A few comments wrt the permission handling.

marcoscaceres

Please remove all the "Candidate addition" stuff. We don't need any of that additional markup anymore (but leave the rest of normative text there 😄 ) .

nondebug

lgtm

alvinjiooo · 2026-01-29T01:15:26Z

Please remove all the "Candidate addition" stuff. We don't need any of that additional markup anymore (but leave the rest of normative text there 😄 ) .

Should we split out the "Candidate addition" removal stuff in a separate CL? It would make this one a little easier to parse :)

It sounds like #181 will be landed soon once the status change happened. I will rebased this PR again once that one is landed.

alvinjiooo · 2026-03-20T03:31:46Z

Hi @marcoscaceres and @antosart ,
I rebased the PR and now we finally get rid of ins and del tag.
PTAL and share your comments.
Thanks!

- Define explicit coherence requirements between "geolocation" and "geolocation-approximate" permission states. - Fix typos and clarify logic in the precise permission query algorithm. - Update the 'set emulated position data' definition and 'Acquire a position' algorithm to consume an Infra map, aligning the Geolocation spec with the WebDriver BiDi implementation. - Rename effectiveAccuracy to accuracyMode in the 'Constructing a GeolocationPosition' algorithm.

antosart

looks good to me now, thanks for all the iterations on this!

alvinjiooo · 2026-03-27T06:16:23Z

Hi @marcoscaceres ,
May I have your help to review this PR?
Thanks!
Alvin

- Update GeolocationPosition and GeolocationCoordinates interfaces to move accuracyMode. - Update 'Acquire a position' and 'Constructing a GeolocationPosition' algorithms to reflect the move. - Align emulation logic with WebDriver BiDi by using 'type' for error codes and embedding accuracyMode in coordinates. - Tidy index.html.

alvinjiooo · 2026-04-06T23:10:17Z

Hi @reillyeon,
Will you have a chance to review this PR before it lands?
Thanks!

Copilot

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 6 comments.

Comments suppressed due to low confidence (1)

index.html:951

This uses [=list/remove=] (lowercase list), but elsewhere the spec uses [=List/remove=] for the Infra list operation. The lowercase form likely won’t resolve to the intended definition; please align the casing with the rest of the document.

              If |resolvedPermissionState| is "denied", then:
                <ol>
                  <li>If |watchId| was passed, [=list/remove=] |watchId| from
                  |watchIDs|.
                  </li>

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

marcoscaceres

Looking good @alvinjiooo ... there seems to be some unrelated editorial changes.

Maybe see about splitting those out (get Genini maybe to do them quickly?). Will make this easier to review.

marcoscaceres · 2026-04-07T02:27:21Z

+          [=approximate positions=]. To mitigate this risk of a refinement
+          attack, when a site receives an [=approximate position=], any
+          subsequent calls from that same site within a user-agent-defined time
+          window SHOULD return the exact same, cached [=approximate position=]


This needs to be in the algorithm (if it's not already).

I did consider formalizing this caching logic within the algorithm. However, opinions on the practical risk of precise location reconstruction still vary, and there isn't a single standardized approach yet. Coupled with the existing visibility requirements, a caching window (like 15 minutes) already makes reconstruction extremely difficult in practice. Keeping this in the Privacy Considerations section provides strong guidance while leaving implementers flexibility as mitigation strategies evolve. I’m inclined to leave it as a 'SHOULD' recommendation rather than a hard algorithmic requirement for now, but I'd be interested to hear your thoughts on this framing.

marcoscaceres · 2026-04-07T02:31:01Z

-                    <dl class="switch">
-                      <dt id="permission-denied">
-                        User or system denied permission:
+              <li data-cite="infra">If acquiring the position data from the


This change seems unrelated or maybe the white space got screwed up?

This one is not changed by the PR, the original place is at here. It got moved further down because the introduced change for approximate geolocation.

marcoscaceres · 2026-04-07T02:32:04Z

+            </ol>
          </li>
        </ol>
+        <dl class="switch">


Does this belong in this PR? Can it be a separate PR?

This part is not changed too, the original place is at here.

- Rephrase privacy risk mitigation and user choice framing for clarity and neutrality. - Update terminology from 'powerful features' to 'permissions' and 'protecting' to 'obscuring'. - Add cross-references to the 'acquire a position' algorithm and AccuracyMode enum values. - Fix ReSpec linking errors and IDL formatting. - Remove redundant MUST statements from informative notes. - Tidy index.html.

marcoscaceres · 2026-04-20T07:10:07Z

Really nice work getting this to a reviewable state, @alvinjiooo.

I want to raise a privacy concern about two pieces: GeolocationPermissionStatus and coords.accuracyMode.

The design lets sites request approximate via PositionOptions.accuracyMode, which is great for data minimization. But I think we should stop there and not tell the site what the user actually chose.

GeolocationPermissionStatus: This exposes the user's privacy preference via navigator.permissions.query() without any position request. There's no precedent for permission result types exposing user preference metadata (camera doesn't reveal which device was selected, notifications doesn't reveal quiet mode). This is closely related to the long-standing concern in w3c/permissions#52 — expanding the queryable surface to include how a user configured their privacy preference compounds the risk. I'd propose removing this entirely, and making "geolocation-approximate" not a JS-queryable permission name. Only "geolocation" should be valid for permissions.query(). This keeps the API backwards-compatible: sites cannot use permissions.query() to pre-detect whether approximate location is available or what the user chose, preserving the same opacity as a UA that doesn't support the feature.

coords.accuracyMode: Today, coords.accuracy of 5000m is ambiguous: it could be the user's privacy choice, bad GPS lock, or WiFi-only positioning. That ambiguity prevents reliable upgrade-nagging. A definitive "approximate" flag removes that ambiguity and enables "tap here for better location" dark patterns. I'd propose removing this attribute.

Permissions Policy gating: I think "geolocation-approximate" still has value as a policy-controlled feature for iframe restriction. But the allowed to use check in the algorithm (currently only checking "geolocation") needs updating: if accuracyMode is "approximate", check allowed to use "geolocation-approximate"; if "precise", check allowed to use "geolocation". And allowing "geolocation" should implicitly allow "geolocation-approximate" (superset), but not vice versa.

Summary:

Keep PositionOptions.accuracyMode (site requests what it needs)
Keep "geolocation-approximate" for Permissions Policy (iframe control)
Remove GeolocationPermissionStatus (no custom permission result type)
Remove coords.accuracyMode (site doesn't learn what user chose)
Only "geolocation" is queryable via Permissions API
Add proper allowed to use checks per accuracy mode

I'd like to invite @martinthomson, @saschanaz, and @npdoty to weigh in on the privacy model here. Once we converge on the right shape, I think this warrants a formal PING review given the sensitivity of location privacy.

marcoscaceres

See #195 (comment) ... as I think the permission model needs a significant overhaul... and could be simultaneously significantly simplified.

marcoscaceres · 2026-04-20T05:44:58Z

+          </pre>
+        </aside>
+        <p>
+          Similarly, you can request a cached approximate position.


Suggested change

Similarly, you can request a cached approximate position.

Similarly, you can request a cached approximate position:

marcoscaceres · 2026-04-20T05:45:47Z

              successCallback,
              console.error,
-              { maximumAge: 600_000 }
+              { maximumAge: 600_000 } // `accuracyMode` defaults to "precise"


Suggested change

{ maximumAge: 600_000 } // `accuracyMode` defaults to "precise"

{

maximumAge: 600_000,

// `accuracyMode` defaults to "precise"

}

marcoscaceres · 2026-04-20T05:46:58Z

+          new position.
        </p>
-        <aside class="example" title="Getting cached position">
+        <aside class="example" title="Getting a cached precise position">


Just a nit... but it feels like we could cover both cases with just one example.

marcoscaceres · 2026-04-20T05:47:38Z

+        The {{PositionOptions/accuracyMode}} option enhances user privacy by
+        providing websites with the choice to request an [=approximate
+        position=]. This allows applications to function without needing the
+        user's [=precise position=], thus offering a more privacy-friendly


Suggested change

user's [=precise position=], thus offering a more privacy-friendly

user's [=precise position=], thus offering a more privacy-preserving

marcoscaceres · 2026-04-20T05:57:35Z

+        the user agent can provide a less precise location that still meets the
+        application's needs while obscuring the user's [=precise position=].


The user agent can't know if the position will meet the sites needs. It can only return an approximate position. If it's good enough, that's up to the site to determine.

Suggested change

the user agent can provide a less precise location that still meets the

application's needs while obscuring the user's [=precise position=].

a supporting user agent MUST provide a less precise location,

obscuring the user's [=precise position=].

marcoscaceres · 2026-04-20T06:05:57Z

+          (for approximate location).
+        </p>
+        <p>
+          There is a strict dependency between the [=permission state=]s of


Suggested change

There is a strict dependency between the [=permission state=]s of

There is a strict dependency between the [=permission states=] of

marcoscaceres · 2026-04-20T06:06:47Z

+          implies denying a [=precise position=]. This results in the following
+          allowed combinations of states:
+        </p>
+        <ul>


Nit: I wonder if this should be a table?

marcoscaceres · 2026-04-20T06:09:30Z

+        <p>
+          Implementers MUST ensure that these states remain coherent. For
+          example, if a user changes the [=permission state=] of
+          <a>"geolocation-approximate"</a> to [=permission/"denied"=] via site


Right, but this needs to be an algorithm. We can wire up the Permission side later, but this still needs to be algorithmically defined.

Basically, the algorithm receives the new state, and then it dos all the things defined here.

marcoscaceres · 2026-04-20T06:10:42Z

+        <p>
+          Implementers MUST ensure that these states remain coherent. For
+          example, if a user changes the [=permission state=] of
+          <a>"geolocation-approximate"</a> to [=permission/"denied"=] via site


Also, this can be very racy, so some kind of coordinator will still be needed where this is queued.

marcoscaceres · 2026-04-20T06:20:02Z

+          while <a>"geolocation"</a> is a [=powerful feature=] with:
+        </p>
+        <ul>
+          <li>A custom [=powerful feature/permission result type=]


Do we really need to leak the user's choice? This seems like it shouldn't be needed. The site should just get back a portion, but it shouldn't know what the user selected or when it's changed, right?

antosart · 2026-04-20T18:07:49Z

Wrt leaking the granted accuracy (either in GeolocationPermissionStatus or in coords.accuracyMode) our main thought was that in practice there is no real way to hide this (on Android, for example, a coarsened position has a fixed accuracy - I believe it's 2000m - and the possible values for the x and y coords are on a grid, so that it seems clear that the position is artificially coarsened and not the result of bad GPS signal).

As for the geolocation-approximate permission policy, I agree there is value in having it. However, it's not totally trivial how to make it work correctly because of the interdependencies between geolocation and geolocation-approximate, which are not currently supported by the Permission Policy specification (see explainers-by-googlers/approximate-geolocation#19 and explainers-by-googlers/approximate-geolocation#20 for more details).

marcoscaceres · 2026-04-21T01:02:13Z

I get that Android's current LocationFudger implementation snaps to a grid, which makes approximate positions detectable in practice. But I think the right response is to encourage UAs to add entropy (jitter, noise, variable quantization) to make approximate less detectable, rather than formalizing the leak with coords.accuracyMode. The browser doesn't have to pass the OS's accuracy value or grid pattern through to JS unchanged. Chrome on Android could add noise to the grid-snapped position before delivering it to content, making grid detection unreliable.

The spec should push implementations toward privacy (guidance on resisting detectability), not codify worst-case current behavior as the API surface.

On the "sites need to know" argument: I think there are two legitimate needs here, and neither requires coords.accuracyMode:

Pre-permission capability detection ("does this browser support approximate?"): A CSS media feature would let sites adapt their UI before ever calling the API, e.g., showing "we only need your city-level location" messaging. This is pure capability detection, no user preference leak.
Post-permission UX adaptation ("is this position good enough for walking directions?"): coords.accuracy already answers this. If accuracy is 3000m, you show city-level features regardless of whether that's approximate mode, bad GPS, or WiFi-only positioning. The site should be checking the number anyway. And even with accuracyMode: "approximate", the UA could return a position with 50m accuracy (the request is a hint, not a guarantee), so the site can't rely on the label for UX decisions.

So the model would be: CSS media feature for capability → PositionOptions.accuracyMode for request → coords.accuracy for adaptation. No flag that reveals the user's privacy choice.

On Permissions Policy: agreed it's non-trivial. I've looked at issues explainers-by-googlers/approximate-geolocation#19 and explainers-by-googlers/approximate-geolocation#20 in the explainer repo. The inheritance problem needs upstream Permissions Policy spec work, but that seems like the right path rather than working around it.

alvinjiooo requested a review from nondebug September 5, 2025 18:25

nondebug reviewed Sep 5, 2025

View reviewed changes

jyasskin mentioned this pull request Sep 12, 2025

Approximate Geolocation w3ctag/design-reviews#1131

Closed

2 tasks

alvinjiooo mentioned this pull request Sep 12, 2025

Approximate geolocation WebKit/standards-positions#470

Closed

antosart reviewed Sep 18, 2025

View reviewed changes

Comment thread index.html Outdated

Comment thread index.html Outdated

Comment thread index.html Outdated

Comment thread index.html Outdated

Comment thread index.html Outdated

Comment thread index.html Outdated

alvinjiooo force-pushed the add-approximate-geolocation branch from 99d9b03 to 3fa8869 Compare September 22, 2025 22:49

marcoscaceres added the TPAC2025 Topics for discussion at TPAC 2025 label Oct 28, 2025

marcoscaceres requested a review from Copilot October 29, 2025 06:42

Copilot AI reviewed Oct 29, 2025

View reviewed changes

Comment thread index.html

Comment thread index.html

Comment thread index.html Outdated

Comment thread index.html

alvinjiooo force-pushed the add-approximate-geolocation branch from 3fa8869 to 8658f5a Compare December 5, 2025 19:45

alvinjiooo marked this pull request as draft December 5, 2025 20:13

alvinjiooo self-assigned this Dec 5, 2025

alvinjiooo force-pushed the add-approximate-geolocation branch 6 times, most recently from 2354ca8 to d3a4d47 Compare December 12, 2025 18:56

alvinjiooo requested a review from nondebug December 12, 2025 18:58

alvinjiooo marked this pull request as ready for review December 12, 2025 19:00

nondebug reviewed Dec 12, 2025

View reviewed changes

antosart reviewed Dec 15, 2025

View reviewed changes

Comment thread index.html Outdated

Comment thread index.html Outdated

Comment thread index.html Outdated

marcoscaceres requested changes Dec 16, 2025

View reviewed changes

alvinjiooo force-pushed the add-approximate-geolocation branch from d3a4d47 to b0d0589 Compare January 10, 2026 04:54

alvinjiooo requested review from antosart and nondebug January 14, 2026 01:39

antosart reviewed Jan 15, 2026

View reviewed changes

Comment thread index.html

Comment thread index.html Outdated

nondebug approved these changes Jan 23, 2026

View reviewed changes

alvinjiooo requested a review from antosart January 29, 2026 01:15

tomvangoethem reviewed Feb 5, 2026

View reviewed changes

Comment thread index.html Outdated

antosart reviewed Feb 5, 2026

View reviewed changes

Comment thread index.html Outdated

Comment thread index.html Outdated

Comment thread index.html Outdated

alvinjiooo force-pushed the add-approximate-geolocation branch from 491b324 to 79598a3 Compare February 5, 2026 23:29

marcoscaceres self-requested a review March 12, 2026 21:14

rebase to Chore: remove updatable-rec stuff (w3c#224)

75126d4

alvinjiooo force-pushed the add-approximate-geolocation branch from 79598a3 to 75126d4 Compare March 19, 2026 20:38

alvinjiooo requested a review from antosart March 20, 2026 03:30

alvinjiooo mentioned this pull request Mar 21, 2026

feat: add accuracyMode to emulation.setGeolocationOverride w3c/webdriver-bidi#1105

Open

antosart reviewed Mar 23, 2026

View reviewed changes

Comment thread index.html Outdated

Comment thread index.html

Comment thread index.html

Alvin Ji added 2 commits March 25, 2026 16:10

correct typo

0f52a5e

alvinjiooo requested a review from antosart March 26, 2026 03:16

antosart approved these changes Mar 26, 2026

View reviewed changes

alvinjiooo requested a review from reillyeon April 6, 2026 22:57

marcoscaceres requested a review from Copilot April 7, 2026 01:21

Copilot started reviewing on behalf of marcoscaceres April 7, 2026 01:22 View session

Copilot AI reviewed Apr 7, 2026

View reviewed changes

Comment thread index.html

Comment thread index.html Outdated

Comment thread index.html Outdated

Comment thread index.html Outdated

Comment thread index.html Outdated

Comment thread index.html

marcoscaceres reviewed Apr 7, 2026

View reviewed changes

alvinjiooo requested a review from marcoscaceres April 8, 2026 07:29

marcoscaceres requested changes Apr 20, 2026

View reviewed changes

	Similarly, you can request a cached approximate position.
	Similarly, you can request a cached approximate position:

	user's [=precise position=], thus offering a more privacy-friendly
	user's [=precise position=], thus offering a more privacy-preserving

		the user agent can provide a less precise location that still meets the
		application's needs while obscuring the user's [=precise position=].

	There is a strict dependency between the [=permission state=]s of
	There is a strict dependency between the [=permission states=] of

Conversation

alvinjiooo commented Sep 5, 2025 • edited by pr-preview bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

reillyeon commented Sep 9, 2025

Uh oh!

marcoscaceres commented Sep 11, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull Request Overview

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

antosart left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

marcoscaceres left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

nondebug left a comment

Choose a reason for hiding this comment

Uh oh!

alvinjiooo commented Jan 29, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

alvinjiooo commented Mar 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

antosart left a comment

Choose a reason for hiding this comment

Uh oh!

alvinjiooo commented Mar 27, 2026

Uh oh!

alvinjiooo commented Apr 6, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

alvinjiooo commented Sep 5, 2025 •

edited by pr-preview bot

Loading

marcoscaceres left a comment •

edited

Loading

alvinjiooo commented Mar 20, 2026 •

edited

Loading