#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.

Discussed Sep 8, 2025 (See Github)

Ehsan: Will raise any issues in the repo separately.

Matthew: One conern re Ehsan's comments, unclear ot me the Explainer is ... it is not in the spec, and there should be one. Don't know if that decision was finalised. Some of the things in the Explainer whether there'd be a prompt.

Yves: Part of the draft response I made was not treating it the same was as IP location. By default, it says if you're using a prompt, continue using it. Depends on the rest of the specification.

Ehsan: Jeffrey mentioned there is a prompt section in the spec and somehow implies mandatory prompt.

Marcos: Not yet clear what fingerprinting risks are.

Lola: What would be significant enough?

Marcos: We don't know what it looks like. re legal, wide enough? e.g. 500something meters enough vs. like country-wide. We don't know at this point what that looks like. What the underlying platform gives. Could chopping off the coordinate system be enough.

Ehsan: Whether that approximate data is good enough to mask the exact location. Having that approximate data from Android, then with like 1000 data points to get accurate data. It is mentioned in the spec that the frequency in that approximate is every 15m. These combined increases the attack vector significantly.

Ehsan: The other concern is about getting more precise geo location data. Like people's locations. I don't know if the Explainer accurately mentions, whether same concern as precise. What do others think?

Marcos: These are valid points / explorations on how all this could work. The general idea is possible but how it works in practice needs ot be raised.

Hadley: 500m may be okay to obscure identity in the city but not in the country. It could be identifiable in some rural areas. So the population density makes a good difference.

Ehsan: I think population factors into geolocation in operating systems. It's in the explainer.

Hadley: Reassured to hear that.

Lola: Sounds like there is still some info the group is waiting for some legal stuff to happen?

Marcos: There are the legal things in place and what the right thing is for users. They weren't always designed with privacy in mind, more focused on battery usage. Whether the privacy goals can be made by the platform. If the thing was designed around battery usage, then that might or not be an issue. It can be done in a country wide. There are some great unknowns.

Lola: Sounds like the group still has some work to do. We tell them our concerns / questions around the prompt stuff. So, comment can go on the main thread. Who is going to draft the comment?

Ehsan: There is a draft.

Lola: Noting Yves has a comment. Also you want to add stuff about prompting to Yves' comment.

Matthew: Maybe we're happy with it.

Lola: Will leave it to Yves.

Yves: If Ehsan has additional comments, please add to private brainstorming.

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?

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

@alvinjiooo On 5, the other way around: the returned value is always "accurate", since browsers don't enable location spoofing. But the configuration here is about how "precise" to make the value: how much different measurements of the same position might diverge from each other.

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

@jyasskin Thank you for that excellent point regarding "accuracy" vs. "precision." You're right that "precision" (or granularity).

While investigating this, I found that the platform-level APIs we'd be building on are also inconsistent, which makes the choice difficult.

  • Apple's CoreLocation API uses desiredAccuracy (e.g., kCLLocationAccuracyBest, kCLLocationAccuracyKilometer).
  • Android's GMS Location API uses Granularity (e.g., GRANULARITY_FINE, GRANULARITY_COARSE).
  • Microsoft (WinRT): DesiredAccuracy (using enum values Default, High)

Since this is a new enum for the web platform and the underlying ecosystem is fragmented, perhaps this naming decision warrants a wider discussion. We will have this noted and see if we can discuss the final name of it in TPAC this year and see what it best way moving forward.

Also copying @nondebug here.

Comment by @martinthomson Sep 22, 2025 (See Github)

As far as naming goes, the best I have is uncertainty. It's the term that metrologists use, which is why it ended up in RFC 7459. Of course, then you need to think about confidence, which that document recommends setting to a fixed value, rather than signaling it.