Re: Restricting API access

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 13:35:08 UTC