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

Re: Restricting API access

From: Doug Turner <doug.turner@gmail.com>
Date: Mon, 15 Jun 2009 08:44:33 -0700
Cc: Geolocation Working Group WG <public-geolocation@w3.org>
Message-Id: <6E2ECE80-3E08-4787-BC7A-0AD170FBD23F@gmail.com>
To: Alissa Cooper <acooper@cdt.org>
Hey Alissa,

Mobile Safari (Greg can confirm), Google Gears (including Android),  
and Firefox 3.5 do not restrict device apis to TLD -- IFRAMEs are  
allowed to access each geolocation.  I suggested we consider  
restricting these sorts of APIs at the Device Security Workgroup back  
in December.  It was more of a strawman position I took to get  
feedback, and much of the feedback was considerations around what we  
would break.

Doug

On Jun 15, 2009, at 6:34 AM, Alissa Cooper wrote:

> I am still unclear on the status of the issue below. If some  
> decision has been made, could it be posted to the list?
>
> Thanks,
> Alissa
>
> On Jun 10, 2009, at 3:33 PM, Alissa Cooper wrote:
>
>> 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 Monday, 15 June 2009 15:46:37 UTC

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