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

Re: Options for same-origin definition for Navigation Timing

From: Sigbjørn Vik <sigbjorn@opera.com>
Date: Fri, 05 Nov 2010 17:03:20 +0100
To: public-web-perf@w3.org
Message-ID: <op.vlpf7u1k41y844@id-c0735.oslo.opera.com>
On Thu, 04 Nov 2010 23:11:30 +0100, Nic Jansma <njansma@microsoft.com>  
wrote:

> Hi everyone,
>
> We have several options for how we can define same-origin for the  
> purposes of the NavigationTiming interface.  I have listed out 4 of  
> these options, along with their advantages/disadvantages and examples  
> below.

Thanks for the nice overview.

I agree that both 2 (document.domain) and 4 (CORS) are complex to  
implement (which will mean lots of bugs, and differences in how browsers  
behave), and both are affecting the security of things unrelated to Timing  
(which will mean lots of obscure security holes in sites). Further #4  
(CORS) needs to add network headers to measure the performance, thus  
changing the performance by measuring it, which might not be what web  
developers want.

For the sake of completeness, #2 (document.domain) have the exact same  
caveats as #3 (private domain) when it comes to the correctness of the  
implementation, as document.domain will/should throw a security exception  
if attempting to set it to a public suffix: "Current public suffix list  
implementations are either heuristics or based on maintained lists, which  
cannot be quickly updated, and are not perfect."

I think the best solution is to go for #3 (private domain), if not #1  
(fqdn) as the other option. I am not in favour of either document.domain  
or CORS. To comment on the listed disadvantages for #3.

> Loosest definition of same-origin.
For Web developers this is good.
For users, in the case of no shared domain: No effect
For users, in the case of shared domains: This is point three below

I'd be tempted to put this as an advantage instead ;)

> Current public suffix list implementations are either heuristics or  
> based on maintained lists, which cannot be quickly updated, and are not  
> perfect.
Current public suffix list implementations are what browsers use for  
cookies today. Though not theoretically perfect, they are already in heavy  
use, absolutely essential for for every single user, and working  
flawlessly.

> Would allow different-owner sites of subdomains such as a.blogspot.com  
> to get data about b.blogspot.com, with no way for b.blogspot.com to  
> restrict access.

I claim that this is not an issue in practice. I also claim that we will  
not be able to find any sites for which this is a real issue, even if we  
look hard. For blogspot.com, it is not an issue.
* Such sites have much worse cookie problems already, as the cookies may  
be shared[1]
* High profile sites (which are the typical target sites of attacks) do  
not share their domain with someone else.
* Such sites tend to fall into one of two categories:
** Shared login (as for blogspot), scripting disabled (if scripting is  
enabled, timing attacks are not the concern)
** Completely different sites (as for dyndns.org), low profile, few  
users[2], not sensitive data (except for possibly private data behind a  
login form[3])
* The potential privacy leak for the user is small, both in data, and  
possible places it can leak to
* Sites which think this might be an issue, can do something about it, by  
getting their own private domain or by getting an entry on the pubsuffix  
list (as for operaunite.com).

[1] Which, though being much worse, has never been an issue, I'd be  
surprised if anyone could even point to a writeup on the Web about the  
issues and how to work around them.
[2] Timing attacks are mostly useless if directed at particular users, in  
order to direct it, one needs to know more about the user than one would  
obtain.
[3] Private data behind a login form would typically suffer from the much  
worse cookie problems

-- 
Sigbjørn Vik
Quality Assurance
Opera Software
Received on Friday, 5 November 2010 16:03:30 GMT

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