- From: Larry Masinter <masinter@adobe.com>
- Date: Sat, 15 Aug 2009 13:22:05 -0700
- To: www-archive <www-archive@w3.org>
(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