Hi API owners, CIL. PLMK in case you've additional questions.
On Wed, May 4, 2022 at 6:41 PM Chris Harrelson <chris...@chromium.org> wrote: > 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). > Happy to report back after the M106 branch point if we were able to start the OTs of Anonymous iframes and COI+popups. We'll not be able to report any impact of the use counters on stable at that time. > > After that time, if you wish to extend it further, you'll need to show > substantial > additional progress > <https://www.chromium.org/blink/launching-features/#step-3-optional-origin-trial> > 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". > In the current OT time frame we've shipped COEP:credentialless - so there was substantial progress made. Nevertheless two pieces are still missing to make the adoption possible in all cases where we're working on finalizing the spec and the implementations. +Camille Lamy <cl...@chromium.org> Is able to share more about the complexities involved and why this is taking so long. > > On Wed, Apr 27, 2022 at 9:27 AM Lutz Vahl <v...@chromium.org> wrote: > >> >> >> On Wed, Apr 27, 2022 at 5:14 PM Chris Harrelson <chris...@chromium.org> >> wrote: >> >>> >>> >>> On Wed, Apr 27, 2022 at 6:04 AM Lutz Vahl <v...@chromium.org> wrote: >>> >>>> Contact emails >>>> >>>> v...@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% >>>> <https://chromestatus.com/metrics/feature/popularity#V8SharedArrayBufferConstructedWithoutIsolation> >>>> page loads. >>>> >>> >>> This seems off by a factor of 10. The real number seems to be 0.036% or >>> so <https://chromestatus.com/metrics/feature/timeline/popularity/3721>, >>> 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% >> <https://chromestatus.com/metrics/feature/timeline/popularity/3721> 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? > I've shared Zoom and Google Earth already in the original post. The breakage is based on a performance drop in case pThreads are not available any more. Therefore the page (or parts of it) came unusable. > > >> >> >> >>> >>>> >>>> To overcome this limitation and make adoption possible more broadly (public >>>> feedback <https://github.com/WICG/proposals/issues/53>), we’re working >>>> on multiple solutions >>>> <https://github.com/camillelamy/explainers/blob/main/cross-origin-isolation-deployment.md> >>>> (all shared timelines are WIP): >>>> >>>> >>>> 1. >>>> >>>> COEP:credentialless <https://github.com/WICG/credentiallessness> - >>>> 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. >>>> >>>> This mechanism was shipped in M96. (Adoption is already at 0.02% >>>> <https://chromestatus.com/metrics/feature/popularity#CrossOriginEmbedderPolicyCredentialless> >>>> of main pages) >>>> >>>> >>>> 1. >>>> >>>> COI+popups (formally: COOP same-origin-allow-popups-plus-coep >>>> <https://github.com/camillelamy/explainers/blob/main/coi-with-popups.md> >>>> ) >>>> >>>> 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. >>>> >>>> >>>> >>>> 1. >>>> >>>> Anonymous iframes <https://github.com/WICG/anonymous-iframe> >>>> >>>> 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 >>>> >>>> Blink>JavaScript >>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EJavaScript> >>>> >>>> Search tags >>>> >>>> SharedArrayBuffer >>>> <https://chromestatus.com/features#tags:SharedArrayBuffer>, SAB >>>> <https://chromestatus.com/features#tags:SAB> >>>> >>>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/471 >>>> TAG review statusClosed >>>> RisksInteroperability 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% >>>> <https://chromestatus.com/metrics/feature/popularity#V8SharedArrayBufferConstructedWithoutIsolation> >>>> 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 >>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/_0MEXs6TJhg/m/QzWOGv7pAQAJ> >>>> >>>> I2S >>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/1NKvbIj3dq4/m/nLcgUst-BQAJ> >>>> >>>> Link to entry on the Chrome Platform Status >>>> >>>> https://chromestatus.com/feature/4570991992766464 >>>> >>>> -- >>>> 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+unsubscr...@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 >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH0ixBN2JhcYtpT4UYKcAfHt1e0Wz_Uxz0CkXcAntguhbmyNCA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >>> 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+unsubscr...@chromium.org. >>> 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 >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_HkK7R3fA0pyGUm8MNjbqoBR54XrQZWKeD464qb6JNhA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- > 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+unsubscr...@chromium.org. > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BN6QZsiRA7SaCapgRDnnGC7RNFZ82NRW_xadxOm4e0xNLJuNA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH0ixBO2UxMEgV2_27xnPOoXSeq-mKXFcPR%2BQ_oDQmOu1BkEtw%40mail.gmail.com.
