Add support for approximate location (without separate permission)

[antosart]

Closes #182

This PR is an alternate version of #195, introducing the ability for developers to request a less precise, privacy-preserving "approximate" location but without defining a separate powerful feature nor prescribing a specific permission model which distinguishes approximate and precise geolocation. In particular, while this PR is motivated by the explainer, it actually tries to follow and specify the proposed WebKit model.

The following tasks have been completed:

• Modified Web platform tests (n/a, this change cannot be tested).

Implementation commitment (and no objections):

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

Documentation (new feature):

• Updated implementation report
• Pinged MDN
• Added example to README or spec

---

Preview | Diff

[antosart]

@marcoscaceres can you have a look and confirm if this version of the PR adheres to the WebKit model you proposed and hence is acceptable for WebKit.

We believe this can be acceptable for Chromium.

[reillyeon]

Some editorial comments, but overall this looks good to me.

[antosart]

Some editorial comments, but overall this looks good to me.

Thanks, I've addressed your comments!

[reillyeon]

Thank you for revising this proposal. @marcoscaceres, please take a look.

[alvinjiooo]

Thank you for revising this proposal. @marcoscaceres, please take a look.

Hi @marcoscaceres,
Do you get a chance to review this PR (which avoid adding new permission for Approximate Geolocation support)?

[marcoscaceres]

Sorry, been trying my best to get back to this 🙈. Got dragged into finishing another project.

[marcoscaceres]

Feels kinda not great to have this note (instead of handling this in the algorithm)... like, should we have a flag or something that assures the prompt and when it doesn't?

[antosart]

I added the note to clarify that this will not result in a prompt to the user, but I am also happy to remove the note.

According to the Permissions specification, this won't result in an additional prompt being displayed, because the user has already been prompted for the same options. Unfortunately, the Permissions specification does not prescribe how the user agent should store internally the chosen option, nor it provides any other algorithm to just query it, so I am not sure how else to word this.

[marcoscaceres]

Can we set up a call to chat if enableHighAccuracy can stand for AccuracyMode?

[marcoscaceres]

I'm flipping this to "approved", but don't merge it yet. I want to do prototype implementation first and check if everything is ok.

I'm getting Claude to implement it, but doing a spec-driven / conformance-first implementation, where the implementation is a test of the spec. I'm hopeful that by being super rigorous, it should generate a bunch of comments and fixes to the PR.

Expect some suggestions coming in...

[Copilot]

Pull request overview

This PR updates the Geolocation specification to support a privacy-preserving “approximate position” mode without introducing a separate powerful feature, aligning the permission/choice flow with a “choose accuracy” model.

Changes:

• Defines “precise position”, “approximate position”, and an “approximate location information source”.
• Adds AccuracyMode and PositionOptions.accuracyMode, plus new examples and privacy guidance around approximate location.
• Updates the permission request and acquisition algorithms to incorporate accuracy choice and caching behavior keyed by the chosen accuracy.

Comments suppressed due to low confidence (1)

index.html:905

• The list item that introduces |promptOptions|/|permission| includes an <aside>, but the <li> itself is not explicitly closed before the next <li> begins. This relies on HTML's implicit <li> closing and is inconsistent with the rest of the algorithm markup.

              </aside>
              <li>If |permission| is "denied":

---

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

[marcoscaceres]

Feedback from a WebKit prototype of this PR (spec-driven, implementation as a conformance test). Three comments below: one construction bug ([[accuracyMode]] is never set), and two suggested clarifying notes.

[antosart]

Thanks for finding these additional issues/bugs! I addressed all the comments (also from copilot).

[marcoscaceres]

Awesome, thanks... still validating the WebKit implementation... but have something drafty working.

[marcoscaceres]

@antosart can you arrange for Mozilla to review this too? It’s looking pretty solid.

We also need to update the testing part, I think.

[antosart]

@antosart can you arrange for Mozilla to review this too? It’s looking pretty solid.

Thanks! I pinged Mozilla in the standard position request and asked them if they'd like to review.

We also need to update the testing part, I think.

Do you mean adding WPTs? We will definitely update the idlharness tests to include accuracyMode. For the rest, it's not really clear to me what is testable or it makes sense to test here. We could tweak the emulation part so that instead of emulating a single position, both an approximate and a precise emulated position can be set. We could then test that a site requesting approximate location gets the emulated approximate position - but we can't really test that a site requesting precise location gets the emulated precise position since that depends on the granted accuracy permission, which in turn cannot really be set via emulation (I don't think Permissions has any hooks for that). Somehow it's not clear to me whether it's worth doing this.

[saschanaz]

If it's not testable, we effectively don't have normative way to enforce any behavior. The spec has no clear definition of what is "approximate position", which also makes it untestable. What does Blink and WebKit PRs do? Can we make it normative based on whatever the PRs do, and make tests based on that?

[antosart]

If it's not testable, we effectively don't have normative way to enforce any behavior. The spec has no clear definition of what is "approximate position", which also makes it untestable. What does Blink and WebKit PRs do? Can we make it normative based on whatever the PRs do, and make tests based on that?

We can definitely change set emulated position to be able to set both an approximate and a precise location. We can then test that requesting approximate location returns the emulated approximate location and requesting precise location returns the emulated precise location. @marcoscaceres do you think that would make sense?

[saschanaz]

I would more expect the browser process the approximate coordinate, if then we don't need to pass two location. And emulate a moving user and see how the approximate mode ensures a certain level of "approximate"-ness. We should not just delegate to system behavior.

[reillyeon]

We should not just delegate to system behavior.

Why not, if the platform provides a "approximate location" concept? Wouldn't this be more consistent with user expectations?

[marcoscaceres]

Yeah, I agree with @antosart and @antosart. This is a rare case where we do want to hand it to the OS if possible, even if it becomes non-deterministic. The OS is in the best, um, position to provide the appropriate position (no pun intended). For testing via webdriver, we could define a rule, like round to x and y degrees and drop heading, speed, etc.

[saschanaz]

Because that's a complete black box for spec perspective. Less black box for Apple et al. given they have access for their respective implementation, but less so for others. Mozilla will have zero idea how they works, what they actually ensure.

[marcoscaceres]

Follow-up to my comment about defining a rule for testing: the draft does not say what happens to altitude, altitudeAccuracy, speed, and heading on an approximate position. positionData is built once for both accuracy modes and those attributes are only "null if not available", so an implementation can return a city-level position carrying real speed and heading, which is the reconstruction that "Preventing Precise Location Reconstruction" asks the source to mitigate.

Android's platform coarsening already does this: LocationFudger.createCoarse() calls removeBearing(), removeSpeed(), and removeAltitude() under the comment "clear any fields that could leak more detailed location information".

The step is in antosart#2, added to "A new GeolocationPosition" so it covers the emulated-position path and is testable.

[antosart]

The step is in antosart#2, added to "A new GeolocationPosition" so it covers the emulated-position path and is testable.

Thanks. I think that makes sense, merged in this PR now.