New issue
Advanced search Search tips

Issue 821948 link

Starred by 2 users

Issue metadata

Status: Assigned
Owner:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac
Pri: 3
Type: Feature



Sign in to add a comment

Geolocation: consider spoofing age of network location estimates

Project Member Reported by mattreynolds@chromium.org, Mar 14 2018

Issue description

Due to recent changes:

* Chrome is now stricter about disallowing network location requests when it would cause us to perform a wifi scan more frequently than once every 10 minutes.
* Chrome is also stricter about not returning position estimates when the age of the estimate is greater than the maximumAge option.

For the common case of a stationary desktop or laptop with the network location provider as the primary source of location estimates, this means that getCurrentPosition may fail to acquire a fresh position estimate for up to 10 minutes. Callers must set an appropriate maximumAge threshold to receive the most recent estimate.


Example:

getCurrentPosition(successCb, errorCb, {})

With default options (timeout:0xffffffff, maximumAge:0), successCb is called with a fresh position estimate after a considerable delay (up to 10 minutes)

getCurrentPosition(successCb, errorCb, { maximumAge:600000 })

Setting maximumAge to a minimum of 10 minutes ensures successCb is called immediately with the most recent cached estimate, if there is one. If not, it will immediately begin the process to request a new estimate.


Most users of this API are not aware of this issue and may expect network location estimates to be more reliably available. This bug represents a proposal to improve this use case.

The first time position is requested, Chrome scans for nearby wifi APs and sends the set of nearby MAC addresses to a Google service, which returns a position estimate. The wifi scan is performed every 10 seconds as long as the results of each new scan are significantly different from the previous scan. If we get substantially the same results, Chrome backs off and uses a longer interval between scans. On most devices this backoff is 10 sec -> 2 min -> 10 min.

The use of the longest interval indicates that Chrome thinks the device is stationary (at least, relative to nearby wifi APs). We could use this as a signal that it's acceptable to treat the stale network estimate as if it was a fresh estimate. (Alternately, we could spoof it with a recent-but-not-quite-fresh age to allow these estimates to be excluded with maximumAge:0)
 
Owner: mattreynolds@chromium.org
Status: Assigned (was: Untriaged)

Comment 2 by jph...@gmail.com, Mar 23 2018

In my testing this seems to be inaccurate across page refreshes:

"Setting maximumAge to a minimum of 10 minutes ensures successCb is called immediately with the most recent cached estimate, if there is one. If not, it will immediately begin the process to request a new estimate"

I am on Chrome 65.0.3325.181, on a stationary Mac 10.13.3 laptop.  I am running the following code in the javascript console on a blank tab:

navigator.geolocation.getCurrentPosition(function() {console.log('success')}, function() {console.log('error')}, { maximumAge:600000 })

I am then refreshing the page, and running the same code, and am not seeing any output in the console for up to 10 minutes.

So effectively, the maximumAge parameter seems to be ignored once a user refreshes the page or opens a different tab.  So this issue is more serious than "Callers must set an appropriate maximumAge threshold to receive the most recent estimate", since setting the maximumAge parameter is not an effective workaround.

Sign in to add a comment