Re: Sub-domain granularity: the poverty of the domain name as the only hook for security

Would you mind clarifying the problems you'd like to address by changing
the origin model?

On Mon, Mar 16, 2015 at 2:28 PM, Tim Berners-Lee <[email protected]> wrote:

> The HSTS spec  http://tools.ietf.org/html/rfc6797 is a good start but it
> is not useful for serious websites which have many separate parts which
> have to have different policies, management, etc.
>

HSTS is, indeed, a sledgehammer. It's really quite good at driving
fence-posts, but less useful for hanging pictures. The per-page suborigins
proposal that WebAppSec has taken up (and that Anne already pointed to)
seems like it might be a reasonable way of adding some granularity. Does it
go in the direction you're interested in?

Similarly the Same Origin Policy in general is very hampering and in that
> it only works at the domain level not at any path level.   It would have
> been not very much harder to set both of them up to work on subtrees within
> the domain, and both would have been much more powerful and useful.  I
> propose they both be fixed in future.
>

Hrm. Cookies take paths into account, and I think they're generally agreed
to be a mess. :)

What properties would you like to be able to share between paths? What
properties do you think should be distinct (and inaccessible)?


> The result of these two has been a pain and many perverse incentives and
> side-effects, for just one example github.com/linkdata having to
> half-move to linkeddata.github.com (which is now a mess and loses
> locality of linking between the two) and
>

How would you propose distinguishing between `github.com/linkeddata` and `
github.com/w3c` (two distinct organiziations, which, I suppose, aren't
same-origin with `github.com/`) on the one hand, and `github.com/blog` on
the other (GitHub's blog, which is theoreticatically same-origin with `
github.com/`)?

Since we're looking at GitHub, note that they migrated to `*.github.io`
(and registered `github.io` as a public suffix) in order to ensure
separation between user pages. In an ideal world, how would they have been
able to handle that use-case?

w3.org not being able to move to HTTPS at all because of being unable to
> apply HTTS path by path.
>

I could understand HSTS being difficult to deploy for the reasons you
outline here. I don't understand how that would prevent path-by-path
migration from HTTP to HTTPS, however. I'd love to see redirects from HTTP
to HTTPS for `www.w3.org/TR/*`, for instance. I'm hopeful that
https://w3c.github.io/webappsec/specs/upgrade/ will help there.

-mike