Re: [minutes] 20101110 Web Performance Working Group

On Thu, Nov 11, 2010 at 1:23 AM, Sigbjørn Vik <sigbjorn@opera.com> wrote:

> On Thu, 11 Nov 2010 02:35:53 +0100, James Simonsen <simonjam@chromium.org>
> wrote:
>
>  On Wed, Nov 10, 2010 at 10:17 AM, Anderson Quach <aquach@microsoft.com
>> >wrote:
>>
>>>
>>> AndersonQuach: We agree to Private Domain, great.
>>>
>>>
>> Sorry for the late follow up, but I think we should revisit this.
>>
>> Regarding option #3 (private domains), I think we need to factor in the
>> rise
>> of cloud computing services, like amazonaws.com and appspot.com. These
>> sites
>> rely on using different subdomains for security
>>
>
> I don't think hosting on subdomains is anything new.
>
> Note that using different subdomains does not provide proper security,
> mainly because cookies can be shared. Partly also because domain
> highlighting might not highlight the subdomain, and allows for easy
> spoofing. E.g. browser IDN rules are also typically different for private
> domains and subdomains, which transfers responsibility for avoiding
> lookalikes among the domain names to the host, and such domains might also
> be sorted in the browser as belonging together. The conclusion is that while
> using subdomains might be practical and partly sandbox the contents, it is
> not a solution to properly secure the contents. Trying to do so already
> leads to a host of subtle issues.
>
> For these two domains in particular, skimming through them, subdomains on
> both of them seem to host public content, and offer no logins. In which case
> there isn't any private information to be leaked. In order for there to be
> private information, there need to be some kind of identification/login, in
> which case there most likely will be cookies. If there are cookies involved,
> the subdomains most likely have security issues, dwarfing any privacy
> issues. I also find no high profile sites on the two domains, and don't
> expect that to change in the future.
>
> Serious webmasters would likely get their own domain, and for the use cases
> I might have missed it is possible for the owner of a private domain to add
> it to the pubsuffix list as a public domain.
>
>
>  The unload information is entirely based on the content of the previous
>> page. Therefore, it should only be available to the previous page's owner.
>>
>> Likewise, if the previous subdomain issues a bunch of redirects before
>> sending the user to a new subdomain, those redirects are only relevant to
>> the previous subdomain's owner.
>>
>
> We can never be certain if the owner of two different resources is the
> same, even in the same folder on the same domain. What I am claiming is that
> even in the worst case, sharing across the private domain isn't all that
> bad, and that if the owners of two subdomains are different, they (and
> users) likely don't care about any potential leakage, in the same way we
> don't care about any leakage between resources with different owners on the
> same subdomain.
>
> You are welcome to convince me otherwise, but that would likely best be
> done with real world data, showing subdomain cases where there is a real
> expectation of security, combined with private data, and where the
> performance object would make things less secure. To me, the two examples
> above don't qualify for any one of the three points. Bonus points if it is a
> high profile site.


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. 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.

James