Intent to Prototype: Document-Isolation-Policy

[Camille Lamy]

Contact emails

cl...@google.com

Explainer

https://github.com/explainers-by-googlers/document-isolation-policy

Specification

None

Summary

Document-Isolation-Policy allows a document to enable crossOriginIsolation for itself, without having to deploy COOP or COEP, and regardless of the crossOriginIsolation status of the page. The policy is backed by process isolation. Additionally, the document non-CORS cross-origin subresources will either be loaded without credentials or will need to have a CORP header.

Blink component

Blink>SecurityFeature

Motivation

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 and not requiring extra work to embed cross-origin iframes. Finally, it will be available for embedded widgets.

Initial public proposal

https://github.com/WICG/proposals/issues/145

TAG review

None

TAG review status

Pending

Risks

Interoperability and Compatibility

None

Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

None

Is this feature fully tested by web-platform-tests?

No

Flag name on chrome://flags

None

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5141940204208128?gate=5097535879512064

This intent message was generated by Chrome Platform Status.

[Charlie Reis]

Thanks for sharing this.  I do think it's worth calling attention to this paragraph of the explainer, for one thing to consider about the proposal:

The Document-Isolation-Policy proposal relies on agent cluster keying to achieve isolation, instead of browsing context group switches. This means that it introduces a situation where two same-origin documents might find themselves in different agent clusters and be unable to have DOM access to each other. This is unprecedented in the HTML spec.

In other words, two same-origin frames within the same page (or anywhere in the same browsing context group) can end up in different processes, unable to script each other.  It could be that this is considered fine and might be outweighed by the benefits of the proposal, though it does have some implications for web developers and for the browser's implementation:

• Web developers might be confused when some attempts to script a same-origin frame fail, since this has always been possible within a given browsing context group.  Maybe this can be mitigated with a different type of error message in the DevTools console?
• In Chromium's implementation, both the browser process and renderer process make assumptions that same-origin frames within the same browsing context group (also known as content::BrowsingInstance) must be in the same process so that they can script each other.  Dividing that up based on Document-Isolation-Policy seems like it should be possible, though it would add some complexity and might require some auditing of process model code.

Maybe this is a manageable risk?

Thanks,

Charlie

--
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/CAMKsNvp7Xcgz%3DcMXJ7%2B%2BBgwhO2wOKEkaMiDk_wUY1nprvPG4HQ%40mail.gmail.com.

[Vladimir Levin]

This does sound a bit unfortunate. My understanding is that at least this behavior is deterministic, right? That is, either the same-origin frames will be able to script each other or they won't and this will happen consistently (based on the agent cluster key).

An observation I had is that it seems that the Document-Isolation-Policy is still at the mercy of the platform having the resources to process-isolate frames. It wasn't clear to me from the explainer whether this is already a limitation with the COOP and COEP approaches, however unwieldy those may be. This basically means that one of the listed use-case of authors maintaining two copies of their widgets -- one with SharedArrayBuffers, one without -- doesn't seem to be addressed. Also I'm not sure if it would be possible for 3p iframes to starve platform of such resources so that the top level frame would no longer be able to create 1p frames that have access to COI-gated APIs

(I also don't know what is the right forum in which to raise these issues)

Thanks,

Vlad

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH%2B8MBZfpRCRsQMqvjy8NPmo9_v8WQcdu%3Ds06%2BVWb6a17dQ-jw%40mail.gmail.com.

[Charlie Reis]

My understanding is that at least this behavior is deterministic, right? That is, either the same-origin frames will be able to script each other or they won't and this will happen consistently (based on the agent cluster key).

Yes, I think it would be deterministic based on the headers, so hopefully education via error messages would help.

An observation I had is that it seems that the Document-Isolation-Policy is still at the mercy of the platform having the resources to process-isolate frames.

Camille can probably confirm the details, but I believe that's right.  COOP+COEP depends on the platform being able to open a new window in a different process, which I think all platforms but Android WebView can support at this point (?).  Document-Isolation-Policy would depend on out-of-process iframes, which wouldn't work on Android WebView or iOS, at least for the time being.  On platforms that do support out-of-process iframes, it would make crossOriginIsolated modes much easier to adopt, though.

Also I'm not sure if it would be possible for 3p iframes to starve platform of such resources so that the top level frame would no longer be able to create 1p frames that have access to COI-gated APIs

IIUC, I think each origin is limited in the number of processes it could create in a given page (basically one with SAB access and one without), which helps.

Charlie 

[Vladimir Levin]

On Thu, Apr 4, 2024 at 12:11 PM Charlie Reis <cr...@chromium.org> wrote:

My understanding is that at least this behavior is deterministic, right? That is, either the same-origin frames will be able to script each other or they won't and this will happen consistently (based on the agent cluster key).

Yes, I think it would be deterministic based on the headers, so hopefully education via error messages would help.

An observation I had is that it seems that the Document-Isolation-Policy is still at the mercy of the platform having the resources to process-isolate frames.

Camille can probably confirm the details, but I believe that's right.  COOP+COEP depends on the platform being able to open a new window in a different process, which I think all platforms but Android WebView can support at this point (?).  Document-Isolation-Policy would depend on out-of-process iframes, which wouldn't work on Android WebView or iOS, at least for the time being.  On platforms that do support out-of-process iframes, it would make crossOriginIsolated modes much easier to adopt, though.

I seem to recall that Android Chrome is also limited here, but maybe that has changed and my knowledge is outdated.

 

Also I'm not sure if it would be possible for 3p iframes to starve platform of such resources so that the top level frame would no longer be able to create 1p frames that have access to COI-gated APIs

IIUC, I think each origin is limited in the number of processes it could create in a given page (basically one with SAB access and one without), which helps.

Ah that makes sense. There may still be some possibility with just spamming 3p iframes but that likely exists today anyway

Thanks!

Vlad

[Charlie Reis]

I seem to recall that Android Chrome is also limited here, but maybe that has changed and my knowledge is outdated.

Correct, we don't usually create out-of-process iframes on Android Chrome if the device has less than 2G of RAM.  Otherwise we allow it (e.g., for partial Site Isolation).  I'm not sure if COOP+COEP has any restrictions on low-end Android devices, since that mode requires multiple processes but not out-of-process iframes.  For Document-Isolation-Policy, I believe there's some notes about low-end Android devices in the explainer, maybe suggesting that it's less needed on such devices?  I'll let Camille clarify.

Charlie 

[Camille Lamy]

Yes the user agent keying is deterministic, and we're adding reporting to warn developers if they end up having two same origin documents that could normally have DOM access but can't due to Document-Isolation-Policy. Our recommendation would be to adopt the header on all documents of an origin, which removes the concerns around script access. As a followup, we might resurrect the Origin-Policy work to help with this issue.

For COOP and COEP, you're correct to note that they are not available due to the platform limitations on Android WebView. Because of this, the crossOriginIsolated spec already has a notion of crossOriginIsolation being either logical (ie no API access) or effective (ie API access). We're building on this existing notion.

In terms of platform support, our goal is to first release on desktop, in order to finally end the ungated SAB reverse Origin Trial. Then we'll extend to Android (but not Android WebView). For Android, the situation is a bit different from full Site Isolation, because here the isolation and resulting increase memory consumption is driven by the website as opposed to the platform. We might not implement full functionality on low-end Android, but then none of the developers interested in the API want to have it run on low-end Android. Basically, this gives access to SharedArrayBuffers, which are mostly useful to cut calculation time in heavy web apps, that wouldn't run on devices with limited hardware.

Hope that helps!

Camille

Charlie 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMKsNvp7Xcgz%3DcMXJ7%2B%2BBgwhO2wOKEkaMiDk_wUY1nprvPG4HQ%40mail.gmail.com.

--
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+unsubscribe@chromium.org.

[Yoav Weiss (@Shopify)]

This is very interesting!

Do I understand correctly and the main reason this would be easier to deploy is because embedded iframes and popups won't need to deploy COEP in this model?

On Fri, Apr 5, 2024 at 12:14 PM Camille Lamy <cl...@chromium.org> wrote:

Yes the user agent keying is deterministic, and we're adding reporting to warn developers if they end up having two same origin documents that could normally have DOM access but can't due to Document-Isolation-Policy.

I'm not sure same-origin isolation won't end up being a desired feature on its own. I heard developers asking for stronger isolation primitives on more than one occasion. I'll talk to folks and think about it some more.

 

Our recommendation would be to adopt the header on all documents of an origin, which removes the concerns around script access. As a followup, we might resurrect the Origin-Policy work to help with this issue.

Origin-Policy would definitely help avoid mistakes here..

 

Charlie 

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/CAMKsNvp7Xcgz%3DcMXJ7%2B%2BBgwhO2wOKEkaMiDk_wUY1nprvPG4HQ%40mail.gmail.com.

--
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/CAH%2B8MBZfpRCRsQMqvjy8NPmo9_v8WQcdu%3Ds06%2BVWb6a17dQ-jw%40mail.gmail.com.

--

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/1db78c8e-0672-4f62-ac3e-22cb614ca2a6n%40chromium.org.

[Tom Jones]

There is a huge demand for protecting data that's shared with users  Any help in strong binding data to origin and blocking sharing would a big win.

thx ..Tom (mobile)

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohS%2BzyOX6amnva6t_HBsXPXAFoZEri7A78ka7-OwA66B%3Dmw%40mail.gmail.com.

[Camille Lamy]

On Monday, April 8, 2024 at 6:12:23 PM UTC+2 thomascli...@gmail.com wrote:

There is a huge demand for protecting data that's shared with users  Any help in strong binding data to origin and blocking sharing would a big win.

I believe that is a different problem from the one we're trying to solve with this API. Would you happen to have more details about the issue you're referring to?

 

thx ..Tom (mobile)

On Mon, Apr 8, 2024, 1:20 AM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:

This is very interesting!

Do I understand correctly and the main reason this would be easier to deploy is because embedded iframes and popups won't need to deploy COEP in this model?

Yes. They also wouldn't need to deploy COOP, and so would be able to interact with cross-origin popups.

 

Charlie 

Blink componentBlink>SecurityFeature

Motivation

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 and not requiring extra work to embed cross-origin iframes. Finally, it will be available for embedded widgets.

Initial public proposalhttps://github.com/WICG/proposals/issues/145

TAG reviewNone

TAG review statusPending

Risks

Interoperability and Compatibility

None

Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

None

Is this feature fully tested by web-platform-tests?No

Flag name on chrome://flagsNone

Finch feature nameNone

Non-finch justificationNone

Requires code in //chrome?False

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Statushttps://chromestatus.com/feature/5141940204208128?gate=5097535879512064

This intent message was generated by Chrome Platform Status.

--
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+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMKsNvp7Xcgz%3DcMXJ7%2B%2BBgwhO2wOKEkaMiDk_wUY1nprvPG4HQ%40mail.gmail.com.

--
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+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH%2B8MBZfpRCRsQMqvjy8NPmo9_v8WQcdu%3Ds06%2BVWb6a17dQ-jw%40mail.gmail.com.

--
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+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1db78c8e-0672-4f62-ac3e-22cb614ca2a6n%40chromium.org.

--
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+unsubscribe@chromium.org.

[Charlie Reis]

On Mon, Apr 8, 2024 at 1:20 AM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:

I'm not sure same-origin isolation won't end up being a desired feature on its own. I heard developers asking for stronger isolation primitives on more than one occasion. I'll talk to folks and think about it some more.

To be clear, this would not be secure isolation between two parts of the same origin.  The documents would still share the same cookies, localStorage, permissions, etc.  It would only allow them to run in different processes from each other.  That's useful for restricting what else runs in the same process (e.g., to limit what can be leaked via Spectre + SABs), but it is not a new isolation primitive for data within an origin.  That sort of primitive is generally discouraged, per the 2008 Beware of Finer-Grained Origins paper.

Charlie