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.

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]

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.

[antosart]

I wrote some web platform tests to cover accuracyMode in getCurrentPosition(), cf. web-platform-tests/wpt#61742.

[marcoscaceres]

I think the tests don't match the spec. Sent a fix: web-platform-tests/wpt#61886

For future tests, can I ask that they are sent as regular PRs so other browser vendors have a chance to review them? 🙏

[marcoscaceres]

On what WebKit does, since the question of what "approximate" means concretely came up, and in case it is useful input for a testing rule.

We coarsen at the single point where a position is delivered to the page, so the one-shot, watch and cached paths all get the same treatment. The rule is deterministic, with no randomness and no time input, so repeated reads of the same true position return the same approximate point rather than letting a site average successive answers toward the real one.

• Snap to a grid of about 5 km. The number is not arbitrary: it matches what CoreLocation produces for reduced accuracy, which its header describes as "a horizontalAccuracy on the order of about 5km", adding that "CoreLocation will snap location estimates to a nearby point which represents the region the device is in". The intent is that an approximate position from the web is never more precise than what the platform gives a native app that was denied precise location.
• Scale the longitude step by 1/cos(latitude), so the cell stays roughly 5 km wide away from the equator instead of narrowing to a few hundred meters at high latitude, clamped so it stays finite near the poles.
• Never report an accuracy tighter than the cell, and never tighter than the input, since the reported uncertainty has to cover the true position.
• Drop altitude, altitudeAccuracy, heading and speed, which is what this pull request now requires.

None of that is meant as the only reasonable rule, and the 5 km figure is a platform match rather than a guarantee about any particular device. It is offered because a concrete set of numbers seemed more useful here than another round of argument about whether the area should be bounded.

[antosart]

I think the tests don't match the spec. Sent a fix: web-platform-tests/wpt#61886

For future tests, can I ask that they are sent as regular PRs so other browser vendors have a chance to review them? 🙏

Indeed, thanks for fixing. I actually tried to open a PR to wpt in the past, but I have no rights on the repo, and even finding out who could review my PR was basically impossible (so that I ended up redoing the same in chromium). But I'll try again next time though!

[marcoscaceres]

@sideshowbarker 👆🙏

[marcoscaceres]

@saschanaz see my suggestion above about coarsening and making it more deterministic, specifically over Web Driver. Would that work for you?

[saschanaz]

specifically over Web Driver

I don't see how it helps if it's just specific to webdriver - that won't allow testing anything on real behavior, right?

[marcoscaceres]

@saschanaz i think quite a bit, like coarsening, making sure the various things that need to be null are null’ed out (see test fix above). And cache behavior in both modes (cache allowing). It’s pretty comprehensive and there’s room to make it better.

I haven’t implemented the testing API in WebKit, but just from the tests, we can get a lot of behavior tested.

@antosart, does this Web Driver extension allow emulation of both precise and approx? If so, we I think we could have something really good here

[martinthomson]

It might help with testing, but I'm not convinced about the privacy story. A lack of dynamism makes this easier to reason about, but it still means a two-layer prompting story if a site ever wants to get better geolocation. That's not privacy harm in the information-loss sense, but privacy harm in the annoying AF sense.

[marcoscaceres]

😹 it’s not that bad, @martinthomson. Yes, it’s potentially a second prompt on upgrade, but it’s the exceptional case and it still puts the user in control. But then it becomes more of a UX problem.

At least, if a site generally needs approx, but sometimes precise, it can request precise up front and approx data. That “solves” double prompting.

[antosart]

@antosart, does this Web Driver extension allow emulation of both precise and approx? If so, we I think we could have something really good here

I'm open to this. I only wonder if it is worth to specify (and implement) in details a coarsening algorithm only for testing purposes (as opposed to, for example, just saying that the webdriver coarsened location should have null heading, speed, altitude, altitudeAccuracy and accuracy > X km).

[marcoscaceres]

a coarsening algorithm only for testing purposes

sorry, I was not clear. It’s not for “testing purposes”, a cached precise position can be coarsened by the UA without hitting the GPS module. That’s great for both privacy and power efficiency.

[marcoscaceres]

(We might be accidentally talking past each other, but I think are goal is the same… we need to fix #193 which should make testing act “like the real thing”… I’m definitely not proposing any deviation from specified behavior when using web driver: setting a position via Web Driver would exercise the real code paths)

[antosart]

sorry, I was not clear. It’s not for “testing purposes”, a cached precise position can be coarsened by the UA without hitting the GPS module. That’s great for both privacy and power efficiency.

My concern with that is that by potentially exposing to a website two positions, coarsened in different ways (one coarsened by the device, one by the UA computed from a cached precise position) we will end up exposing more information (the website can now infer that the user is in the intersection of the two positions).

Fixing #193 makes sense to me. But couldn't we just have a "cached precise position" and a "cached approximate position"?

[marcoscaceres]

I’m not following. The site already had the user’s precise position? Getting approx just gives them a coarse thing they already have. What am I missing?

[antosart]

Sorry, maybe we are talking past each other. I thought you were proposing to add a coarsening algorithm to the spec, for coarsening a cached precise position?

My point is: if there are two ways of producing a coarsened location (one is produced directly by the user agent, another one comes directly from the underlying device) and the coarsening algorithms are different, then we might end up exposing more information than expected.

[saschanaz]

It may still be useful to provide coarsened location if the previous one is outdated enough, maybe the user moved far enough or it was just a long time ago, etc.

[sideshowbarker]

@antosart

I actually tried to open a PR to wpt in the past, but I have no rights on the repo

You should now have waiting in your inbox an invite to join the WPT Reviewers GitHub team. Once you accept that, you’ll have push/write perms for the WPT repo.

and even finding out who could review my PR was basically impossible

That’s a separate problem that we can’t really do anything about from the WPT side. As an author of a WPT PR you’re expected to find your own reviewer for the PR. O else, if you’re upstreaming a test change that’s already gone through internal review within your own engine project (for changes to an in-tree imported downstream copy of the WPT test) then you can state as much in the WPT PR description, and either ask for someone else from your project to rubberstamp the WPT PR, or else mention @web-platform-tests/admins in a comment and ask for an admin merge.

That said, since the Chromium project also has the @chromium-wpt-export-bot for upstreaming WPT test changes, you can hook into that from any Chromium changeset. And as far as I know, that’s supposed to mark the upstreamed WPT as already-reviewed and ready-to-merge (as long as it passes all the other WPT GH Actions checks).