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

[Mark Seaborn]

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)

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).

There are several problems here:


1. There might be a clickjacking vulnerability.  e.g. Suppose BobMaps.com
has been granted persistent access to geolocation info by the user.  If an
attacker embeds BobMaps.com in an iframe, can the attacker trick BobMaps.com
into revealing the user's location?  (I need to investigate the browser
changes that were made after clickjacking was publicised.)

The API appears to introduce a new kind of ambient authority.  Tyler Close's
paper on clickjacking [2] argues that the root cause of the problem is use
of ambient authority via cookies.  Tyler argues that sites should use
URLs-as-capabilities instead of cookies so that an attacker cannot guess the
URL of a frame to embed.

Though sites can opt not to use cookies as an implementation strategy, they
can't opt out of using same-origin authorisation for persistent access to
geolocation data.  I suspect DOM storage [3] has a similar issue.


2. According to the spec, the browser UI is required to display the origin
string in its question to the user (section 4.1).

As Mark Miller pointed out [4], this string is chosen by the attacker, so
this could be the subject of location phishing attempts.

If there is only one origin on the page, displaying the origin is
redundant:  it is already displayed in the URL bar.


3. There may be multiple origins per page.

Suppose AliceStores.com embeds BobMaps.com as a way to display a map of
nearby stores based on the user's location.

If BobMaps.com has previously been granted persistent authorisation for
geolocation info, should it be able to use this authorisation when embedded
in AliceStores.com?  Assuming AliceStores does not have a reference to a
user-specific facet of BobMaps, AliceStores would be getting the benefit of
the user's (or BobMaps') ambient authority.

If BobMaps.com has *not* been granted persistent authorisation for
geolocation, should it be able to ask for such authorisation while embedded
in AliceStores.com?  If so, BobMaps is getting a trusted path to the user
without going through AliceStores.  It can acquire greater authority than
AliceStores despite not being distinguishable from AliceStores by the user.
Does this pattern make sense?  Are there parallels with other systems?

Lastly, what happens if there are several origins on the page, all asking
for geolocation info?  Should the browser display all of these requests?  A
simple UI for this request would be a non-modal info bar similar to
Firefox's info bar for saving passwords.  Several origins could result in
several stacked info bars.


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.

I don't see a reliable way of displaying indicator icons for actively-used
persistent grants that is tied to sites.


I'd like to work out what we'd do in the ideal case, to make it clear to the
user what they are authorising, and see if we can adapt that to the API spec
either as it stands or with changes.  Any thoughts?

Mark

[1] http://www.w3.org/TR/geolocation-API/
[2] http://waterken.sourceforge.net/clickjacking/
    - "The Confused Deputy rides again!"
[3] http://en.wikipedia.org/wiki/DOM_storage
[4] http://lists.w3.org/Archives/Public/www-tag/2009Jun/0055.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20091029/ec6dbe12/attachment.html