browser leaks old location data to web pages

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

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.

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 ?

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.