browser leaks old location data to web pages

[Alan Bell]

visit a web page that requests your current location, for example http://where-am-i.net it prompts to get permission to share the current location, hit allow and it will probably show where you were a few hours ago as the GPS will have a cached location. Refreshing won't update the location, only applications that subscribe to updates cause the GPS to get a new location.

The problem here is that I authorised the web page to know where I am now. I am OK with giving my current position to the web page requesting it. I *didn't* authorise it to know where I was yesterday or this morning, and I might have reasons to not want it to know where my house is, even though I am fine with it knowing where I am right now.

The web browser app should not reveal GPS locations that are older than the decision to allow location to be shared with the page.

[Olivier Tilloy (osomon)]

According to the specification¹, when the 'maximumAge' parameter of a call to getCurrentPosition() is not explicitly set, its value defaults to 0, which instructs the user agent to request a new position, and not return a cached one.

However pages that call getCurrentPosition() with a maximumAge parameter > 0 might get a cached location, without your explicit consent.

That said, I had a look at the code at http://www.where-am-i.net/, and it appears getCurrentPosition() is called without a maximumAge parameter, so it should not disclose a cached location, instead it should always try to get a fresh position.

Assuming this is correctly implemented in chromium (which the browser’s web engine uses under the hood), the issue could be somewhere else in the stack (maybe the location provider returning a stale position with a fresh timestamp?). This is merely a conjecture, more investigation is needed. I’m tentatively adding an ubuntu-location-service task.

¹ https://dev.w3.org/geo/api/spec-source.html#position_options_interface

[Alberto Mardegan (mardy)]

I've been investigating the issue a bit. My understanding of the situation is that Chromium (used by oxide) keeps its own cache for last known location, and that's what it uses when the client plays with the "maximumAge" option; otherwise, it assumes that the location provider always returns new positions. The interface it offers to let developers implement custom location providers (and which oxide uses to implement its QtPositioning-based backend) is this one:

    https://chromium.googlesource.com/chromium/chromium/+/trunk/content/public/browser/location_provider.h

As you can see, it doesn't offer a way to let custom implementations specify a last known position.

Some time ago, I made a change to the location service which makes it always return the last known position as soon as a client starts requesting updates:

    http://bazaar.launchpad.net/~phablet-team/location-service/15.04/revision/204

The plan was to obfuscate that location update and also to decrease its accuracy as it ages (and indeed, not report a position at all if so much time has passed that the user could be anywhere now), but this hasn't been implemented yet.

Also, as this bug report says, we probably should not return a cached position to a client which has just been authorised to use the location service.

[David Barth (dbarth)]

Oxide is normally also pulling updates once permission has been granted:

http://bazaar.launchpad.net/~oxide-developers/oxide/oxide.trunk/view/head:/qt/core/browser/oxide_qt_location_provider.cc#L352

Looking at that part, do you see something that would be at odds with the logic in the other layers of the location stack ?

[David Barth (dbarth)]

To summarize the analysis and the plan forward, we have identified a series of fixes and improvements to various parts of the stack:

Oxide: the ubuntu-specific provider code or related logic could filter out obvious bogus values returned by the location-service which do not meet the maximumAge filter

Location-service: the service API could be extended to support a maximumAge filter parameter

Location-service: in the absence of a maximumAge parameter, the accuracy could be reduced depending on the cached location age; that would help app decide whether to ask for a better location if needed.