Re: geolocation update

Bad choice of phrase. I apologize. Too fast on the send button. Please allow
me to substitute "worst ideas".

On Sat, Jun 13, 2009 at 2:21 PM, Mark S. Miller <erights@google.com> wrote:

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



-- 
   Cheers,
   --MarkM