FW: geolocation update

(forwarded with permission to allow public access;
this is Thomas Roessler's August 3 reply to 
my June 20 questions about GeoPriv vs. GeoLocation)

>> -----Original Message-----
>> From: Larry Masinter
>> Sent: Saturday, June 20, 2009 6:07 PM
>> To: 'Thomas Roessler'; 'www-tag@w3.org'
>> Cc: 'Matt Womer'; 'Rigo Wenning'
>> Subject: RE: geolocation update
>>
>> I'm still not clear, even after your message, about how the GeoPriv
>> and GeoLocation use cases are so significantly different.
>>
>> Why would a  "policy authorization interface" be any more difficult
>> for GeoLocation than it is for IETF GeoPriv? And won't almost all
>> the devices supporting GeoLocation APIs also support GeoPriv
>> services? Are there any examples of devices that wouldn't have both?

> For the purpose of this discussion, I'll take "support geopriv" to
> mean that whatever API is used to discover location data will *always*
> return, along with the location data, a flag whether that information
> can be passed on, and how long the data can be kept.
>
> The question at hand, then, is one about the separation of concerns:
> If that information needs to be present, then the analysis would have
> to say that the user agent (or the location sensor?) best deals with
> the user's decisions about secondary use.  The geolocation working
> group came to the result that secondary use is a concern that the web
> application best deals with directly, and that it should therefore not
> be dealt with by the user agent.  That sounds reasonable to me, as it
> pushes interactions about secondary use to the parties that are most
> likely to actually know what's going on.
>
> (I could also imagine circumstances under which that assumption
> doesn't hold -- and the classical geopriv use case of a telephone
> learning its location over the local network sounds like one of these
> cases.)
>
> To your question about UIs:  The difficulty of constructing one will
> depend on the circumstances under which it will be invoked, who will
> use it (expert vs consumer), how often it is expected to be used, and
> so on. In the geolocation case (as designed now), it's likely that
> secondary use can be dealt with in a task and application specific
> way, which is typically a good thing in designing UIs.
>
>> Is the scope of the GeoLocation API explicitly limited to only be
>> applicable to the where they are only ever used for "the user
>> controlled piece of a browser"? I understand that the GeoLocation
>> use cases are more limited,
>
> I don't know whether they are "more limited" -- geopriv seems to be
> making some very specific assumptions about where policy authoring
> best occurs, and (as we see here) these seem not to hold universally,
> either.
>
>> but unless the domain of applicability is clearly limited, shouldn't
>> the security and privacy requirements address all of the likely
>> uses, and not just the scenarios illustrated by use cases?
>
> Your question suggests a dangerously general answer.  Therefore, let
> me just note that one of the reasons for having security
> considerations (!) as opposed to security solutions in many
> specifications is precisely that the details of privacy and security
> aspects will depend on the concrete use case and deployment, and will
> eventually involve judgment.
>
> To the concrete case -- nothing in the design of the geolocation API
> prevents Position objects from acquiring additional attributes.  See
> section 5.3:
>> Future versions of the API may allow additional attributes that
>> provide other information about this position (e.g. street  
>> addresses).
>>
> -- http://www.w3.org/TR/2009/WD-geolocation-API-20090707/#position_interface
>
> Regards,
> --
> Thomas Roessler, W3C  <tlr@w3.org>
>
>
>
>
>
>> Wouldn't the same API also be used for devices and services that are
>> not the "user controlled piece of a browser"?
>>
>> Larry
>> -- 
>> http://larry.masinter.net
>>
>>
>> -----Original Message-----
>> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] On
>> Behalf Of Thomas Roessler
>> Sent: Saturday, June 13, 2009 2:29 AM
>> To: www-tag@w3.org
>> Cc: Matt Womer; Rigo Wenning
>> Subject: geolocation update
>>
>> 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>
>>
>>
>

Received on Saturday, 15 August 2009 20:22:45 UTC