Approximate Geolocation: permissions

[marcoscaceres]

Specification title

Approximate Geolocation (PositionOptions.accuracyMode and the "geolocation-approximate" permission)

Specification or proposal URL (if available)

w3c/geolocation#195

Explainer URL (if available)

https://github.com/w3c/geolocation/wiki/Approximate-Geolocation:-Permissions-Model-Comparison

(See also the Chromium-side explainer: https://github.com/explainers-by-googlers/approximate-geolocation/)

Proposal author(s)

@marcoscaceres, @reillyeon (spec editors); @antosart, @alvinjiooo, @nondebug (Chromium)

MDN URL

No response

Caniuse.com URL

No response

Bugzilla URL

No response

Mozillians who can provide input

No response

WebKit standards-position

No response (the WebKit-favored design is one of the two models described in the linked wiki document; a separate WebKit standards-positions filing has not yet been opened)

Other information

The W3C Devices and Sensors Working Group is asking for Mozilla input on a specific unresolved question in the Geolocation API's approximate-location work, rather than on the feature as a whole. The areas of agreement and disagreement are summarized in the wiki page linked above.

What both sides agree on:

• A new accuracyMode member on PositionOptions, accepting "precise" (default) or "approximate".
• "geolocation-approximate" as a Permissions Policy token for iframe restriction.
• Backward compatibility with existing getCurrentPosition() / watchPosition() behavior.
• Dropping the originally proposed GeolocationPermissionStatus and coords.accuracyMode additions.

Where the working group is split:

Whether "geolocation-approximate" should also be queryable via navigator.permissions.query().

• The Chromium-favored model adds it as a second queryable permission name. This preserves the invariant that permissions.query() predicts whether getCurrentPosition() will prompt, and enables an onchange event when a user grants approximate-only via browser UI. It also makes an approximate-only grant distinguishable by sites that query both names.
• The WebKit-favored model does not add a new queryable name. permissions.query({name: "geolocation"}) returns its current three states; sites learn the resulting accuracy only via coords.accuracy on returned positions, and cannot distinguish a user privacy choice from a hardware/signal limitation. This preserves the precedent set by enableHighAccuracy (a hint with no report-back).

Specific questions the WG is asking reviewers (full text in the wiki):

1. Does adding a second queryable permission name compound the concerns raised in w3c/permissions#52 about passive information availability via the Permissions API?
2. Can the onchange-on-grant flow be preserved with a single queryable permission, or does it require two?
3. Should the spec include normative guidance on adding entropy to approximate positions (Android's LocationFudger currently snaps to a detectable grid)?
4. Should accuracyMode follow the enableHighAccuracy precedent (hint, no report-back), or is a user privacy choice categorically different from a hardware capability hint?
5. Should the spec mandate one model, or leave queryability of "geolocation-approximate" to UA discretion?

The wiki page was drafted as a neutral side-by-side comparison and reviewed by both sides before distribution; it includes an appendix describing exactly how it was generated. Mozilla input would be most useful on questions 1, 2, and 5, which turn on privacy properties of the Permissions API surface rather than on Geolocation specifics.

[alvinjiooo]

To add more context, the previous issue for the entire feature (Approximate Geolocation) is at #1193 . This one focus on the discussion of the permission model for the feature.