#1131: Approximate Geolocation

Visit on Github.

Opened Aug 8, 2025

Specification

https://github.com/w3c/geolocation/pull/195

Explainer

https://github.com/explainers-by-googlers/approximate-geolocation/blob/main/README.md

Links

The specification

Where and by whom is the work is being done?

  • GitHub repo: https://github.com/w3c/geolocation/

  • Primary contacts:

    • $name @alvinjiooo (spec change collaborator)
    • $name @nondebug (spec change collaborator)
    • $name @antosart (spec change collaborator)
    • $name @reillyeon (spec editor)

  • Organization/project driving the specification: Chromium

  • This work is being funded by: N/A

  • Primary standards group developing this feature: Web Applications WG and Device and Devices and Sensors Working Group

  • Incubation and standards groups that have discussed the design: https://github.com/w3c/geolocation/issues/182

Feedback so far

You should also know that...

Here are the responses to the Security and Privacy Considerations Questionnaire.

2.1. What information does this feature expose, and for what purposes?

This feature modifies how geolocation data is exposed to websites. The primary purpose is to enhance user privacy by allowing sites to function with a less-precise, approximate location, which still serves user needs (like finding nearby points of interest) without revealing sensitive, precise locations (like a home address).

  • To a first party: The feature exposes a new piece of information: GeolocationPosition.accuracyMode (with values "precise" or "approximate"). This tells the site whether the location it received was intentionally coarsened for privacy. It also exposes a less precise version of the user's location than what is currently available.

  • To third parties: The exposure is the same as for first parties. However, the design specifies integration with Permissions Policy, allowing the top-level site to restrict or disable this feature in third-party iframes, giving them control over what embedded content can access.

2.2. Do features in your specification expose the minimum amount of information necessary?

Yes, data minimization is the core principle of this feature. By introducing an "approximate" location option, the specification allows a site to receive only the level of location accuracy users grant, rather than defaulting to the most precise location possible. The design explicitly aims to provide a "less effective signal" for tracking by grouping users into larger geographic areas.

2.3. Do the features in your specification expose personal information?

Yes, geolocation is personal information. The design addresses this by introducing a new, more granular permission model.

  • It adds a "geolocation-approximate" permission, which is subordinate to the existing "geolocation" permission.
  • This creates a tiered system where users can grant permission for only approximate location, giving them more direct and meaningful control over how their personal information is shared. The feature relies on this enhanced permission model to acquire user consent.

2.4. How do the features in your specification deal with sensitive information?

This feature deals with sensitive location information by adhering to a new, more granular permission model, as described in the explainer. To mitigate the risks of exposing a sensitive, precise location, the feature will prompt the user to grant permission for either precise or approximate location. Based on the user's choice, the browser will return location data at the corresponding level of granularity. This ensures that when a user only consents to sharing an approximate location, the feature provides coarsened data that is less sensitive but still sufficient for many common use cases.

2.14. How does this specification distinguish between behavior in first-party and third-party contexts?

The explainer explicitly calls for Permissions Policy integration. This allows a first-party site owner to create policies that can selectively disable or enable both precise ("geolocation") and approximate ("geolocation-approximate") location access for any embedded third-party iframes. This gives the first party direct control over the feature's use in third-party contexts.

2.16. Does this specification have both "Security Considerations" and "Privacy Considerations" sections?

Yes, the Geolocation API specification defines "Privacy Considerations" and "Security Considerations" sections.

<!-- Content below this is maintained by @w3c-tag-bot -->

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1131

Discussions

Log in to see TAG-private discussions.

Discussed Sep 1, 2025 (See Github)

Lola: Not had a chance to look. Some feedback on the explainer, but nothing much. No Christian here today.

Marcos: Have looked. It's interesting. ... An interesting thing that has come up with this one, for longer term consideration, is that the granularity can be so wide that it may not warrant a prompt any more because it is roughly equivalent to IP geolocation. Putting that out there to think about. I don't know what that means if there is a VPN active.

Lola: Is that something they need to put in the security considerations?

Yves: The VPN question is important here. It is easy to fake location with a VPN, but not with the API. Is there something needed to activate.

Marcos: This doesn't currently require user activation, which is an outstanding issue on the main spec.

Yves: A permission might not be for every call. If you request far too often, you might be able to infer the proper location instead of getting an approximated one.

Marcos: In practice, you don't query, you'll get a cached position from subsequent requests. It's not cheap to update the location. For this you would get something stale.

Yves: Might need to explicitly add something to avoid oversampling.

Lola: Others might have input, but it sounds like we need to give people a chance to review.

Yves: not a negative comment, just feedback.

Martin: We could put the comment in.

Lola: Not confident in drafting a comment.

Yves: I can try to draft something.

Comment by @ylafon Sep 12, 2025 (See Github)

The proposal looks interesting, we still have a few comments:

1/ Requesting several times an approximate location could lead to disclosing the real location, if not cached or strictly rate-limited, the spec should consider being explicit about that risk

2/ location in general is not easy to fake, unlike an ip address which can be hidden using a VPN as an example. Even if it is not currently considered, coarse location should not be considered equivalent to IP geolocation, unless the same capability of intentionally changing location is available.

3/ There is a concern of leakage of private information due to the granularity of the coarsing algorithm provided at the OS level. The spec includes this in Preventing Precise Location Reconstruction by throttling the geolocation data intervals to every 15 minutes. There is no mention of that in the explainer. Can you please clarify that, and highlight any other defences against this?

Comment by @jyasskin Sep 12, 2025 (See Github)

I also wanted to individually add that

  1. Your specification link should to go to the PR defining this feature, and not to the overall spec that it will eventually land in.
  2. I believe you're using the wrong one of "precision" vs "accuracy": https://en.wikipedia.org/wiki/Accuracy_and_precision. You've copied the mistake from the old field, but since you're replacing that field, maybe you can fix the mistake.
Comment by @alvinjiooo Sep 12, 2025 (See Github)

The proposal looks interesting, we still have a few comments:

1/ Requesting several times an approximate location could lead to disclosing the real location, if not cached or strictly rate-limited, the spec should consider being explicit about that risk

I agree that this is a critical risk. I have updated the explainer so now it matched to what we have in spec PR to be explicit about this threat, which we refer to as a "precise location reconstruction" attack.

2/ location in general is not easy to fake, unlike an ip address which can be hidden using a VPN as an example. Even if it is not currently considered, coarse location should not be considered equivalent to IP geolocation, unless the same capability of intentionally changing location is available.

I agree that approximate geolocation, as proposed here, is not equivalent to IP-based geolocation or a user's ability to provide an arbitrary location. The goal of this proposal is to empower users to share a less precise version of their actual location to enhance privacy, rather than to enable location spoofing. The control offered to the user is the choice between "precise" and "approximate," which we consider is an privacy enhancement for users.

3/ There is a concern of leakage of private information due to the granularity of the coarsing algorithm provided at the OS level. The spec includes this in Preventing Precise Location Reconstruction by throttling the geolocation data intervals to every 15 minutes. There is no mention of that in the explainer. Can you please clarify that, and highlight any other defences against this?

Thank you for pointing out, similar to point 1), I have just updated the explainer to include the threat and mitigation discussion. If we spot on more threats then we can continue to update section and try to come up mitigations.

Comment by @alvinjiooo Sep 12, 2025 (See Github)

I also wanted to individually add that

  1. Your specification link should to go to the PR defining this feature, and not to the overall spec that it will eventually land in.

Thanks! I have this link now update in the TAG review issue content.

  1. I believe you're using the wrong one of "precision" vs "accuracy": https://en.wikipedia.org/wiki/Accuracy_and_precision. You've copied the mistake from the old field, but since you're replacing that field, maybe you can fix the mistake.

I wonder do you think we should change from using "precise" to "accurate" in the proposed AccuracyMode?