Re: Sub-domain granularity: the poverty of the domain name as the only hook for security
Martin Thomson <[email protected]>
| Newsgroups | gmane.org.w3c.tag |
|---|---|
| Message-ID | <CABkgnnVz7kG+CRaq5QDZoWvg+i-AjaC5Oe7fKGuLMsSy-KnAiw@mail.gmail.com> |
On 16 March 2015 at 12:39, Tim Berners-Lee <[email protected]> wrote: > It seems simpler and more powerful to just extend the current origin policy but introduce the '/' as well as the DNS '.' in the hierarchy of origins. Certainly simpler, but how do you plan to deal with legacy content. I guess that the only way you can is to have parent origins disable privileges for children in a declarative fashion. i.e., https://example.com/ can say that https://example.com/foo/ can't have its toys. The inverse causes existing things to break. For a lot of cases, that means you'd need a combination of a blanket down-privilege statement, plus some selective up-privilege clauses. github.com/admin/ has all the rights, but github.com/user/project doesn't. BTW, I don't find the github example especially compelling, because I don't believe that github wants to cede control over project pages entirely, just the public spaces that they (currently) provide on github.io.