Intent to Extend Origin Trial (again): 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
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)
Yoav Weiss
--
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/CAH0ixBOWwnCnRnb4zrRQCttem1e44ZdmM0ifLu_-7bnCQFm1PQ%40mail.gmail.com.