Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Specify behaviour for sessionStorage with opaque origins #3283

Closed
Zirro opened this issue Dec 12, 2017 · 3 comments · Fixed by #5560
Closed

Specify behaviour for sessionStorage with opaque origins #3283

Zirro opened this issue Dec 12, 2017 · 3 comments · Fixed by #5560
Labels
good first issue Ideal for someone new to a WHATWG standard or software project interop Implementations are not interoperable with each other topic: storage

Comments

@Zirro
Copy link
Contributor

Zirro commented Dec 12, 2017

The specification for the localStorage attribute currently includes a set of "Storage object initialization steps". Among them is a step for throwing a SecurityError if the Document's origin is an opaque origin.

The sessionStorage attribute does not include similar steps at the moment. When I attempt to access window.sessionStorage on about:blank in Chrome and Safari, they throw a SecurityError much like for localStorage. Firefox throws an internal error (NS_ERROR_NOT_AVAILABLE), while I'm not able to test in Edge.

The sessionStorage attribute should presumably also include a set of "Storage object initalization steps" and behave the same way as localStorage for opaque origins.

@domenic
Copy link
Member

domenic commented Dec 12, 2017

Oh, interesting! I was in that area of the spec recently and I thought this difference was intentional because sessionStorage is not as persistent. But it sounds like either it was an unintentional mistake, or all browsers missed this difference while implementing.

We should fix the spec; even if it is a reasonable and safe to allow sessionStorage, it's not worth the churn on browsers to add a "feature" that is so esoteric.

@inexorabletash
Copy link
Member

FWIW, prompted by https://bugs.chromium.org/p/chromium/issues/detail?id=677733 I did a pass. Safari 12, Firefox 66, Edge 18 and Chrome 73 all throw on access to sessionStorage from an opaque origin. So yeah, let's fix the spec.

Good first PR?

@domenic
Copy link
Member

domenic commented Apr 25, 2019

Yeah, not a trivial one since it involves a bit of monkeying with existing text, but not so bad. The goal is to turn the paragraph

The sessionStorage attribute must return a Storage object associated with the Document's assigned session storage area. Each Document object must have a separate object for its relevant global object's sessionStorage attribute.

into a series of three steps: the first two more or less copied from https://html.spec.whatwg.org/multipage/webstorage.html#storage-object-initialisation-steps, and the third containing the existing contents of the paragraph. You can model it after https://html.spec.whatwg.org/multipage/webstorage.html#storage-object-initialisation-steps , but we probably don't need a separate definition for "Storage object initialization steps" or similar.

@domenic domenic added the good first issue Ideal for someone new to a WHATWG standard or software project label Apr 25, 2019
annevk added a commit that referenced this issue May 18, 2020
This makes use of the new primitives in the Storage Standard.

Closes #3210, closes #3283, closes #4650, and closes #5463.
@annevk annevk mentioned this issue May 18, 2020
3 tasks
annevk added a commit that referenced this issue May 18, 2020
This makes use of the new primitives in the Storage Standard.

Closes #3210, closes #3283, closes #4650, and closes #5463.
annevk added a commit that referenced this issue Jun 5, 2020
This makes use of the new primitives in the Storage Standard.

Closes #3210, closes #3283, closes #4650, and closes #5463.
annevk added a commit that referenced this issue Jul 8, 2020
Use the new primitives in the Storage Standard.

Closes #3209, closes #3210, closes #3283, closes #4650, closes #5463, and closes #5498.
annevk added a commit that referenced this issue Jul 10, 2020
Use the new primitives in the Storage Standard.

Closes #3209, closes #3210, closes #3283, closes #4650, closes #5463, and closes #5498.
mfreed7 pushed a commit to mfreed7/html that referenced this issue Sep 11, 2020
Use the new primitives in the Storage Standard.

Closes whatwg#3209, closes whatwg#3210, closes whatwg#3283, closes whatwg#4650, closes whatwg#5463, and closes whatwg#5498.
mjfroman pushed a commit to mjfroman/moz-libwebrtc-third-party that referenced this issue Oct 14, 2022
whatwg/html#3283 was resolved to change the spec to not
allow access to session storage in opaque origins, matching our implementation.

Bug: 677733
Change-Id: I23da98f166f0845312a0c8ec386d84ac2e3c74f3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2579023
Commit-Queue: Marijn Kruisselbrink <mek@chromium.org>
Commit-Queue: Tom Sepez <tsepez@chromium.org>
Auto-Submit: Marijn Kruisselbrink <mek@chromium.org>
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Cr-Commit-Position: refs/heads/master@{#834818}
GitOrigin-RevId: 0aaf444242e608b9234ebb9dd1244ace3ed0f141
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Ideal for someone new to a WHATWG standard or software project interop Implementations are not interoperable with each other topic: storage
Development

Successfully merging a pull request may close this issue.

4 participants