This repository has been archived by the owner on Dec 12, 2020. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 11
API concerns for originIsolationRestricted #31
Comments
3 tasks
@annevk and I do not have strong opinions about the edge cases here. (IRC log.) None of them are important for the actual use cases listed in #24, where it would be used in the wild to check if the header had an effect. Since it sounds like you do have strong opinions, we're happy to change to your preferred (1). My suggestion for naming if we change to (1) is |
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Jun 25, 2020
See WICG/origin-agent-cluster#24 and WICG/origin-agent-cluster#30 for background, and whatwg/html#5545 for the specification. Failing test expectations include: - We implement (3) from WICG/origin-agent-cluster#24 instead of (2) for now, so we fail getter-sandboxed-iframe. Tracking at https://crbug.com/1095653. - The initial about:blank, as well as removed iframes, are not properly returning true, so about-blank and removing-iframes are failing. Also tracking at https://crbug.com/1095653. - data: URLs are not [SecureContext] in Chromium (https://crbug.com/1095656) so getter-data-url fails. Note that per ongoing discussion in WICG/origin-agent-cluster#31 the naming of this API, as well as its edge-case behavior (e.g. for sandboxed iframes) will likely change. Bug: 1042415 Change-Id: I20c2d3e3fec7a5c0f1d12c386999c32fe27b6a34
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Jun 25, 2020
See WICG/origin-agent-cluster#24 and WICG/origin-agent-cluster#30 for background, and whatwg/html#5545 for the specification. Failing test expectations include: - We implement (3) from WICG/origin-agent-cluster#24 instead of (2) for now, so we fail getter-sandboxed-iframe. Tracking at https://crbug.com/1095653. - The initial about:blank, as well as removed iframes, are not properly returning true, so about-blank and removing-iframes are failing. Also tracking at https://crbug.com/1095653. - data: URLs are not [SecureContext] in Chromium (https://crbug.com/1095656) so getter-data-url fails. Note that per ongoing discussion in WICG/origin-agent-cluster#31 the naming of this API, as well as its edge-case behavior (e.g. for sandboxed iframes) will likely change. Bug: 1042415 Change-Id: I20c2d3e3fec7a5c0f1d12c386999c32fe27b6a34 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2243994 Reviewed-by: Charlie Reis <[email protected]> Reviewed-by: Daniel Cheng <[email protected]> Reviewed-by: James MacLean <[email protected]> Commit-Queue: Domenic Denicola <[email protected]> Cr-Commit-Position: refs/heads/master@{#782672}
pull bot
pushed a commit
to Alan-love/chromium
that referenced
this issue
Jun 26, 2020
See WICG/origin-agent-cluster#24 and WICG/origin-agent-cluster#30 for background, and whatwg/html#5545 for the specification. Failing test expectations include: - We implement (3) from WICG/origin-agent-cluster#24 instead of (2) for now, so we fail getter-sandboxed-iframe. Tracking at https://crbug.com/1095653. - The initial about:blank, as well as removed iframes, are not properly returning true, so about-blank and removing-iframes are failing. Also tracking at https://crbug.com/1095653. - data: URLs are not [SecureContext] in Chromium (https://crbug.com/1095656) so getter-data-url fails. Note that per ongoing discussion in WICG/origin-agent-cluster#31 the naming of this API, as well as its edge-case behavior (e.g. for sandboxed iframes) will likely change. Bug: 1042415 Change-Id: I20c2d3e3fec7a5c0f1d12c386999c32fe27b6a34 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2243994 Reviewed-by: Charlie Reis <[email protected]> Reviewed-by: Daniel Cheng <[email protected]> Reviewed-by: James MacLean <[email protected]> Commit-Queue: Domenic Denicola <[email protected]> Cr-Commit-Position: refs/heads/master@{#782672}
Hexcles
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Jun 26, 2020
See WICG/origin-agent-cluster#24 and WICG/origin-agent-cluster#30 for background, and whatwg/html#5545 for the specification. Failing test expectations include: - We implement (3) from WICG/origin-agent-cluster#24 instead of (2) for now, so we fail getter-sandboxed-iframe. Tracking at https://crbug.com/1095653. - The initial about:blank, as well as removed iframes, are not properly returning true, so about-blank and removing-iframes are failing. Also tracking at https://crbug.com/1095653. - data: URLs are not [SecureContext] in Chromium (https://crbug.com/1095656) so getter-data-url fails. Note that per ongoing discussion in WICG/origin-agent-cluster#31 the naming of this API, as well as its edge-case behavior (e.g. for sandboxed iframes) will likely change. Bug: 1042415 Change-Id: I20c2d3e3fec7a5c0f1d12c386999c32fe27b6a34 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2243994 Reviewed-by: Charlie Reis <[email protected]> Reviewed-by: Daniel Cheng <[email protected]> Reviewed-by: James MacLean <[email protected]> Commit-Queue: Domenic Denicola <[email protected]> Cr-Commit-Position: refs/heads/master@{#782672}
moz-v2v-gh
pushed a commit
to mozilla/gecko-dev
that referenced
this issue
Jul 3, 2020
…nIsolationRestricted, a=testonly Automatic update from web-platform-tests Origin isolation: implement window.originIsolationRestricted See WICG/origin-agent-cluster#24 and WICG/origin-agent-cluster#30 for background, and whatwg/html#5545 for the specification. Failing test expectations include: - We implement (3) from WICG/origin-agent-cluster#24 instead of (2) for now, so we fail getter-sandboxed-iframe. Tracking at https://crbug.com/1095653. - The initial about:blank, as well as removed iframes, are not properly returning true, so about-blank and removing-iframes are failing. Also tracking at https://crbug.com/1095653. - data: URLs are not [SecureContext] in Chromium (https://crbug.com/1095656) so getter-data-url fails. Note that per ongoing discussion in WICG/origin-agent-cluster#31 the naming of this API, as well as its edge-case behavior (e.g. for sandboxed iframes) will likely change. Bug: 1042415 Change-Id: I20c2d3e3fec7a5c0f1d12c386999c32fe27b6a34 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2243994 Reviewed-by: Charlie Reis <[email protected]> Reviewed-by: Daniel Cheng <[email protected]> Reviewed-by: James MacLean <[email protected]> Commit-Queue: Domenic Denicola <[email protected]> Cr-Commit-Position: refs/heads/master@{#782672} -- wpt-commits: 9e23aa452a1261c637ce32cbb8bee450e7006f8d wpt-pr: 24194
xeonchen
pushed a commit
to xeonchen/gecko
that referenced
this issue
Jul 6, 2020
…nIsolationRestricted, a=testonly Automatic update from web-platform-tests Origin isolation: implement window.originIsolationRestricted See WICG/origin-agent-cluster#24 and WICG/origin-agent-cluster#30 for background, and whatwg/html#5545 for the specification. Failing test expectations include: - We implement (3) from WICG/origin-agent-cluster#24 instead of (2) for now, so we fail getter-sandboxed-iframe. Tracking at https://crbug.com/1095653. - The initial about:blank, as well as removed iframes, are not properly returning true, so about-blank and removing-iframes are failing. Also tracking at https://crbug.com/1095653. - data: URLs are not [SecureContext] in Chromium (https://crbug.com/1095656) so getter-data-url fails. Note that per ongoing discussion in WICG/origin-agent-cluster#31 the naming of this API, as well as its edge-case behavior (e.g. for sandboxed iframes) will likely change. Bug: 1042415 Change-Id: I20c2d3e3fec7a5c0f1d12c386999c32fe27b6a34 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2243994 Reviewed-by: Charlie Reis <[email protected]> Reviewed-by: Daniel Cheng <[email protected]> Reviewed-by: James MacLean <[email protected]> Commit-Queue: Domenic Denicola <[email protected]> Cr-Commit-Position: refs/heads/master@{#782672} -- wpt-commits: 9e23aa452a1261c637ce32cbb8bee450e7006f8d wpt-pr: 24194
domenic
added a commit
that referenced
this issue
Jul 8, 2020
Closes #31. Closes #32. Note that the specification pull request at whatwg/html#5545 is already updated for these semantics.
domenic
added a commit
that referenced
this issue
Jul 8, 2020
Closes #31. Closes #32. Note that the specification pull request at whatwg/html#5545 is already updated for these semantics.
domenic
added a commit
that referenced
this issue
Jul 9, 2020
Closes #31. Closes #32. Note that the specification pull request at whatwg/html#5545 is already updated for these semantics.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
#24 proposes adding a
window.originIsolationRestricted
API to help web developers understand when opt-in origin isolation takes effect. I'm concerned about the API being a bit confusing as specified, and I wonder if any additional review is useful to make it easier to understand and use.It sounds like the API is currently specified to return whether
document.domain
andpostMessage
are more restricted than usual, rather than whether they're restricted to an origin rather than a site. "Than usual" is a relative term, though, which makes it hard to predict or explain: it is true when the reason is opt-in origin isolation and COOP/COEP, but it is false when the reason is IP addresses, opaque origins, workers, etc. Thus, it isn't useful as an indicator of page behavior, but only as an indicator of certain arbitrary features' effects.It also seems like we might aspire to some day have
document.domain
(and perhapspostMessage
of WASM Modules) be restricted by default, which would again change the meaning of this API (either false everywhere, because the behavior never gets further restricted, or true everywhere, because it's always restricted). Having it be true everywhere seems like a more consistent thing to aspire to, at least from my perspective. (Otherwise its value would become true more commonly as isolation are adopted, then suddenly drop off if we restrict everywhere.)From #24 (comment), I would suggest that option (1) seems like an easier concept to explain and have as part of the web platform, even if it doesn't map as directly to one concrete use case (i.e., "was my specific header the reason for the behavior change?").
As an aside, neither
originIsolation
nororiginIsolationRestricted
seem like particularly self-explanatory names here either, when side-by-side withcrossOriginIsolated
. Maybe the desired behavior is better to establish first, though, before any bikeshedding on the name.@domenic @annevk @arturjanc @mikewest for thoughts.
The text was updated successfully, but these errors were encountered: