Intent to Extend Origin Trial: Trial for SharedArrayBuffers in non-isolated pages on Desktop platforms
Lutz Vahl
Contact emails
va...@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 again from M103 until M113 (branch point 2023-03-23). This is an estimation - Can we come back to y'all in 6 months with a report on progress and usage to justify that extension and agree on the final milestone?
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 lots of feedback that adopting COOP/COEP is hard and sometimes impossible. Therefore the reverse OT is currently the only way to enable SABs for some sites within Chromium. Chromestatus is showing that SABs in none COI context are being used on ~0.36% page loads.
To overcome this limitation and make adoption possible more broadly (public feedback), we’re working on multiple solutions (all shared timelines are WIP):
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.
This mechanism was shipped in M96. (Adoption is already at 0.02% of main pages)
COI+popups (formally: 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 Q2 2022 for the OT and Q3 for the shipping. As soon as the spec is defined, we’ll kick off the intent process. Without this all sites need to migrate to FedCM and WebPayment for their flows to be able to use SABs.
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.
Based on the progress made for storage partitioning and CHIPs, which are needed to safely ship Anonymous iframes, we’re aiming to start the OT in Q2 2022 (M106) and the rollout in Q3 2022 (M110).
Blink component
Search tags
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 give 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 usage is down to ~0.36% page loads and that other browsers have or are shipping SABs again gated behind COOP/COEP. Bad news is that Chromium was the only browser that supported SABs without COI, therefore we need to provide a migration path to not break existing sites such as Zoom or Google Earth.
Gecko: Shipped/Shipping (https://bugzilla.mozilla.org/show_bug.cgi?id=1312446)
WebKit: Added COOP/COEP and SAB support 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
Link to entry on the Chrome Platform Status
Chris Harrelson
Contact emails
va...@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 again from M103 until M113 (branch point 2023-03-23). This is an estimation - Can we come back to y'all in 6 months with a report on progress and usage to justify that extension and agree on the final milestone?
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 lots of feedback that adopting COOP/COEP is hard and sometimes impossible. Therefore the reverse OT is currently the only way to enable SABs for some sites within Chromium. Chromestatus is showing that SABs in none COI context are being used on ~0.36% page loads.
--
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/CAH0ixBN2JhcYtpT4UYKcAfHt1e0Wz_Uxz0CkXcAntguhbmyNCA%40mail.gmail.com.
Lutz Vahl
On Wed, Apr 27, 2022 at 6:04 AM Lutz Vahl <va...@chromium.org> wrote:Contact emails
va...@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 again from M103 until M113 (branch point 2023-03-23). This is an estimation - Can we come back to y'all in 6 months with a report on progress and usage to justify that extension and agree on the final milestone?
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 lots of feedback that adopting COOP/COEP is hard and sometimes impossible. Therefore the reverse OT is currently the only way to enable SABs for some sites within Chromium. Chromestatus is showing that SABs in none COI context are being used on ~0.36% page loads.
This seems off by a factor of 10. The real number seems to be 0.036% or so, right? Can you highlight why it's important to extend for 10 more milestones for such a small percentage of traffic? Will the sites in question completely break for some reason, or just behave the same as in non-chromium browsers?
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_HkK7R3fA0pyGUm8MNjbqoBR54XrQZWKeD464qb6JNhA%40mail.gmail.com.
Mike Taylor
On Wed, Apr 27, 2022 at 5:14 PM Chris Harrelson <chri...@chromium.org> wrote:
On Wed, Apr 27, 2022 at 6:04 AM Lutz Vahl <va...@chromium.org> wrote:
Contact emails
va...@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 again from M103 until M113 (branch point 2023-03-23). This is an estimation - Can we come back to y'all in 6 months with a report on progress and usage to justify that extension and agree on the final milestone?
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 lots of feedback that adopting COOP/COEP is hard and sometimes impossible. Therefore the reverse OT is currently the only way to enable SABs for some sites within Chromium. Chromestatus is showing that SABs in none COI context are being used on ~0.36% page loads.
This seems off by a factor of 10. The real number seems to be 0.036% or so, right? Can you highlight why it's important to extend for 10 more milestones for such a small percentage of traffic? Will the sites in question completely break for some reason, or just behave the same as in non-chromium browsers?That's on me: 0.036% is correct!Some sites use SAB to gain extra performance on chromium based browsers in some cases 3P content is using SABs. Some might work without the OT others will break based on how they identify their code path to be used.
The list of OT registrations is ~500 and most of them mentioned to be blocked by 3Ps to deploy COOP+COEP broadly.We're happy to extend the OT to give them time to adopt. Do you (and/or other API owners) think this is not required based on the low usage?
Looking at the use counter data, usage was around 0.17% when the
last request to extend this deprecation trial was made (in Sept of
'21). Since then, it seems like usage decreased quite a lot but
has been basically flat since November of '21 when it was at
0.031% (it's looks to have grown a tiny bit to 0.037% as of
April).
Do we know who the 3Ps are who are holding back migration for the
rest, and what their plans are?
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH0ixBMg_ydJqgjAdPaWZKfv0Xqjj9xqs4kRENmFUgLLy2ZtaA%40mail.gmail.com.
Steve Hoek
Arthur Sonzogni
Does this metric count sites that have opted into the rOT? My company has a web product hosted under dozens of domains that has the rOT registered for each one of them. I don't see those domains in the top 156 list (admittedly a quick scan), so I wonder if it is only counting pages that try to create SAB without any isolation _and_ without the rOT ?
Credentialless has helped in some cases, but anonymous iframes is what we're hoping for to resolve the rest of the flows, but that feature seems to be a bit stuck and unmoving at the moment from what we can tell.
Yoav Weiss
Lutz Vahl
--
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/58b4260b-37c2-4e15-933f-6f6e4d243281n%40chromium.org.
Chris Harrelson
On Wed, Apr 27, 2022 at 5:14 PM Chris Harrelson <chri...@chromium.org> wrote:On Wed, Apr 27, 2022 at 6:04 AM Lutz Vahl <va...@chromium.org> wrote:Contact emails
va...@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 again from M103 until M113 (branch point 2023-03-23). This is an estimation - Can we come back to y'all in 6 months with a report on progress and usage to justify that extension and agree on the final milestone?
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 lots of feedback that adopting COOP/COEP is hard and sometimes impossible. Therefore the reverse OT is currently the only way to enable SABs for some sites within Chromium. Chromestatus is showing that SABs in none COI context are being used on ~0.36% page loads.
This seems off by a factor of 10. The real number seems to be 0.036% or so, right? Can you highlight why it's important to extend for 10 more milestones for such a small percentage of traffic? Will the sites in question completely break for some reason, or just behave the same as in non-chromium browsers?That's on me: 0.036% is correct!Some sites use SAB to gain extra performance on chromium based browsers in some cases 3P content is using SABs. Some might work without the OT others will break based on how they identify their code path to be used.The list of OT registrations is ~500 and most of them mentioned to be blocked by 3Ps to deploy COOP+COEP broadly.We're happy to extend the OT to give them time to adopt. Do you (and/or other API owners) think this is not required based on the low usage?
Lutz Vahl
The API owners met today and discussed this Intent.Overall, I'd summarize as saying that I think the API owners would only be comfortable extending the origin trial by 3 milestones at this time. (We have not yet approved that extension however; first I'd like to wait for an answer to the followup question inline below).
After that time, if you wish to extend it further, you'll need to show substantial additional progress towards shipping. For me, substantial progress could include "we rolled out more of the mechanisms to make it easy to migrate", "the number of reverse OT participants dropped substially", or "the use counter and list of sites at risk reduced substantially".
On Wed, Apr 27, 2022 at 9:27 AM Lutz Vahl <va...@chromium.org> wrote:On Wed, Apr 27, 2022 at 5:14 PM Chris Harrelson <chri...@chromium.org> wrote:On Wed, Apr 27, 2022 at 6:04 AM Lutz Vahl <va...@chromium.org> wrote:Contact emails
va...@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 again from M103 until M113 (branch point 2023-03-23). This is an estimation - Can we come back to y'all in 6 months with a report on progress and usage to justify that extension and agree on the final milestone?
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 lots of feedback that adopting COOP/COEP is hard and sometimes impossible. Therefore the reverse OT is currently the only way to enable SABs for some sites within Chromium. Chromestatus is showing that SABs in none COI context are being used on ~0.36% page loads.
This seems off by a factor of 10. The real number seems to be 0.036% or so, right? Can you highlight why it's important to extend for 10 more milestones for such a small percentage of traffic? Will the sites in question completely break for some reason, or just behave the same as in non-chromium browsers?That's on me: 0.036% is correct!Some sites use SAB to gain extra performance on chromium based browsers in some cases 3P content is using SABs. Some might work without the OT others will break based on how they identify their code path to be used.The list of OT registrations is ~500 and most of them mentioned to be blocked by 3Ps to deploy COOP+COEP broadly.We're happy to extend the OT to give them time to adopt. Do you (and/or other API owners) think this is not required based on the low usage?Thanks for this information. Can you also share some examples of specific sites you're concerned about breaking and how they would break?
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BN6QZsiRA7SaCapgRDnnGC7RNFZ82NRW_xadxOm4e0xNLJuNA%40mail.gmail.com.
Arthur Hemery
PS: If you're working on a website that currently uses the reverse OT because it needs to interact with popups, feel free to reach out to me personally about your thoughts on the current proposal. Getting developers feedback will help make it move faster!
Chris Harrelson
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/df3c52f6-d928-404f-9d92-740edba62502n%40chromium.org.
Lutz Vahl
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9dUzHffPmitk5iv%2BvKx03_6bmf9WUp6%2BKShMgyEY8xqw%40mail.gmail.com.
Chris Harrelson
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH0ixBNs_nxh5pKgV_W2%3DNufRsrU_LA7CW-tso_0uJm3Aswy0g%40mail.gmail.com.
Lutz Vahl
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.
Updates
We’ve received lots of feedback that adopting COOP/COEP is difficult (details above). Nevertheless we made substantial progress towards removing the usage - Chromestatus is showing that SABs in non-COI context are being used on ~0.026% page loads (down from >2.5%).
The API owners asked to prove substantial progress to allow an extension until M113 (3x MS after shipping the last feature), which I’m happy to share:
COEP:credentialless was shipped in M96. (Adoption is already increasing to 0.025% of main pages)
Developers who depend on popups to 3P for e.g. identity or payment flows can’t currently deploy cross-origin-isolation. To allow crossOriginIsolated pages to use popup-based OAuth/payment flows, we plan to have a new COOP value: “restrict-properties” that enables crossOriginIsolation when used in conjunction with COEP. This new value restricts cross-window access to just postMessage and closed instead of completely severing popup access.
Spec work is ongoing (see discussion, and previous iteration PR) and requires partners input to convince Mozilla that it is the correct solution, ENG work is ongoing and we’re targeting M106 for OT and M110 to ship.
Anonymous iframes and COEP reflection - launch bug - I2P - I2E
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.
Based on the progress made for storage partitioning and CHIPs, which are needed to safely ship Anonymous iframes, we’re unblocked to start the OT in M106 and the rollout in Q3 2022 (M110).
The spec:
https://wicg.github.io/anonymous-iframe/#specification (PRs: 1,2,3)
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw84WJS-Vt4S8%2BiRuHqZZaGaP58MCNCo3sCJoH%3DwxN%2BmBg%40mail.gmail.com.
Yoav Weiss
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH0ixBO1%3D_WbDvMZ9oWQV01MgQ0J272G0FqCvdmgcbTEr5U4Nw%40mail.gmail.com.
Lutz Vahl
Lutz
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWBZMRp%3DzYqC_%2Ba9BGD0%3D%2Bzi_1NUxd4MgFno7MSPG%2BzWA%40mail.gmail.com.
Yoav Weiss
Lutz Vahl
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUTTamjCT0tg5S4wG2fVAJ06wGuMuap0GzurfHgzRqocg%40mail.gmail.com.
Lutz Vahl
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.
Updates
We’ve received lots of feedback that adopting COOP/COEP is difficult (details above). Nevertheless we made substantial progress towards removing the usage - Chromestatus is showing that SABs in non-COI context are being used on ~0.027% page loads (down from >2.5%).
The API owners asked to prove substantial progress to allow an extension until M113 (aimed OT start of the last feature), which I’m happy to share.
Once we’ve started the COOP:RP OT I’ll come back to this thread sharing feedback and the final deprecation timeline.
COEP:credentialless was shipped in M96. (Adoption is already increasing to 0.0032% of main pages)
Developers who depend on pop ups to 3P for e.g. identity or payment flows can’t currently deploy cross-origin-isolation. To allow crossOriginIsolated pages to use popup-based OAuth/payment flows, we plan to have a new COOP value: “restrict-properties” that enables crossOriginIsolation when used in conjunction with COEP. This new value restricts cross-window access to just postMessage and closed instead of completely severing popup access.
Spec work is ongoing (see discussion, and previous iteration PR) and requires partners input to convince others that it is the correct solution. Initial design and implementation met some issues and we got back to the design stage after missing the OT in 109. We are iterating on it with support from Chrome Security Architecture. See the design doc and this discussion doc for details. We are now planning to have an OT in early 2022. Other vendors and TAG need to be queried again for standardization once the new design is considered good, but that is not required to start the OT, since feedback will very likely have influence. This feature is the last puzzle piece to make COI adoption possible across various use cases.
Anonymous iframes - launch bug - I2P - I2E - I2S
Anonymous iframes are a generalization of COEP credentialless to support 3rd party iframes. Instead of waiting for the third party to opt-in into COEP, it allows the embedder to load the public version of iframe without requiring COEP. The anonymous iframe’s document is assigned a new and ephemeral storage/network/cookie partition.
The Anonymous iframes OT started in M106 and we’ve received positive feedback from developers. We would like to address issue/5 and enable the feature in M110
The spec:
https://wicg.github.io/anonymous-iframe/#specification (PRs: 1,2,3)Lutz Vahl
Yoav Weiss
Lutz Vahl
Contact emails
va...@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
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.
Updates
We’ve received lots of feedback that adopting COOP/COEP is difficult (details above). Nevertheless we made substantial progress towards removing the usage - Chromestatus is showing that SABs in non-COI context are being used on ~0.027% page loads (down from >2.5%).
The API owners asked to prove substantial progress to allow an extension until M113 (aimed OT start of the last feature), which I’m happy to share.
Once we’ve started the OT I’ll come back to this thread sharing feedback and the final deprecation timeline.
COEP:credentialless was shipped in M96. (Adoption is already increasing to 0.0032% of main pages)
Developers who depend on pop ups to 3P for e.g. identity or payment flows can’t currently deploy cross-origin-isolation. To allow crossOriginIsolated pages to use popup-based OAuth/payment flows, we plan to have a new COOP value: “restrict-properties” that enables crossOriginIsolation when used in conjunction with COEP. This new value restricts cross-window access to just postMessage and closed instead of completely severing popup access.
Spec work is ongoing (see discussion, and previous iteration PR) and requires partners input to convince others that it is the correct solution. Initial design and implementation met some issues and we got back to the design stage after missing the OT in 109. We are iterating on it with support from Chrome Security Architecture. See the design doc and this discussion doc for details. We are now planning to have an OT in early 2022. Other vendors and TAG need to be queried again for standardization once the new design is considered good, but that is not required to start the OT, since feedback will very likely have influence. This feature is the last puzzle piece to make COI adoption possible across various use cases.
Anonymous iframes - launch bug - I2P - I2E - I2S
Anonymous iframes are a generalization of COEP credentialless to support 3rd party iframes. Instead of waiting for the third party to opt-in into COEP, it allows the embedder to load the public version of iframe without requiring COEP. The anonymous iframe’s document is assigned a new and ephemeral storage/network/cookie partition.
The Anonymous iframes OT started in M106 and we’ve received positive feedback from developers. We would like to address issue/5 and enable the feature in M110
The spec:
https://wicg.github.io/anonymous-iframe/#specification (PRs: 1,2,3)
Lutz Vahl
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWZqjxDfnOk8-dwcheJ%3D%2ByX1F_wf5xtP-OiigWAyZgfbQ%40mail.gmail.com.