[cap-talk] Ambient authority in the Web Geolocation API

[David-Sarah Hopwood]

Mark Seaborn wrote:
> I am investigating how to design a browser UI for the Web Geolocation API
> [1].
> 
> The spec proposes an API that lets Javascript ask for the user's current
> location (obtained from GPS or WiFi devices).  The browser is expected to
> ask the user whether to return this information.  The user might have a
> choice between:
> 
>  * granting the current location once
>  * granting access to the location, as it changes, while the page is open
>  * granting access persistently (either indefinitely or for a period of
> time)

This is too complicated. Simplify by only allowing one option (the second
one).

> The complication is that this is supposed to be done using a same-origin
> policy, and there might be multiple origins on the page if the page uses
> frames (including iframes).

Dependence on the same-origin policy should be minimized for all new APIs.
It's just too broken.

To the extent that users can determine the principal associated with a
page/tab, they can at best do so for the top-level frame (the one that
was originally loaded from the URL shown in the address bar). It is up to
the principal controlling that frame to either avoid displaying other
content that it does not want to be associated with, or to do so in a way
that makes it visually apparent that it is third-party content.

So, only a top-level frame should be able to request geolocation data.
If it does, the browser shows a non-modal confirmation bar, like the
pop-up bar, which asks the user whether they want to grant access. If they
do, then the bar updates to say something like "This page can see your
current location", with an option to revoke access. The bar remains
visible for as long as the geolocation is being updated for that frame.
(It could be updated by calling an event handler registered by the frame,
for example.)

Switching away from a tab automatically revokes geolocation access; to
reenable it, the user has to switch back to that tab *and* click to allow
it again.

There is *no* persistence across sessions. Privacy is absolutely critical
here; it overrides the usability cost of one extra click each time you
want to use a geolocation app.

> 4. Indicator icons for review and revocation.
> 
> Some people have suggested that the browser could display an icon (perhaps
> in the URL bar) to indicate when the currently-displayed site has been
> granted geolocation access.  The intent is for this to act as a reminder to
> the user that their location is (or could be) being disclosed if this is the
> result of a persistent authorisation that they have forgotten about.
> 
> This icon might be a useful indicator for single-origin pages, but it falls
> down for multi-origin pages.  A new iframe for a previously-authorised
> origin could be added to a page at any time, without user action, while a
> tab is in the background.  So a page, when opened, may appear not to have
> geolocation access initially, but it might acquire it (via a new iframe)
> while in the background, after a delay.

This isn't possible in the design I sketched above.

A remaining potential security vulnerability is that if there is an XSS
attack on a site that the user trusts with their geolocation, then the
geolocation could be accessible to the attacker. This is a bug in the
site, and I don't see anything that the browser can do about it other
than features that are helpful against XSS in general (such as a
"secure iframe" feature).

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com