-
Couldn't load subscription status.
- Fork 64
Add support for approximate geolocation #195
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
This commit introduces the ability for users and developers to request a less precise, privacy-preserving "approximate" location. Key changes include: - A new `accuracyMode` option in `PositionOptions` to request either "precise" or "approximate" location. - A new `geolocation-approximate` permission and policy, which is implicitly granted if the "geolocation" permission is given. - Separate internal caching for precise and approximate positions. - Updated "Request a position" and "Acquire a position" algorithms to handle the new accuracy levels, permission fallback, and caching logic. - The `GeolocationPosition` interface now includes an `accuracyMode` attribute to reflect the accuracy of the returned position. - Expanded privacy and user consent sections to discuss the benefits and user interface implications of approximate location.
index.html
Outdated
| </p> | ||
| <p> | ||
| To better protect user privacy, this specification also provides a way | ||
| for users to share an <em>approximate location</em> instead of a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should define all our terms here with <dfn> tags so we can refer back to them elsewhere in the spec.
I think we should define "approximate location" in a way that makes it clear it's an optional thing that some location sources support and some don't. The previous paragraph refers to "sources of location information", I think we should turn it into a proper definition and refer to it here.
Perhaps:
An <dfn>approximate location information source</dfn> is a [=location information source=] that returns positions that have been intentionally obfuscated to make it more difficult to recover the true location.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently I added precise position and approximate position and approximate location information source to the introduction chapter. PTAL
|
For readability as you iterate on this proposal it's okay for this PR to directly change the specification text however to land this change the changes need to be enclosed in the correct candidate additions/corrections/deletions syntax. |
|
@reillyeon if it's ok, let's move this to CR first (i.e., let's not waste time with the ins/dels). We are close to publishing as CR again. |
index.html
Outdated
| <aside class="example" title="Permissions Policy over HTTP"> | ||
| <pre class="http"> | ||
| Permissions-Policy: geolocation=() | ||
| Permissions-Policy: geolocation=(), geolocation-approximate=() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about just writing
Permissions-Policy: geolocation-approximate=()
here and explaining in words that by disabling geolocation-approximate, geolocation will automatically be disabled too?
index.html
Outdated
| permission|checks permission=] for the level of accuracy specified by | ||
| the {{PositionOptions/accuracyMode}} option. A grant for the | ||
| "geolocation" permission implies a grant for the | ||
| "geolocation-approximate" permission. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would add
"while if the "geolocation-approximate" is denied, then so is "geolocation""
index.html
Outdated
| "geolocation-approximate" permission. | ||
| </p> | ||
| <p> | ||
| When <dfn data-local-lt="check permission">checking permission</dfn> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we'll want to expand this and clarify that when requesting permission to use geolocation, the user will also be prompted for geolocation-approximate. This will probably require some changes to https://www.w3.org/TR/permissions/#dfn-request-permission-to-use so that that algorithm can be overridden, and we'll need to override it here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you mean we should add the case when website request position using accuracy_mode='approximate', the prompt should show approximate option and denial only?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, I mean that when the website requests position using accuracy_mode='precise', then the browser should show a prompt that allows the user to either grant precise location or approximate location. So a request for precise location might end up changing the values of both the geolocation and geolocation-approximate permissions.
For how things work at the moment in the spec, two different powerful features are independent from each other and you can either prompt for one or for the other. I think we want some mechanism so that the prompts for the two features geolocation and geolocation-approximate are intertwined.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for clarification, I added a new for "request geolocation permission" to describe the interaction between "geolocation" and "geolocation-approximate", also use it in "Request a position". Please review this part see if this make more sense now.
99d9b03 to
3fa8869
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR adds support for approximate location positioning to the Geolocation API specification. It introduces a privacy-preserving alternative to precise location sharing, allowing applications to request coarse-grained location data when high accuracy is not needed.
Key changes:
- Introduces
accuracyModeoption with "precise" (default) and "approximate" values - Adds new "geolocation-approximate" permission alongside existing "geolocation" permission
- Implements separate caching for precise and approximate positions
- Updates permission request flows to allow users to choose between precise and approximate location sharing
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| <li>Go to <a href="#errors-reasons">dealing with | ||
| failures</a>. |
Copilot
AI
Oct 29, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The link references #errors-reasons, but this section ID no longer exists in the document. The 'Dealing with failures' section appears to have been removed during the refactoring. This broken link should either be removed or updated to reference the correct error handling section, or the id=\"errors-reasons\" anchor should be restored.
| <li>Go to <a href="#errors-reasons">dealing with | |
| failures</a>. | |
| <li>Go to dealing with failures. |
| <li>Do the <a href="#permission-denied">user or system denied | ||
| permission</a> failure case step. |
Copilot
AI
Oct 29, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The link references #permission-denied, but this section ID no longer exists in the document. The 'User or system denied permission' section appears to have been removed during the refactoring. This broken link should either be removed or updated to reference the correct error handling, or the id=\"permission-denied\" anchor should be restored.
| <li>Do the <a href="#permission-denied">user or system denied | |
| permission</a> failure case step. | |
| <li>Handle the user or system denied permission failure case. |
| <tr> | ||
| <td> | ||
| <del><dfn data-dfn-for= | ||
| "Geolocation">[[\cachedPosition]]</dfn></del> | ||
| </td> | ||
| <td> | ||
| <del>A {{GeolocationPosition}}, initialized to null. It's a | ||
| reference to the last acquired position and serves as a cache. A | ||
| user agent MAY evict {{Geolocation/[[cachedPosition]]}} by | ||
| resetting it to null at any time for any reason.</del> | ||
| </td> | ||
| </tr> | ||
| <tr> | ||
| <td> |
Copilot
AI
Oct 29, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The deprecated [[cachedPosition]] internal slot is marked with <del> tags but is still present in the specification table. This entry should be completely removed rather than shown as deleted text in the final specification, as it may confuse readers about what is actually part of the current API.
| <tr> | |
| <td> | |
| <del><dfn data-dfn-for= | |
| "Geolocation">[[\cachedPosition]]</dfn></del> | |
| </td> | |
| <td> | |
| <del>A {{GeolocationPosition}}, initialized to null. It's a | |
| reference to the last acquired position and serves as a cache. A | |
| user agent MAY evict {{Geolocation/[[cachedPosition]]}} by | |
| resetting it to null at any time for any reason.</del> | |
| </td> | |
| </tr> | |
| <tr> | |
| <td> | |
| <tr> | |
| <td> |
| <li>Let |positionData| be a [=map=] with the following | ||
| name/value pairs based on the acquired position data: | ||
| <dl> | ||
| <dt> |
Copilot
AI
Oct 29, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The positionData map is missing the required "latitude" field. The specification defines longitude, altitude, accuracy, altitudeAccuracy, speed, and heading, but does not include latitude, which is a fundamental coordinate required for geolocation.
| <dt> | |
| <dt> | |
| "latitude" | |
| </dt> | |
| <dd> | |
| A {{double}} that represents the latitude coordinates | |
| on the Earth's surface in degrees, using the [[WGS84]] | |
| coordinate system. Latitude measures how far north or | |
| south a point is from the Equator. | |
| </dd> | |
| <dt> |
This commit introduces the ability for users and developers to request a less precise, privacy-preserving "approximate" location.
Key changes include:
Closes #182
Approximate Geolocation explainer
Preview | Diff