Intent to Change - Geolocation maximum age

196 views
Skip to first unread message

Matt Reynolds

unread,
Oct 31, 2017, 5:48:26 PM10/31/17
to blin...@chromium.org

Primary eng (and PM) emails

SWE: mattre...@chromium.org

TL: sch...@chromium.org

PM: owe...@chromium.org


Summary

Chrome does not enforce the maximumAge option in geolocation API calls (getCurrentPosition, watchPosition) when the location provider returns a stale position estimate. Changing the implementation to match the spec will cause a noticeable difference in behavior for applications that request fresh position estimates.


Motivation

The maximumAge option allows the caller to specify an upper bound for the age of cached position estimates. The age is calculated as the duration from the time of the position fix to the time of the API call (getCurrentPosition or watchPosition). The default value for maximumAge is zero, indicating that cached estimates should not be returned. Instead, the position callback should be delayed until a fresh estimate is available or the call times out.


Returning stale position estimates to callers who have requested fresh estimates may have privacy implications as it could expose the user's prior position estimate. For instance, a user might switch location mode from "High accuracy" to "Device only" to avoid Wi-Fi-based tracking. A cached position estimate from before the location mode was changed could expose a Wi-Fi-based estimate to the page. The risk is higher if the device is not able to generate a position fix in "Device only" mode since the cached estimate will be retained longer.


Interoperability and Compatibility Risk


The geolocation API is supported in all major browsers, but implementations differ in how they handle the maximumAge option. Due to the current diversity in behavior it is unlikely that this change poses a significant compatibility risk.


Edge: Partially supported.


Specifying non-zero values for maximumAge will not cause cached position estimates to be returned. From the observed behavior it seems that Edge does not cache position estimates.


Firefox: Supported.


Returned position estimates are never older than maximumAge. When the cached estimate is too stale, Firefox waits until a fresh estimate is available. The behavior in Firefox matches my reading of the spec.


Safari: Partially supported.


On the first call to getCurrentPosition or after a period of inactivity, Safari may return a cached estimate outside the maximumAge window. Subsequent calls return fresh estimates.


Alternative implementation suggestion for web developers

The previous behavior caused Chrome to sometimes return quickly with a cached position estimate even when the position options specified that the cached estimate should not be returned. This behavior is incorrect with respect to the spec, but ensured that callers would not experience extended delays waiting for a position estimate.


After this change, developers who need the old behavior (quickly return a cached estimate) can replicate it by setting maximumAge to a large value.


Usage information from UseCounter

Geolocation is not yet instrumented. I've created a CL to add UseCounter metrics for getCurrentPosition and watchPosition:

https://chromium-review.googlesource.com/c/chromium/src/+/747862


Tracking bug

http://crbug.com/769231


Entry on the feature dashboard

This falls under the Geolocation feature:

https://www.chromestatus.com/features/6348855016685568


A separate feature entry is not needed as this is a minor change that brings us closer in line with the spec.

Joe Medley

unread,
Nov 2, 2017, 10:41:51 AM11/2/17
to Matt Reynolds, blink-dev
The bug link on the status entry is broken. It should be the tracking bug anyway. Please fix.

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195
If an API's not documented it doesn't exist.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BqnoufPVy%3DT7A-M-Yt5ROrYRj_N1zu8CqjZ2uJ6RgBasBo9WQ%40mail.gmail.com.

Daniel Bratell

unread,
Nov 2, 2017, 11:29:52 AM11/2/17
to Matt Reynolds, 'Joe Medley' via blink-dev, Joe Medley
Seems like a reasonable change. If I understand correctly it will not prevent web pages from doing anything they did before. The thing that will change is that if they request a new-ish position, they will no longer get an old position? 

I can only think of one possible concern. If it's common to call getCurrentPosition() with default arguments, then maxage=0 which means "don't return anything cached". Previously Chrome returned some position even if it was stale? Should this be something to worry about? Those sites will either get a delay while a position is calculated, or no position at all?

/Daniel
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJUhtG89kCvqWz2CUdkLJ08dJ6bzReMaXqZ-G1-X7qQn6r4LhQ%40mail.gmail.com.



--
/* Opera Software, Linköping, Sweden: CET (UTC+1) */

Matt Reynolds

unread,
Nov 3, 2017, 1:19:43 PM11/3/17
to Daniel Bratell, 'Joe Medley' via blink-dev, Joe Medley
> If it's common to call getCurrentPosition() with default arguments, then maxage=0 which means "don't return anything cached". Previously Chrome returned some position even if it was stale?

The buggy behavior is platform-dependent since it only occurs if the location provider API returns stale estimates. In particular, FusedLocationProviderApi on Android can return stale estimates. Chrome for Android switched to this provider in M60; previously it used the Android Location API. Location API doesn't return stale estimates unless the caller specifically asks for them with getLastKnownLocation.

(This bug was particularly bad on Android because FusedLocationProviderApi won't spin up GPS if the client doesn't stay subscribed long enough. When calling getCurrentPosition, Chrome would only stay subscribed long enough to get a single estimate. This meant that the same stale estimate would be returned after every call. The fix will permit Chrome to stay subscribed if the first estimate is stale to give the provider a chance to generate a fresh estimate.)

I haven't seen the bug on other platforms, it seems maximumAge is correctly handled elsewhere.

> Should this be something to worry about? Those sites will either get a delay while a position is calculated, or no position at all?

The default options also specify timeout:Infinity, so the expected outcomes are either a fresh position estimate (after some delay) or no response.

I expect in practice there will be little observable difference. This change primarily affects the behavior on Android, where the bug was only caught because of a bad interaction with the location provider.

This change will likely increase battery usage on Android due to increased use of active location providers (GPS, Wi-Fi scanning).

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Daniel Bratell

unread,
Nov 6, 2017, 12:28:18 PM11/6/17
to Matt Reynolds, 'Joe Medley' via blink-dev, Joe Medley
Now "Intent to Change" has no defined process. Do you want it to follow the Intent to ship process? It seems that you have this under control and I've seen nobody else with any concerns.

/Daniel
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.



--
/* Opera Software, Linköping, Sweden: CET (UTC+1) */

Vincent Scheib

unread,
Nov 6, 2017, 12:43:28 PM11/6/17
to Daniel Bratell, Matt Reynolds, 'Joe Medley' via blink-dev, Joe Medley, Shruthi, Dimitri Glazkov
I think this change falls under "Trivial Changes ... changes to existing APIs to improve compliance with web standards or to fix bugs ... send at a PSA to blink-dev or ask an API OWNER for advice".

CC sshruthi dglazkov for process suggestions & meta point: I think we should improve https://www.chromium.org/blink to call out at a header section how to handle changes like this, including a formal template.


To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.



--
/* Opera Software, Linköping, Sweden: CET (UTC+1) */



--
/* Opera Software, Linköping, Sweden: CET (UTC+1) */

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

Chris Harrelson

unread,
Nov 6, 2017, 3:15:28 PM11/6/17
to Vincent Scheib, Daniel Bratell, Matt Reynolds, 'Joe Medley' via blink-dev, Joe Medley, Shruthi, Dimitri Glazkov
I think this change sounds fine, and counts as a trivial update to increase compliance/fix bugs.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK-EfXnsPJf9cLKz%3DHKiEq-kjmAQcuudE-i5S%2BWX_5iy5%3DHjFA%40mail.gmail.com.

Reply all
Reply to author
Forward
0 new messages