- From: Alissa Cooper <acooper@cdt.org>
- Date: Wed, 10 Jun 2009 15:33:16 -0400
- To: Geolocation Working Group WG <public-geolocation@w3.org>
It doesn't look like this issue ever got added to the tracker, but it seems important enough to have some sort of resolution before LC. I am still concerned about the scenario where an ad network serves ads through iframes in order to be able to track people's locations across sites based only on a single grant of user permission. It seems prudent to restrict access to the API to top level documents. This restriction could be removed in V2 if discussions with the Device APIs group or with Web Apps result in a consensus that points in the other direction. Alissa On May 21, 2009, at 10:39 PM, Matt Womer wrote: > Hi all, > > [This was: "Additional security and privacy considerations?"] > > I am splitting this thread for maintenance purposes, I'd like to add > it to the tracker and have one easy pointer for others to follow. > If there's no objection, could we continue this discussion on this > thread/subject. If there are no problems with this, I'll add a > tracker item, and I'd also like to solicit feedback from the > (coming) Device APIs group (a mailing list at this point) and from > Web Apps WG. > > -M > > > > On May 21, 2009, at 6:02 PM, Doug Turner wrote: > >> got some feedback on this. this isn't how it works today, but I >> think it is the way it should work in the future. Even more so, I >> have been considering restricting device apis (like geolocation) to >> top level documents only and prevent iframes from accessing this >> APIs. I did get some push back in Dec when I suggested this at our >> w3c devices workshop (are the notes anywhere for this? thomas?). >> This will break many of the sites like igoogle and others that >> embed content from remote origins. However such sites, could use >> something like PostMessage to explicitly send data. >> >> Is this an overkill? Thoughts? >> >> Doug >> >> >> On May 20, 2009, at 2:45 PM, Doug Turner wrote: >> >>> I am not sure if there is any precedent for this. >>> >>> fwiw, in your example, pages containing an iframe will be of a >>> different document origin, UAs will be prompting separately. In >>> other words, if "a" contains the geolocation request, and sites x, >>> y, and z include "a" as a iframe, the user is going to see 3 UI >>> prompts. >>> >>> Doug >>> >>> On May 20, 2009, at 7:09 AM, Alissa Cooper wrote: >>> >>>> Is there precedent in other specs for restricting access to the >>>> parent document? Although it may not become a mainstream >>>> practice, I have a pretty good feeling that once this API gets >>>> out there some service provider or ad network will start using >>>> iframes to track a user's location across different sites based >>>> on a single consent. If there isn't a strong argument for >>>> allowing access from iframes, I think it makes sense to restrict >>>> geolocation to parents. >>>> >>>> Alissa >>>> >>>> On May 18, 2009, at 7:21 PM, Doug Turner wrote: >>>> >>>>> erik, >>>>> >>>>> I am not sure I follow the argument. so, say urchin.js starts >>>>> requesting geolocation. That would mean that _EVERY_ site that >>>>> you visit which uses this script (cnn.com, google,com, espn.com, >>>>> etc) would prompt the user for geolocation. We are basing >>>>> asking for permission on the document's origin -- not some >>>>> script that it loads. >>>>> >>>>> I did suggest before that we may want to consider restricting >>>>> geolocation to parent documents (eg. not allow geolocation >>>>> access from iframes) as a way to mitigate xss and other >>>>> attacks. Is that what you are thinking about here? >>>>> >>>>> Thanks, >>>>> Doug >>>>> >>>>> On May 18, 2009, at 4:08 PM, Erik Wilde wrote: >>>>> >>>>>> hello. >>>>>> >>>>>> Rigo Wenning wrote: >>>>>>> All this can be derived from the requirement to have the >>>>>>> user's consent when acquiring location data as required by two >>>>>>> EU Directives and subsequent transposed national law. As there >>>>>>> is always new data sent over, the legal requirements are not >>>>>>> met with a one time permission for data disclosure for an >>>>>>> unforeseeable future. >>>>>> >>>>>> at the risk of repeating myself, i want to point out to >>>>>> something i sent to the list a while ago. 3rd party trackers >>>>>> are increasingly moving from cookies to javascript. one reason >>>>>> is that 3rd party cookies now can (and sometimes are) blocked >>>>>> by browsers, and browsers have configuration options for that. >>>>>> the other reason is that the information available through >>>>>> scripting is much richer than cookie information. imagine for a >>>>>> second that urchin.js, probably the most widely executed >>>>>> javascript on the web (the code feeding google analytics) >>>>>> starts requesting location information. given the fact how >>>>>> pervasive 3rd party tracking is these days [1], this would mean >>>>>> that iphone users (or any other GPS- or skyhook-enabled phones) >>>>>> would leave an almost perfect location trail from their phones. >>>>>> >>>>>> i think that this is in very different domain than donating my >>>>>> IP address or screen size or browser type to 3rd party >>>>>> trackers. and while i might want to use location features on >>>>>> web sites as soon as they start implementing them, i might not >>>>>> be willing to disclose my location to 3rd parties affiliated >>>>>> with those sites (and many of the popular web sites have an >>>>>> amazing number of affiliated 3rd parties). it seems to me that >>>>>> in case of location, this really is something that needs to be >>>>>> handled carefully, and i am wondering whether the browser of >>>>>> the future will have more "3rd party information disclosure" >>>>>> controls that just "3rd party cookies". >>>>>> >>>>>> kind regards, >>>>>> >>>>>> erik wilde tel:+1-510-6432253 - fax:+1-510-6425814 >>>>>> dret@berkeley.edu - http://dret.net/netdret >>>>>> UC Berkeley - School of Information (ISchool) >>>>>> >>>>>> [1] http://www2009.org/proceedings/pdf/p541.pdf >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >> > > >
Received on Wednesday, 10 June 2009 19:33:58 UTC