W3C home > Mailing lists > Public > public-geolocation@w3.org > May 2009

Restricting API access

From: Matt Womer <mdw@w3.org>
Date: Thu, 21 May 2009 22:39:37 -0400
Message-Id: <D63433E9-B86E-4EE5-B855-B52F650871A8@w3.org>
To: Doug Turner <doug.turner@gmail.com>
Cc: Alissa Cooper <acooper@cdt.org>, Erik Wilde <dret@berkeley.edu>, Geolocation Working Group WG <public-geolocation@w3.org>, Rigo Wenning <rigo@w3.org>
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 Friday, 22 May 2009 02:40:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:50:55 UTC