search

w3c / webappsec-suborigins

Suborigins
https://w3c.github.io/webappsec-suborigins/
Other
25 stars 9 forks source link

Use path prefixes instead? #64

Open hlandau opened 7 years ago

hlandau commented 7 years ago

Suborigins are a nice idea.

The current spec has a number of problems. Since different resources can have suborigins assigned to them arbitrarily, all requests from JS have to use CORS, etc.

If suborigins were required to be path prefixes, user agents could reason about what resources are inside and outside of the current suborigin without additional network communication. This is a property of the current origin system, and preserving it is desirable.

This would also allow support for history.pushState to be defined, as it could be immediately determined whether a history change would result in a change outside of the current suborigin.

Essentially:

Suborigin: /foo would contain https://example.com/foo, https://example.com/foo/, https://example.com/foo/bar, etc.

There would need to be a rule that no suborigin name may form a prefix of another suborigin name issued under the same origin. It would be the responsibility of the origin to ensure that the set of suborigins it issues is prefix-free. If this rule is violated, suborigin /foo might erroneously assume that https://example.com/foo/bar is part of the same suborigin.

It would be interesting to know if the above proposal damages the utility of the suborigins proposal for any identified use cases.

mozfreddyb commented 7 years ago

This comment is somewhat off topic, but you reminded me of the paper Beware of finer grained origins by Collin Jackson and Adam Barth.

devd commented 7 years ago

exactly.

Instead of requiring suborigins to be path prefixes, I think I can see the value of a site being able to say "all URIs in this path prefix will always be this suborigin" via a site wide policy or a .well-known-uri. But this is all too far out for v1. Lets ship something simple and usable in v1.

annevk commented 7 years ago

The main compelling argument I've heard against this is that sometimes you might want to generate a suborigin per resource, e.g., for email attachments.

Having a central registry might also complicate deployment of new applications or result in accidentally including resources in a suborigin (such as robots.txt) that have no place being there.

The main advantage seems to be that you can maybe segment cookies further, but typically you don't want the user to have to login again within a single origin so that doesn't apply.

pushState() doesn't seem problematic as invoking it won't change the suborigin of the document. And if it could that would actually be a security bug, not a feature.

So I guess I'm coming around to the fact that this is not a good idea, in aggregate.