Document-Isolation-Policy

[camillelamy]

こんにちは TAG-さん!

I'm requesting a TAG review of Document-Isolation-Policy.

Developers want to build applications that are fast using SharedArrayBuffers (SAB), which can improve computation time by ~40%. But SharedArrayBuffers allow to create high-precision timers that can be exploited in a Spectre attack, allowing to leak cross-origin user data. To mitigate the risk, SharedArrayBuffers are gated behind crossOriginIsolation (COI). CrossOriginIsolation requires to deploy both Cross-Origin-Opener-Policy (COOP) and Cross-Origin-Embedder-Policy (COEP). Both have proven hard to deploy, COOP because it prevents communication with cross-origin popups, and COEP because it imposes restrictions on third-party embeds. Finally, the whole COOP + COEP model is focused on providing access to SharedArrayBuffers to the top-level frame. Cross-origin embeds can only use SABs if their embedder deploys crossOriginIsolation and delegates the permission to use COI-gated APIs, making the availability of SABs in third-party iframes very unreliable.

Document-Isolation-Policy, is proposing to solve these deployment concerns by relying on the browser Out-of-Process-Iframe capability. It will provide a way to securely build fast applications using SharedArrayBuffers while maintaining communication with cross-origin popups (needed for OAuth and payment flows) and not requiring extra work to embed cross-origin iframes. Finally, it will be available for embedded widgets as well as top-level frames, allowing to build efficient compute heavy widgets that are embedded across a variety of websites (e.g. photo library, video conference iframe, etc….

• Explainer: https://github.com/WICG/document-isolation-policy
• Specification: https://wicg.github.io/document-isolation-policy/
• WPT Tests: https://wpt.fyi/results/html/document-isolation-policy?label=experimental&label=master&aligned
• User research:
• Security and Privacy self-review: https://github.com/WICG/document-isolation-policy/blob/main/security_privacy_self_review.md
• GitHub repo: https://wicg.github.io/document-isolation-policy/
• Primary contacts:
  • Camille Lamy (@camillelamy), Google, spec author
• Organization/project driving the specification: Google
• Multi-stakeholder support:
  • Chromium comments: We are excited to start trialing this API with developers through origin trials.
  • Mozilla comments: Document-Isolation-Policy mozilla/standards-positions#1074
  • WebKit comments: https://wicg.github.io/document-isolation-policy/ WebKit/standards-positions#399
  • Positive feedback from developer on the initial WICG proposal.
• Status/issue trackers for implementations:
  • Chromium: https://chromestatus.com/feature/5141940204208128

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• The group where the work on this specification is currently being done: WICG
• The group where standardization of this work is intended to be done (if different from the current group): WHATWG
• Major unresolved issues with or opposition to this specification:
• This work is being funded by: Google

You should also know that...

This proposal is solving the same issues as our previous proposal COOP: restrict-properties. This new proposal is meant to replace the old one.

[martinthomson]

Hi @camillelamy, thanks for bringing this to us. We're still struggling a little bit with the explainer here, but there are a few things you might add to help us a little.

1. What is the user need that this addresses? There is some mention of performance benefits in your writeup here (~40%! [citation-needed]), but that isn't really substantiated. Can you give us some examples of real-world scenarios in which this would be used and provide material end-user benefit. In particular, why do these applications need to jointly use popups and this sort of arrangement? In "use cases" you list "App with cross-origin popup" and state "The user would like some of their compute heavy web apps to be faster" - but there is no discussion of why these applications must exist cross-origin.

2. What are the trade-offs taken for this? Or, what are the risks that we'd be taking on by allowing this loosening of cross-origin isolation? The explainer focuses exclusively on arguing for the proposal, but if we're going to make a reasoned decision, we need to understand the cost of the change. Are there any safeguards that might be needed to mitigate these risks?

3. Are there cases where applications might want to use SharedArrayBuffer, but are unable to employ a fallback method, such that enabling easier access to the capability would dramatically simplify the deployment/development of those applications?

[Sora2455]

As a web developer, I'm very interested in the "Prevent XS-leaks and Specter without having to force all my 3rd-party iFrames to use COEP" part of this proposal.