Re: geolocation update

This looks like it means well and much of it seems good. But "The user
interface must include the URI of the document origin ..." is one of the
stupidest ideas I've heard in a long time. As <
http://www.skyhunter.com/marcs/petnames/IntroPetNames.html> explains, this
is a string chosen by the attacker. Location phishing anyone?


On Sat, Jun 13, 2009 at 2:29 AM, Thomas Roessler <tlr@w3.org> wrote:

> Copying Matt Womer, who serves as Team Contact on the geolocation WG.
>  http://www.w3.org/2008/geolocation/
>
> The TAG had asked for a quick update on the geolocation situation.
>
>
> 1. There was a liaison statement from the IETF concerning priacy and
> security concerns with the geolocation specification.  Part of these
> concerns was the lack of integration of the IETF's geopriv specification.
>
>
> 2. The geopriv specification is mostly motivated by emergency calling use
> cases:  E.g., a DHCP server on a local network indicates where that network
> is physically located, a VOIP device picks up on the location data, and
> might then include the location information as metadata as calls are made.
>  The geopriv specification enables the DHCP server to add basic policy
> information to the location data, in particular whether the location
> information can be forwarded to third parties, and how long it might be
> stored.
>
> You'll notice that the use case is conspicuously different from the
> geolocation API's:  The API is designed to sit right on a trust boundary,
> between the user controlled piece of a browser, and the web application that
> wants to consume the location data.  Therefore, the Working group chose to
> build its security considerations on user authorization:
>
>  User Agents must not send location information to Web sites without the
>> express permission of the user. User Agents must acquire permission through
>> a user interface, unless they have prearranged trust relationships with
>> users, as described below. The user interface must include the URI of the
>> document origin [DOCUMENTORIGIN]. Those permissions that are acquired
>> through the user interface and that are preserved beyond the current
>> browsing session (i.e. beyond the time when the browsing context
>> [BROWSINGCONTEXT] is navigated to another URL) must be revocable and User
>> Agents must respect revoked permissions.
>>
>
>
> There are additional explicit considerations for the recipients of location
> information, which ask for further user consent whenever data are passed on.
>
> In December 2008, the Working Group considered a closer coupling to the
> geopriv WG's design, and rejected it, on the basis that it would require
> user agent implementers to include policy authoring UI (which is known to be
> a chronically difficult problem in user facing situations), in a situation
> in which the Web application in question can actually ask for user consent
> easily and directly (it's a web application, after all!).  Input from the
> geopriv WG was further considered at the W3C device API workshop (also in
> December 2008, actually held in the same room as the WG meeting, just a day
> later).  Among those in the room, there seemed to be relatively little
> interest in picking up on the geopriv WG's design for the purposes of this
> API.
>
> There were numerous other times the proposals were considered as well, both
> off and on-list; most recently last week.
>
>
> 3. Over the last month or so, some in the Team (largely Matt, Rigo and I)
> have reached out to various participants in the IETF, and discussed the
> difference in scenario between the geopriv WG's use cases and the use cases
> that are in scope for the geolocation WG.  Additionally, the WG has sent a
> formal answer to the liaison note, explaining some of the steps above, and
> noting that the WG has decided to not build its specification on the product
> of the geopriv Working Group.
>
> We've also advocated for more extensive security and privacy
> considerations, to cover some situations in which the current specification
> material might lead to insufficient protection (based, e.g., upon user
> error).  The Working Group is apparently going to include some of that
> material in the specification.  We specifically haven't pushed for any
> changes to the API signatures.
>
> The remaining contention is whether to call out relatively specific
> mitigation patterns in the specification; the WG seems disinclined.
>
>
> At this point, I suspect that the place where related architectural issues
> will come up is going to be the device API Working Group.  Issues are likely
> to include what shape and form a policy expression language should take, and
> what deviations from the existing browser security model are acceptable (a
> proposal that might help to mitigate some threat scenarios is to only permit
> "dangerous" APIs from top-level frames)
>
> Hope this helps,
> --
> Thomas Roessler, W3C  <tlr@w3.org>
>
>
>


-- 
   Cheers,
   --MarkM