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

[Ben Laurie]

On Fri, Oct 30, 2009 at 1:05 AM, Mark Seaborn <mrs at mythic-beasts.com> 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)
>
> 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.

The idea was to also show a global indicator so it is clear that some
page is getting geolocation.

>
>
> 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
>
>
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
>
>