+ This specification provides two ways for users to share their location: + a precise position and an approximate position. +
++ A precise position is a position returned by the underlying + [=location information source=]. By default, any location data is + considered precise, regardless of its accuracy estimate, unless it has + been explicitly coarsened by an [=approximate location information + source=] to be an [=approximate position=]. +
++ An approximate position is a less precise, + privacy-preserving representation of the user's location. Instead of + providing precise coordinates, the user agent MUST return a location + that is intentionally coarsened to a larger area, such as the nearest + city, postal code, or a predefined region. This is often sufficient for + applications that don't need to know the user's [=precise position=], + for example, a weather application that only needs a city-level + location. By sharing an [=approximate position=], users can still get + the benefit of a location-aware application without revealing their + [=precise position=]. +
++ An approximate location information source is a [=location + information source=] that returns positions that have been + intentionally obfuscated to make it more difficult to recover the true + location.
If an end user [=check permission|grants permission=], @@ -149,7 +178,11 @@
Request the user's current location. If the user allows it, you will - get back a position object. + get back a position object. The website can influence the position's + accuracy by using the `accuracyMode` option. By default, the user + agent will provide a `"precise"` location, but a website can request + an `"approximate"` location if it doesn't require high accuracy, + which helps protect user privacy.
+By default, the API always attempts to return a cached position so - long as it has a previously acquired position. In this example, we - accept a position whose age is no greater than 10 minutes. If the - user agent does not have a fresh enough cached position object, it - automatically acquires a new position. + long as it has a previously acquired position that matches the + requested `accuracyMode`. In this example, we accept a precise + position whose age is no greater than 10 minutes. If the user agent + does not have a fresh enough cached position object of the correct + accuracy, it automatically acquires a new position.
-Third-party usage can be selectively enabled by adding the - [^iframe/allow^]`="geolocation"` attribute to an [^iframe^] element: + [^iframe/allow^]`="geolocation"` or `allow="geolocation-approximate"` + attribute to an [^iframe^] element. Note that if `geolocation` is + allowed, `geolocation-approximate` is also implicitly allowed.
Alternatively, the API can be disabled in a first-party context by - specifying an HTTP response header: + specifying an HTTP response header. Disabling + `geolocation-approximate` will also disable `geolocation`.
@@ -364,6 +434,19 @@
+ To mitigate this privacy risk, this specification introduces the + {{PositionOptions/accuracyMode}} option, which allows the application + to request an [=approximate position=]. This allows applications to + function without needing the user's [=precise position=], thus offering + a more privacy-friendly alternative. When an application requests an + [=approximate position=], the user agent can provide a less precise + location that still meets the application's needs while protecting the + user's [=precise position=]. Even when a [=precise position=] is + requested, the user agent can provide an [=approximate position=] + instead, for example, if the user has only granted permission for + approximate accuracy. +
An end-user will generally give [=express permission=] through a user - interface, which usually present a range of permission + interface. [=User agents=] with support for [=approximate position=] + SHOULD allow the user to choose between sharing a [=precise + position=] or an [=approximate position=]. This choice gives users + more control over their privacy, allowing them to share a less + precise location when they are not comfortable sharing their + [=precise position=]. +
++ The user interface will usually present a range of permission [=permission/lifetimes=] that the end-user can choose from. The choice of [=permission/lifetimes=] vary across user agents, but they are typically time-based (e.g., "a day"), or until browser is closed, @@ -420,6 +511,17 @@
+ In line with this principle, recipients are strongly encouraged to + request the lowest level of location accuracy that is sufficient for + their application's functionality. For instance, if an application + only needs to know the user's city, it should request an + [=approximate position=] by setting the `accuracyMode` option to + `"approximate"`. This is preferable to requesting a [=precise + position=], which is done by either setting `accuracyMode` to + `"precise"` or by leaving the option unset. This practice of data + minimization is a key aspect of respecting user privacy. +
The recipients of location information need to refrain from retransmitting the location information without the user’s express @@ -460,16 +562,93 @@
Geolocation is a [=default powerful feature=] identified
- by the [=powerful feature/name=] "geolocation".
+ by the [=powerful feature/name=]s "geolocation" for [=precise position=] and
+ "geolocation-approximate"
+ for [=approximate position=].
- When checking permission - to use the API, a user agent MAY suggest time-based [=permission=] + To request geolocation permission for a given + {{PermissionDescriptor}} |descriptor|, the user agent MUST run the + following steps. These steps override the default behavior of + [=request permission to use=] for these features. +
++ A user agent MAY also suggest time-based [=permission=] [=permission/lifetimes=], such as "24 hours", "1 week", or choose to remember the permission [=permission/grant=] indefinitely. However, it is RECOMMENDED that a user agent prioritize restricting the @@ -479,6 +658,21 @@
+ A malicious actor could potentially infer a user's [=precise + position=] by collecting and correlating multiple, distinct + [=approximate position=]s. To mitigate this risk of a refinement + attack, when a site receives an [=approximate position=], any + subsequent calls from that same site within a user-agent-defined time + window SHOULD return the exact same, cached [=approximate position=] + data. A user agent might, for example, use a time window of 15 + minutes. +
+- [=Call back with error=] passing |errorCallback| and - {{GeolocationPositionError/PERMISSION_DENIED}}. -
- + A non-negative {{double?}} that represents the altitude + accuracy, or `null` if not available, indicating the + 95% confidence level in meters. Altitude accuracy + measures how close the measured altitude is to the true + altitude.
+ enum AccuracyMode {
+ "precise",
+ "approximate"
+ };
+
dictionary PositionOptions {
+ AccuracyMode accuracyMode = "precise";
boolean enableHighAccuracy = false;
[Clamp] unsigned long timeout = 0xFFFFFFFF;
[Clamp] unsigned long maximumAge = 0;
};
+ + The accuracyMode member is used to request a specific + level of accuracy. It can be set to "precise" to request the most + accurate location data available, or "approximate" to receive a less + accurate location that protects user privacy. The default value is + "precise". +
+ ++ The accuracyMode attribute indicates the accuracy level of + the position, which can be either `"precise"` or `"approximate"`. + This reflects the level of accuracy that was granted and used to + obtain the position. +
+A new `GeolocationPosition` is constructed with [=map=] - |positionData|, {{EpochTimeStamp}} |timestamp:EpochTimeStamp| and - boolean |isHighAccuracy| by performing the following steps: + |positionData|, {{EpochTimeStamp}} |timestamp:EpochTimeStamp|, + boolean |isHighAccuracy|, and string |effectiveAccuracy| by + performing the following steps:
@@ -1504,10 +1792,18 @@
- This specification defines a [=policy-controlled feature=] identified - by the token string "geolocation". Its [=policy-controlled + This specification defines two [=policy-controlled features=] + identified by the token strings "geolocation" and + "geolocation-approximate". Their [=policy-controlled feature/default allowlist=] is [=default allowlist/'self'=].
++ The "geolocation" policy controls access to [=precise position=], while + "geolocation-approximate" controls access to [=approximate position=]. + Granting "geolocation" permission implicitly grants + "geolocation-approximate" permission as well, while restricting + "geolocation-approximate" also restricts "geolocation". +