[webkit-dev] Request for position on COEP reflection
Greetings webkit-dev, I am requesting your feedback about exposing: ```js self.crossOriginEmbedderPolicy; ``` It reflects the environment's crossOriginEmbedderPolicy's value. More details on: https://github.com/ArthurSonzogni/coep-reflection Thanks Arthur @arthursonzogni ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Request for position on Anonymous iframe
Greetings webkit-dev, We have been working on Anonymous iframe, and we would appreciate your feedback. This is an attribute to the element causing its document to be associated with a new and ephemeral context. It resolves a problem developers have using Cross-Origin-Embedder-Policy (COEP). It allows embedding that do not use COEP. To achieve this, we rely on adding a nonce to the storage key used to access shared storage by anonymous iframe. As part of the client-side storage partitioning effort (declined across storage APIs, network state and Cookie State), See https://github.com/ArthurSonzogni/anonymous-iframe Thanks Arthur @arthursonzogni ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Request for position: block navigation toward external protocol from sandboxed iframe.
Hi webkit-dev, This is a request for Webkit's position about blocking navigation toward external protocols from sandboxed iframe. *Summary:* Gates sandboxed iframe navigation toward external protocol behind any of: - allow-popups - allow-top-navigation - allow-top-navigation-with-user-gesture (+ user gesture) *Motivation:* Developers are surprised that a sandboxed iframe can navigate and/or redirect the user toward an external application. General iframe navigation in sandboxed iframe are not blocked normally, because they stay within the iframe. However they can be seen as a popup or a top-level navigation when it leads to opening an external application. In this case, it makes sense to extend the scope of sandbox flags, to block malvertising. *Issue:*https://github.com/whatwg/html/issues/2191 *Specification:*https://github.com/whatwg/html/pull/7124 *Mozilla position*https://github.com/mozilla/standards-positions/issues/581 I would love to hear your feedback. Arthur @arthursonzogni ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Request for position: COEP: credentialless
Hi webkit-dev, This is a request for Webkit's position on Cross-Origin-Embedder-Policy:credentialless *Summary:* Credentialless is a Cross-Origin-Embedder-Policy (COEP) variant. Similarly to require-corp, it can be used to enable cross-origin-isolation. COEP:credentialless causes no-cors cross-origin requests not to include credentials (cookies, client certificates, etc...) *Motivation:* Sites that wish to continue using SharedArrayBuffer must opt-into cross-origin isolation. Among other things, cross-origin isolation will block the use of cross-origin resources and documents unless those resources opt-into inclusion via either CORS or CORP. This behavior ships today in Firefox, and Chrome aims to ship it as well in 2021. The opt-in requirement is generally positive, as it ensures that developers have the opportunity to adequately evaluate the rewards of being included cross-site against the risks of potential data leakage via Spectre. It poses adoption challenges, however, as it does require developers to adjust their servers to send an explicit opt-in. This is challenging in cases where there’s not a single developer involved, but many third parties. It would be ideal if we could find an approach that provided robust-enough protection against accidental cross-process leakage without requiring an explicit opt-in. *Explainer*: https://github.com/mikewest/credentiallessness/blob/main/explainer.md *Specification:* https://htmlpreview.github.io/?https://github.com/mikewest/credentiallessness/blob/main/index.html *W3C TAG thread:* https://github.com/w3ctag/design-reviews/issues/582 *WICG proposal.* https://github.com/WICG/proposals/issues/31 *ChromeStatus:* https://www.chromestatus.com/features/4918234241302528 Please let us know if you have any feedback! Thanks, Arthur @arthursonzogni ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
