W3C home > Mailing lists > Public > public-web-perf@w3.org > October 2010

Re: [Open Issue] Privacy concern with Navigation Timing

From: Sigbjørn Vik <sigbjorn@opera.com>
Date: Fri, 22 Oct 2010 10:38:01 +0200
To: public-web-perf@w3.org
Message-ID: <op.vkyx9nuc41y844@id-c0735.oslo.opera.com>
On Fri, 22 Oct 2010 09:59:07 +0200, Zhiheng Wang <zhihengw@google.com>  
wrote:

> On Fri, Oct 22, 2010 at 12:29 AM, Sigbjørn Vik <sigbjorn@opera.com>  
> wrote:
>
>> My thought is that using a cookie domain will be of great benefit to
>> developers, and that it has little real-life negative impact on  
>> websites. Do
>> you foresee any practical problems doing this?
>>
>    Different sub-domain is only part of the story.
> Origin<http://www.w3.org/TR/html5/origin-0.html> refers
> to (schem, host, port), so different ports and schemes could be potential
> risk as well.

True, conceptually and security wise, we can consider them as subdomains  
to make things easier.

> It's a good point that they are sharing the same cookie already, so the
> additional negative impact by relaxing the SOP is at most incremental.

Note that cookies can be shared, but that does not happen automatically,  
and it is possible to take extra care to create safe cookies even on such  
a subdomain (some extra code is needed). It is not possible to have safe  
cookies across ports though, and only in one direction between schemes  
(using the secure flag). So cookies are somewhat more safe than Timing  
information would be, but also carry a lot more information.

>    I actually have a bit more thought after the previous email... The SOP
> doesn't seem to guarantee absolute safety either, e.g., some web services
> are already hosting UGC on the same domain but a user-specific path like
> some.domain.com/mystuff. Arguably though, some.domain.com *should*
> cover any potential security issues.

This model is typically used to separate documents, not web applications.  
The User Generated Content is typically limited to whitelisted HTML and  
CSS, rarely server side scripting. Universities and companies often use  
this model too, and sometimes do allow scripting - though such accounts  
are rarely used for full fledged applications. Cookies has a security  
model for this too, though practically unused in the wild.

>    Don't make me wrong. Cookie domain is also my favorite and I tend to
> agree that its benefit is greater than other concerns. :-) I just feel  
> like bringing
> up the point for discussion. And if we all agree on using the cookie  
> domain,
> we will go with it.

Agreed, this would need explicit approval from all before deciding for it.
In some ways, deciding to use cookie domain is equivalent to taking the  
another step towards declaring that "For Web applications to get full  
security from browsers, they need to run in a trusted cookie domain."  
Browsers have already taken several steps towards this apart from cookies  
and document.domain, the cookie domain might be highlighted in the address  
bar and domain sorting in lists might be based on the cookie domain.

-- 
Sigbjørn Vik
Quality Assurance
Opera Software
Received on Friday, 22 October 2010 08:38:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 21 December 2010 18:13:55 GMT