I would prefer we try to ban these since they are synchronous I/O and should have no place on the platform.

I'll let @devd and @arturjanc comment, but we've already seen issues with converting applications to sandbox and Suborigins that makes banning them impractical. I also don't particular think Suborigins is the right place to deprecate APIs because we don't like their design, but that's more of a philosophical point.

Since suborigins are explicitly designed for "old code not trusted", it seems weird to force "this is how the future should look like" in suborigins. Sorry! I agree we want to kill these, but I don't think this is the place.

+1 to @devd / @metromoxie, I think we should maintain "feature parity" with non-suborigin contexts. Any time suborigins take something away we reduce the number of applications which can adopt them, and in the end reduce their security value.

FWIW I also like option 3; suborigins could be presented very similarly to subdomains in most UIs.

@devd well, now you're putting an additional tax on everyone implementing these APIs by making them more complicated.

My general thinking is that I am ok removing all the other synchronous APIs if we can keep localStorage or one such synchronous API around. Otherwise it becomes really painful to fake these.

Treat Suborigins as a new origin with their own localStorage and sessionStorage. Good because it is probably the easiest to transfer applications to, but tough because it would be difficult to figure out how to best present this to users, especially in UX.

Please do this option. Using sessionStorage is very useful in our case for communicating between multiple iframes in the same suborigin. It allows a nice secure channel of communication where one does not need handles of other iframes, or postmessage over the main origin.

I do not see really a reason why each suborigin would not simply get their own copy of localStorage and sessionStorage?

@jeisinger does the current implementation support localStorage in suborigins?

Yes: https://arturjanc.com/cgi-bin/suborigin-testing/localstorage.py (obviously still needs the Experimental Web Platform features flag set in Chrome).

fwiw, we separate all storage mechanisms by suborigin, so I guess it's fine to close this one

FWIW, it's unclear to me that changing the meaning of "origin" is the way to go. While more work, it seems better to change "origin" to "suborigin" (or some such) where needed and add the relevant tests for each case. That ensures we covered all ground and implementations won't miss anything.

Changing the meaning of an existing well understood concept was also tried with shadow DOM and it took years to sort it through.

hey Anne! Sorry; I don't understand the concern you are referencing. Do you mind flagging the issue more explicitly? I am sure you are right but just trying to understand the concern more clearly.

The concern is that we have a lot of standards prose branching on origin. Rather than changing how that works without going through it all, it seems better to explicitly change the prose that needs to branch on suborigins instead.

So instead of saying "this should be physical origin" we say "this should be suborigin".

aah ok. I think that's fine: per Jochen's note, that's what chrome does (tie storage to suborigins). Is there a particular wording change somewhere in the suborigin spec that you are alluding to? Or is this in the html spec?

If we go the way I suggest we'd have to change HTML for localStorage/sessionStorage (and every other feature that becomes suborigin rather than origin-bound).

With respect to OP I think we are concluded that localStorage and sessionStorage get their own double-keyed area, just like Indexed DB and others. How to make sure this is carefully defined is still a bit up in the air.

(To the question whether this generalizes to Origin Isolation, I don't think it should. It would make transitioning an origin to be isolated harder for marginal benefit when transitioning to isolated origins.

cc @estark37)