Some origins can contain different applications with different levels of security requirements. In those cases, it can be beneficial to prevent scripts running in one application from being able to open and script pages of another same-origin application. In such cases, it can be beneficial for a document to ensure its opener cannot script it, even if the opener document is a same-origin one. The `noopener-allow-popups` Cross-Origin-Opener-Policy value will allow documents to define that.
Compatibility risk: As this feature adds a new COOP value, it doesn't run a risk of colliding with existing values. Where we may see some risk is when developers start using this value in ways that would surprise other teams on their origins. (as they would no longer have scripting access to opened documents) I don't expect that to happen often, and if it would it's something that developers would find out at development time. So I don't expect that to impact users. Interoperability risk: WebKit's positive position makes me optimistic that I'd be able to land the feature there as well.
No particular issues: https://gist.github.com/yoavweiss/3cb7283f56717f6dfe6da05009a27a65
The main risk is having developers over rely on the protections this would provide. Input from Chrome and Google security folks led to the inclusion of a spec note warning developers against it and indicating what else they'd need to do for more holistic isolation of same-origin documents from others.
I'm planning to add a similar note to developer-facing docs.
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None
None
The test doesn't pass on the bots as the feature is disabled using a base feature flag (and no runtime flag).
Shipping on desktop | 131 |
Shipping on Android | 131 |
Shipping on WebView | 131 |
Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/24c89356-98aa-4503-83d1-a015c5ab7f1cn%40chromium.org.
LGTM3
(Would be nice to have the PR landed, but it does look like it's just a post-vacation delay rather than any concerns so I will assume that it's landing Real Soon Now)
/Daniel
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-kEUKSHDazs61oor%2B3SQu3j7L1Jpp7Hhb3jhKjnLuUgg%40mail.gmail.com.