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

Re: [minutes] 20101110 Web Performance Working Group

From: James Simonsen <simonjam@chromium.org>
Date: Mon, 15 Nov 2010 04:38:08 -0800
Message-ID: <AANLkTi=Y1u=zXDOBrxF54vKPh8JjydAsBqZ5vQ4NJxeZ@mail.gmail.com>
To: public-web-perf@w3.org
On Fri, Nov 12, 2010 at 1:08 AM, Sigbjørn Vik <sigbjorn@opera.com> wrote:

> On Thu, 11 Nov 2010 20:04:26 +0100, James Simonsen <simonjam@chromium.org>
> wrote:
> How hosting services deal with these potential subdomain attacks is beyond
>> the scope of Navigation Timing. I'm sure all of the hosting services have
>> security teams dedicated to addressing these issues.
>> It's clear that many hosting sites, like the blog hosting and app hosting
>> sites, use subdomains to indicate different owners.
> It is also clear that many hosting sites, like my.opera and facebook (both
> high profile sites), use paths to indicate different owners. Substitute
> "subdomain" with "path" in your argument, and the conclusion that follows is
> that we cannot expose navigation timing when navigating across paths on the
> same domain. That conclusion doesn't make any sense, which shows the
> argument should not be trusted.
> That means that when we
>> cross subdomains, we can't assume that the two pages have the same owner.
>> The unload information is only relevant to the previous page. Likewise,
>> redirect timing is really only relevant to the site that caused the
>> redirect. It's only because of implementation difficulty that we're
>> including that information in the destination page's timing. If we can't
>> be
>> confident that the information is getting back to the previous page's
>> owner,
>> we shouldn't expose it.
> Anything we expose might end up in the wrong hands, whether it is across
> subdomains, paths, or resources. My point is that we need to take a
> pragmatic approach. If we want to take the approach of guaranteed
> theoretical security, the only conclusion possible is that we need to drop
> redirection and unload information entirely.
> I take it you are supporting sharing this information across paths on the
> same domain, thus that you are taking a pragmatic approach. I suggest we
> stick with a single approach all the way through, thus evaluating the
> possible impact our decisions have. I maintain that the possible impact,
> both on cross-path and cross-subdomain sharing is very small, though
> existant for both of them. Do you want 0 risk, or a risk balanced against
> the use cases?
> If the latter, 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.

Received on Monday, 15 November 2010 12:38:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:29 UTC