RE: [minutes] 20101110 Web Performance Working Group

This is a great discussion! We are all conscious about security and the potential implications of a design decision such the one being discussed in this thread. Landing the appropriate trade-offs is key. We want to make sure that we have safe defaults and also a useful API.

There are two main goals in mind:
.	Mitigate concerns of end-user information disclosure.
.	Maximize ease of use and value to web developers.

In 11/10/2010's meeting [1] as a working group we came to the decision to use the Private Domain as the origin as a means to define when we expose navigationStart, redirectStart, redirectEnd, unloadEventStart, unloadEventEnd and redirectCount. This decision really struck the balance with respect to the two goals. Currently, there is precedence with Private Domains having a trust relationship with their subdomains as seen in examples of cookies and in HTML5's quota for Web Storage [2]. Additionally, the value of the timing information is relatively low when compared to things already shared in Private Domains like cookies, compatibility lists, zones and etc. 

As a thought experiment, going with the FQDN definition of origin, the timings mentioned would be zeroed out and not easily accessible by web developers in cases where they want to access the time taken to perform a logon or some server-side redirects when accessing the root document. If a web-developer wanted to gain access to navigationStart, they would have to put forth effort to implement a solution that may have performance side-effects, such as leveraging the onunload or onbeforeunload handler to transmit a beacon or storing timestamps in cookies prior to transitioning to the new page. 

Nic and I recommend that we continue forward with the decision we had made as a Working Group on 11/10/2010.

[1] http://www.w3.org/2010/11/10-webperf-minutes.html 
[2] http://www.w3.org/TR/2009/WD-webstorage-20090423/#disk-space 

Thanks,
Anderson and Nic

-----Original Message-----
From: public-web-perf-request@w3.org [mailto:public-web-perf-request@w3.org] On Behalf Of Sigbjørn Vik
Sent: Monday, November 15, 2010 5:46 AM
To: public-web-perf@w3.org
Subject: Re: [minutes] 20101110 Web Performance Working Group

On Mon, 15 Nov 2010 13:38:08 +0100, James Simonsen <simonjam@chromium.org>
wrote:

> On Fri, Nov 12, 2010 at 1:08 AM, Sigbjørn Vik <sigbjorn@opera.com> wrote:

>> I'd like to understand why you think the line in the sand should be 
>> drawn exactly between path and subdomain, rather than between 
>> subdomain and domain.
>
> Particularly with app hosting services, people are paying to have 
> their sites hosted. There's a real expectation that their content is 
> being protected by the app hosting service. These services have chosen 
> subdomains to separate their customers content. That's a good 
> indication that we should follow suit.
>
> More generally, many hosting services now use subdomains instead of 
> separate paths. Previously, people would use a service like Geocities 
> or their ISP to host a site in their own path. Now, even simple sites 
> like blogs, are hosted on sites like wordpress or blogspot, which use 
> subdomains.
>
> We do have to be pragmatic, but isolating timing data from separate 
> subdomains is most in line with how content is hosted.

I don't have any intention of dragging this out. I don't seem able to convince you otherwise, and I haven't seen any arguments from you to convince me, nor any examples of pages where timing information would be an issue. Let's just agree that there are strong opinions both ways, consensus is unreachable, and settle for a majority decision after the arguments have been exhausted.

To reply to the above:
In general, people who pay will buy their own domain. People who use free services to share content, typically do so to distribute and publisize the content, not to protect it. If they get scripting access to the subdomain, then the hosting provider cannot fulfill such requirements/expectations for protection in any case (due to cookies, etc), so if such expectations exist they are false. I'd also claim that most content on subdomains belong to the same site, and thus that sharing, not isolating, timing information would be most in line with current content hosting[1].  
Disregarding all of that, I still don't see how timing information becomes a problem.

And most importantly, I think it is extremely useful for Web developers to be able to get timing data on their entire site, even though it is spread out over several subdomains (which is very common, even called best practices these days).

[1] Even the top hits for the two domains you mention use subdomains to host inline elements of their top pages. wordpress.com loads inlines from files.wordpress.com, and googleblog.blogspot.com loads inlines from bp.blogspot.com. I think sharing timing information on those domains would be beneficial, and I have stil not seen any subdomains which would suffer the slightest.

--
Sigbjørn Vik
Quality Assurance
Opera Software

Received on Thursday, 18 November 2010 19:38:11 UTC