Plan for isolating storage

[jonathanKingston]

The current draft mentions isolating local/session storage and also cookies. Will these be added?

• [ ] Plugins (if such a thing exists in the future)
• [ ] IndexDB
• [ ] Browser cache & Cache API

Points to consider:

• Could the language of 'Storage model' section be written in such a way that extending to new storage mechanisms don't need whole new sections. Eg: 4.2.2.1. localStorage, 4.2.2.2. sessionStorage
  • For example if the isolated boolean becomes part of origin specified here https://html.spec.whatwg.org/multipage/browsers.html#origin such that all new APIs/fetch would need to cope with checking for isolated.
• If the draft can't be made extensible to all future APIs could the draft enumerate APIs in a permissive manner in such a way that new APIs don't break out of the isolation?
• The draft doesn't(at first quick read through) cover XSS exploits in example.com exfiltrating data to evil.com. Perhaps this is out of scope and should just be covered by CSP. Either way it should probably be mentioned in threat models/security considerations.

[estark37]

Hmm. I was really hoping to avoid modifying the definition of origins, but it might be inevitable.

We could follow the suborigins model; however, my concern is that origin serialization is not really extensible (https://html.spec.whatwg.org/multipage/browsers.html#ascii-serialisation-of-an-origin). Suborigins serialize into the host component of an origin, with a suffix on the scheme to indicate that a suborigin is present. It's not easy to extend that to an isolated origin... plus, isolation is even more complicated because we'd have to encode a whole other origin in the serialization. (That is, if https://embedded.com is embedded in https://isolated.com, the serialized origin for embedded.com has to somehow encode the fact that it is embedded in the isolated origin https://isolated.com.)

cc @mikewest @tanvihacks

[estark37]

On second thought, maybe we don't really need to encode isolation info into an origin serialization. My vague understanding is that suborigins needed to serialize in order for postMessage to work. But in this case we don't really need isolation info in postMessage origins because nothing inside an isolated origin should be able to postMessage outside and vice versa.

Maybe @metromoxie or @devd can elaborate a little more on suborigin serialization. If postMessage didn't exist, would suborigins need to have a special serialization?

[devd]

For CORS too, right? Unless we want to make the origin header null in that case and use a new suborigin header.

[estark37]

Ah, right, CORS!

I think an isolated origin serialization isn't necessary for CORS; a server doesn't need to distinguish requests coming from an isolated context because the cookies will already be separated.

[devd]

Well, a server might use origin for auth and ignore cookies.

[estark37]

Eh? Can you explain that more?

[devd]

[chatted offline but we are still figuring out if this applies to isolate me]