Intent to Extend Origin Trial: Trial for SharedArrayBuffers in non-isolated pages on Desktop platforms

161 views
Skip to first unread message

Lutz Vahl

unread,
Sep 6, 2021, 8:43:25 AM9/6/21
to blink-dev, experimen...@chromium.org

Contact emails

va...@chromium.org bbu...@chromium.org cl...@chromium.org


Explainer

https://docs.google.com/document/d/1zDlfvfTJ_9e8Jdc8ehuV4zMEu9ySMCiTGMS9y0GU92k


Specification

https://tc39.github.io/ecma262/#sec-sharedarraybuffer-objects


Design docs Including the new security requirements

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer

Discussion how and what to gate

https://github.com/whatwg/html/issues/4732


Summary

‘SharedArrayBuffers’ (SABs) on desktop platforms are restricted to cross-origin isolated environments, matching the behavior we've recently shipped on Android and Firefox. We've performed that change in Chrome 92. A reverse OT was started to give developers the option to use SABs in case they are not able to adopt cross origin isolation yet.

We’ve received lot’s of feedback that adopting COOP/COEP is hard (details below). Therefore I’m asking for your approval to extend the SAB reverse OT from M96 until M103 (branch point 2022-05-12) to give developers confidence that they'll have time to adopt these additional mechanisms as a means to deploy cross-origin isolation.


Experimental timeline / plan for all new capabilities needed to replace the OT

The SAB restriction in M92 went smoothly without any major issues in the wild because we offered the reverse OT. We’ve received lot’s of feedback that adopting COOP/COEP is hard and sometimes impossible (e.g. Steve’s message in this thread). Therefore the reverse OT is currently the only way to enable SABs for some sites. We do see ~6M DoD active usage of SABs in non COI contexts on UMA, chromestatus is showing ~0.36%.


To overcome this limitation and make adoption possible, we’re working on multiple solutions:


  1. COEP:credentialless - https://crbug.com/1218896

COEP:credentialless causes no-cors cross-origin requests not to include

credentials (cookies, client certificates, etc...). Similarly to require-corp, it can be used to enable cross-origin-isolation. Some developers are blocked on a set of dependencies which don't yet assert that they're safe to embed in cross-origin isolated environments. 

We're working on a `credentialless` COEP mode which is currently in OT that will allow developers to work around this constraint. Based on positive developer feedback we expect to send an I2S in the near future and are hopeful that we can ship this mechanism in the M96


  1. COOP same-origin-allow-popups-plus-coep

To allow crossOriginIsolated pages to use popup-based OAuth/payment flows, we plan to have COOP same-origin-allow-popups enable crossOriginIsolation when used in conjunction with COEP. Developers who depend on popups to 3P for e.g. identity or payment flows can’t currently deploy cross-origin-isolation.


Spec work is ongoing and we’re targeting EoY 2021 to have a prototype and start the OT in Q1 2022. As soon as the spec is defined, we’ll kick off the intent process. Without this all sites need to migrate to WebID and WebPayment for their flows to be able to use SABs.



  1. Anonymous iframes

Anonymous iframes are a generalization of COEP credentialless to support 3rd party iframes that may not deploy COEP. Like with COEP credentialless, we replace the opt-in of cross-origin subresources by avoiding to load non-public resources. This will remove the constraint and will unblock developers to adopt cross-origin-isolation as soon as they’re embedding 3P iframes.


This work is even further down the road as we’re currently blocked by the ongoing pre-partitioning work (Storage partitioning and CHIPs to be code complete), which is needed to safely ship Anonymous iframes. The current plan is to start an OT in Q2 2022.

We’re currently investigating to limit Anonymous iframes to sandboxed iframes in the first place to overcome the partitioning dependency and start a OT earlier, but this will not unblock COI adoption for all iframes.


Blink component

Blink>JavaScript


Search tags

SharedArrayBuffer, SAB


TAG review

https://github.com/w3ctag/design-reviews/issues/471


TAG review status

Closed


Risks

Interoperability and Compatibility

We expect this change to negatively impact developers using `SharedArrayBuffer` today. Chrome was the only platform where SABs have been available without COOP/COEP. Therefore we need to gice developers the right capabilities and a clear path forward to ensure they’ve enough time to adopt. We aim to mitigate these risks by adopting a longer-than-usual depreciation period with console warnings/issues and a reverse origin trial. 

Good news is, that other browsers have or are shipping SABs again gated behind COOP/COEP.

Gecko: Shipped/Shipping (https://bugzilla.mozilla.org/show_bug.cgi?id=1312446)

WebKit: Added COOP/COEP support in the lates preview. SAB support landed recently gated behind COOP/COEP


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

No - This OT is only for desktop, as this was the only platform where SABs have been available without COOP/COEP.

Android re-enabled SABs gated behind COOP/COEP: https://chromestatus.com/feature/5171863141482496


Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1144104


Launch bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1138860


Blink-dev Thread

Planning isolation requirements (COOP/COEP) for SharedArrayBuffer

I2S


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4570991992766464


Yoav Weiss

unread,
Sep 6, 2021, 8:51:54 AM9/6/21
to Lutz Vahl, blink-dev, experimentation-dev
Thanks for working with the community on these mechanisms that enable easier COI adoption!

M92-M103 would mean the trial is running for ~10 months, which is slightly longer than the typical OT. I'm inclined to say that as such, an extension would require 3 LGTMs.

With that said, I don't think there's high risk here, as this is a deprecation trial, and you're actively working with partners to rip the band-aid off eventually.

LGTM1

--
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/CAH0ixBP8_9eWFWYhA2_N_o-1E_xZRqDEh3kZgmZu9YXeX6ajEA%40mail.gmail.com.

Chris Harrelson

unread,
Sep 7, 2021, 1:38:48 PM9/7/21
to Yoav Weiss, Lutz Vahl, blink-dev, experimentation-dev
Reply all
Reply to author
Forward
0 new messages