va...@chromium.org cl...@chromium.org
https://docs.google.com/document/d/1zDlfvfTJ_9e8Jdc8ehuV4zMEu9ySMCiTGMS9y0GU92k
https://tc39.github.io/ecma262/#sec-sharedarraybuffer-objects
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
‘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.
Last time we extended the OT for 6 months and now we’re coming back to you all to provide updates.
We’re proposing to extend the reverse OT until M121 because of
COOP:restrict-properties spec and implementation work (OT planned start in M115 - aiming for 3 milestones)
COEP:credentialless - Adoption is already at 0.02% of main pages
We’ve worked with multiple internal and external users of the OT to understand their use cases and why they can’t adopt yet. With COEP:credentialless and iframes credentialless now available, the SAB non COI usage went further down. The last known issues are popup based workflows (Login and payments) which are being addressed with COOP:RP.
Going forward we propose to give those partners 3 more milestones after the stable release, hence the SAB reverse OT should end with M121.
To allow crossOriginIsolated pages to use popup-based flows, we plan to have COOP:RP enable crossOriginIsolation when used along with COEP. Developers who depend on popups to 3P for identity, payments, multi-app integrations, data visualization, etc. can’t currently deploy cross-origin-isolation.
We plan to start an OT for this feature in Q3, and take feedback we receive back to WHATWG to continue a conversation around standardization. We expect our implementation to completely incorporate that feedback in Q4. Without this, sites need to either migrate to dedicated APIs like FedCM or WebPayment, if available, or to totally drop their use of SABs, sometimes causing drastic performance reductions.
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.
Gecko: Shipped/Shipping (https://bugzilla.mozilla.org/show_bug.cgi?id=1312446)
WebKit: Added COOP/COEP and SAB support recently gated behind COOP/COEP
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
https://bugs.chromium.org/p/chromium/issues/detail?id=1144104
https://bugs.chromium.org/p/chromium/issues/detail?id=1138860
Blink-dev Thread
Planning isolation requirements (COOP/COEP) for SharedArrayBuffer
--
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/CAH0ixBM2ReRVKKUVHj7Ca3%2BOzw6y-qmZyhA9thiBoqXmqXwCiw%40mail.gmail.com.