- From: Doug Turner <doug.turner@gmail.com>
- Date: Wed, 20 May 2009 14:45:45 -0700
- To: Alissa Cooper <acooper@cdt.org>
- Cc: Erik Wilde <dret@berkeley.edu>, public-geolocation@w3.org, Rigo Wenning <rigo@w3.org>
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, 20 May 2009 21:46:44 UTC