Hi API Owners, This is an update on the current status and the plan forward.
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% <https://chromestatus.com/metrics/feature/popularity#V8SharedArrayBufferConstructedWithoutIsolation> . To overcome this limitation and make adoption possible, we’re working on multiple solutions <https://github.com/camillelamy/explainers/blob/main/cross-origin-isolation-deployment.md> : 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. 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 <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 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 <https://github.com/camillelamy/explainers/blob/main/anonymous_iframes.md> 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. 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. Cheers, Lutz On Tue, Aug 31, 2021 at 3:50 PM Lutz Vahl <[email protected]> wrote: > Hi Steve, > > Thanks for letting us know! We're aware that COEP adoption is sometimes > blocked by 3P content and are working on credentialess and anonymous > iframes > <https://github.com/camillelamy/explainers/blob/master/anonymous_iframes.md> > to > unblock this. > Feel free to submit credentials feedback > <https://developer.chrome.com/origintrials/#/view_trial/3036552048754556929> > letting > us know more details about your issues. > > The plan is that the SAB reverse OT will be in place as long as the COEP > adoption is blocked as this is for now the only solution to be able to use > SAB in such cases. > > @API Owners: I'll ping this thread again later this week as soon as the > anonymous iframe launch plan is finalized asking for an SAB reverse OT > extension. > > > On Tue, Aug 31, 2021 at 2:41 PM Steve Hoek <[email protected]> wrote: > >> Hi... great work on this restriction for SABs. Is there any possibility >> that the OT will be extended past M96? >> >> Unfortunately, due to the way our solution (an interior design tool with >> 3D rendering) is provided to third party OEMs (eg: IKEA, Home Depot), we >> have had to resort to using the OT for now as we work through the issues we >> uncovered with adding full CORP support to all of our subdomains and the >> subdomains of our OEM customers (which is where it is most challenging for >> us since these third parties don't want to add CORP to their resources, >> understandably). >> >> We are tracking the new "credentialess" feature to enable us to fully >> CORP isolate the first and third party content on our site, but it is not >> ready yet and we cannot have the OT end before it is. >> >> Thoughts? >> >> >> On Thursday, May 6, 2021 at 11:23:19 AM UTC-4 Chris Harrelson wrote: >> >>> Sounds ok to me, thanks for updating the thread. >>> >>> On Thu, May 6, 2021 at 2:56 AM Lutz Vahl <[email protected]> wrote: >>> >>>> Hi fellow API owners, >>>> >>>> Unfortunately we’ve received last minute feedback from developers that >>>> there are limitations and issues using the provided reverse origin trial ( >>>> https://crbug.com/1204271 & https://crbug.com/1201589). >>>> One of our goals for this migration is a smooth transition, therefore >>>> we’ve decided to adjust the timeline of this change and will support the >>>> reverse origin trial via <meta> tag as well. >>>> >>>> The usage of SharedArrayBuffers in none cross-origin isolated sites >>>> will be restricted in *M92* - one milestone later as requested >>>> earlier. In case sites already registered for the origin trial and are >>>> serving the token, those will be ignored. >>>> >>>> In addition we’re moving the reverse OT for SABs as well starting in >>>> *M92* and ending in M96 (unchanged). >>>> >>>> >>>> >>>> On Thu, Apr 29, 2021 at 10:07 PM Chris Harrelson <[email protected]> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Fri, Apr 16, 2021 at 4:49 AM Lutz Vahl <[email protected]> wrote: >>>>> >>>>>> Hi fellow API owners, >>>>>> >>>>>> We've received tons of feedback based on our SAB restriction >>>>>> outreach. Working with partners internally and externally, we've learned >>>>>> that there are a few workflows we don't yet have a good story for >>>>>> supporting. E.g. COEP adoption is nearly impossible in case 3P content is >>>>>> provided by users or out of control of the main page, and popup based >>>>>> OAuth >>>>>> flows are not yet supported in cross-origin isolated contexts. >>>>>> >>>>>> credentialless <https://github.com/mikewest/credentiallessness/> >>>>>> (Planned for M93) - >>>>>> >>>>>> We're looking at a credentialless mode. This allows the cross-origin >>>>>> frame to be embedded even without the setting of headers, but all >>>>>> requests >>>>>> within the frame are made without credentials. This mitigates the effect >>>>>> of >>>>>> a Spectre attack in non-OOPIF browsers (since all resources are >>>>>> unpersonalized, it doesn't matter if they leak). >>>>>> >>>>>> CrossOriginIsolated for COOP: same-origin-allow-popups (Planned for >>>>>> M94) >>>>>> >>>>>> Extending CrossOriginIsolated to COOP: same-origin-allow-popups >>>>>> enabling popup flow based use cases. >>>>>> >>>>>> To not break those use cases in the meantime, we're planning to >>>>>> extend the reverse origin trial (currently planned end M93) until those >>>>>> changes are made and give sites 2x milestones to adapt before ending the >>>>>> reverse OT for SABs (M96). >>>>>> >>>>> >>>>> Hi, >>>>> >>>>> This plan LGTM. >>>>> >>>>> >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Lutz >>>>>> >>>>>> >>>>>> On Fri, Nov 20, 2020 at 8:34 PM Daniel Bratell <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Something I took into consideration before adding my lgtm is that >>>>>>> this feature and code has been in flux all since spectre and meltdown >>>>>>> became publicly known. As frustrating as that must be as a web >>>>>>> developer, >>>>>>> it also means that the code Chromium encounters on the web is newer and >>>>>>> more likely to still be in development. >>>>>>> >>>>>>> This change is also about aligning all browsers to do the same >>>>>>> thing, and wherever the deprecation warning triggers, the code will >>>>>>> already >>>>>>> be broken in other engines. That also increases the likeliness that web >>>>>>> developers will fix the code rather than leaving it in the less secure >>>>>>> state. >>>>>>> >>>>>>> Still, Rick has a good point. We do not want a situation where we >>>>>>> end up giving developers warning fatigue, and if that seems probable, we >>>>>>> need to find alternative solutions. >>>>>>> >>>>>>> /Daniel >>>>>>> On 2020-11-20 09:19, Lutz Vahl wrote: >>>>>>> >>>>>>> Hi Rick, >>>>>>> >>>>>>> thanks for the feedback, see my comments below. >>>>>>> >>>>>>> On Thu, Nov 19, 2020 at 8:21 PM Rick Byers <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Aligning with other browsers and across operating systems >>>>>>>> definitely seems urgent and important to me. LGTM4 >>>>>>>> >>>>>>>> I am, however, a little worried that this thread sounds a little >>>>>>>> bit like past "hopeful deprecation" efforts where we add warnings to >>>>>>>> billions of page loads and then revisit once we realize that warnings >>>>>>>> are >>>>>>>> not sufficient to get usage down to a level we can break. I also worry >>>>>>>> a >>>>>>>> lot about warning blindness when we start doing warnings at such a high >>>>>>>> level. In general our experience is that warnings are not a >>>>>>>> particularly >>>>>>>> powerful way of reducing usage. >>>>>>>> >>>>>>> That's right. Warnings are one part of the puzzle to raise awareness >>>>>>> of the change! In addition blog Posts, videos, virtual conference talks >>>>>>> etc. are released or in the making. >>>>>>> >>>>>>> Should we perhaps be looking at UKM data and doing targeted outreach >>>>>>>> to the top sites and see if we can't get the UseCounter down to >>>>>>>> something >>>>>>>> not so massive before introducing a high-prevalence warning? >>>>>>>> >>>>>>> >>>>>>> We do have UKMs in place and are using them currently for success >>>>>>> tracking. We're not able to reach out to all sites currently using SABs >>>>>>> (for obvious reasons), but I'll verify if an outreach to the top % pages >>>>>>> can be done in the near future. >>>>>>> >>>>>>>> >>>>>>>> Rick >>>>>>>> >>>>>>>> On Thu, Nov 19, 2020 at 11:26 AM Daniel Bratell <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> LGTM3 - May the Use Counters be with you >>>>>>>>> >>>>>>>>> /Daniel >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2020-11-19 11:00, Manuel Rego Casasnovas wrote: >>>>>>>>> > LGTM2 >>>>>>>>> > >>>>>>>>> > We in Igalia are very happy to see improvements to >>>>>>>>> interoperability with >>>>>>>>> > other browsers, even if it requires working through difficult >>>>>>>>> compat >>>>>>>>> > issues like this one. >>>>>>>>> > >>>>>>>>> > On 19/11/2020 10:29, Yoav Weiss wrote: >>>>>>>>> >> LGTM1 >>>>>>>>> >> >>>>>>>>> >> The plan sounds reasonable, and while current usage is not low, >>>>>>>>> carrots >>>>>>>>> >> (Android + Firefox) and a deadline may be able to drive it down. >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> On Thu, Nov 19, 2020 at 10:04 AM Lutz Vahl <[email protected] >>>>>>>>> >> <mailto:[email protected]>> wrote: >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> On Thu, Nov 19, 2020 at 9:38 AM Yoav Weiss <[email protected] >>>>>>>>> >> <mailto:[email protected]>> wrote: >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> On Thu, Nov 19, 2020 at 9:29 AM Lutz Vahl < >>>>>>>>> [email protected] >>>>>>>>> >> <mailto:[email protected]>> wrote: >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> On Thu, Nov 19, 2020 at 7:29 AM Yoav Weiss < >>>>>>>>> [email protected] >>>>>>>>> >> <mailto:[email protected]>> wrote: >>>>>>>>> >> >>>>>>>>> >> The overall plan sounds reasonable to me. >>>>>>>>> >> Do you have use counters in place for current >>>>>>>>> usage? >>>>>>>>> >> >>>>>>>>> >> Yes, SAB use counters are >>>>>>>>> >> available. V8SharedArrayBufferConstructed >>>>>>>>> >> < >>>>>>>>> https://chromestatus.com/metrics/feature/popularity#V8SharedArrayBufferConstructed >>>>>>>>> > measured >>>>>>>>> >> all SAB usage until M87. Starting M87 ONLY gated >>>>>>>>> usage is >>>>>>>>> >> >>>>>>>>> counted. V8SharedArrayBufferConstructedWithoutIsolation >>>>>>>>> >> < >>>>>>>>> https://chromestatus.com/metrics/feature/popularity#V8SharedArrayBufferConstructedWithoutIsolation >>>>>>>>> > was >>>>>>>>> >> added in M87 to measure usage without isolated >>>>>>>>> (this usage >>>>>>>>> >> is planned to be blocked) >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> The latter is rather high at 1.6%... >>>>>>>>> >> >>>>>>>>> >> That's right! We're targeting all current users explicitly >>>>>>>>> with >>>>>>>>> >> deprecation warnings and will reach out to the top % sites >>>>>>>>> using >>>>>>>>> >> SABs to do our best to bring this number down until May >>>>>>>>> 2021. >>>>>>>>> >> We think that the Firefox and Chrome on Android reablement >>>>>>>>> of SABs >>>>>>>>> >> gated behind COI will have a positive impact as well. >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> Any sense regarding how much of that usage >>>>>>>>> will have a >>>>>>>>> >> hard time adapting to the crossOrigin isolation >>>>>>>>> >> requirements? (e.g. content that incorporates >>>>>>>>> >> credentialed and sensitive information in the >>>>>>>>> iframes it >>>>>>>>> >> loads) >>>>>>>>> >> >>>>>>>>> >> It all depends on the architecture of the app. >>>>>>>>> Facebook & >>>>>>>>> >> Twitter managed to adopt COOP/COEP very quickly. >>>>>>>>> We do see >>>>>>>>> >> some complexity in heavily integrated apps as all >>>>>>>>> 3P >>>>>>>>> >> dependencies need to be marked emaddebal via CORP >>>>>>>>> or CORS >>>>>>>>> >> and in case 3P is loaded into iframes even via >>>>>>>>> COEP. >>>>>>>>> >> This is why we send out the I2S early and are >>>>>>>>> planning lot's >>>>>>>>> >> of comms to inform developers about the change and >>>>>>>>> how to adapt. >>>>>>>>> >> Last but not least we've included the reverse OT >>>>>>>>> to the >>>>>>>>> >> rollout plan to be able to extend the migration >>>>>>>>> period for >>>>>>>>> >> some apps if needed. We're checking the SAB use >>>>>>>>> counters >>>>>>>>> >> linked above continuously to monitor the adoption >>>>>>>>> and to be >>>>>>>>> >> able to ramp up more comms if needed. >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> On Wed, Nov 18, 2020 at 4:56 PM Lutz Vahl >>>>>>>>> >> <[email protected] <mailto:[email protected]>> >>>>>>>>> wrote: >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> Contact emails >>>>>>>>> >> >>>>>>>>> >> [email protected] <mailto: >>>>>>>>> [email protected]>, >>>>>>>>> >> [email protected] <mailto: >>>>>>>>> [email protected]>, >>>>>>>>> >> [email protected] <mailto: >>>>>>>>> [email protected]> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> 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 >>>>>>>>> >> will be restricted to cross-origin isolated >>>>>>>>> >> environments, matching the behavior we've >>>>>>>>> recently >>>>>>>>> >> shipped on Android and Firefox. We're >>>>>>>>> aiming for >>>>>>>>> >> Chrome 91 to make this change. >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> This I2S will gate the usage of SABs on >>>>>>>>> Desktop >>>>>>>>> >> behind COOP/COEP and is a follow up on >>>>>>>>> ‘Planning >>>>>>>>> >> isolation requirements (COOP/COEP) for >>>>>>>>> >> SharedArrayBuffer >>>>>>>>> >> < >>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/_0MEXs6TJhg/m/QzWOGv7pAQAJ >>>>>>>>> >’. >>>>>>>>> >> Only sites opt-in to cross-origin isolated >>>>>>>>> will be >>>>>>>>> >> able to use the feature. This change is >>>>>>>>> targeted for >>>>>>>>> >> Chrome 91 (Release planned 2021-05-25) to >>>>>>>>> align >>>>>>>>> >> Chrome with other browsers and all >>>>>>>>> platforms. >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> Feature in detail >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> SharedArrayBuffers can be used to make >>>>>>>>> >> high-resolution timers. High-resolution >>>>>>>>> timers >>>>>>>>> >> simplify Spectre attacks on cross-origin >>>>>>>>> resources. >>>>>>>>> >> To mitigate Spectre attacks, all browser >>>>>>>>> vendors >>>>>>>>> >> disabled SharedArrayBuffers in January >>>>>>>>> 2018. Chrome >>>>>>>>> >> M67 re-enabled SharedArrayBuffers on >>>>>>>>> platforms >>>>>>>>> >> (Desktop) where Site Isolation is >>>>>>>>> supported. >>>>>>>>> >> ‘crossOriginIsolated’ allows us to enable >>>>>>>>> the >>>>>>>>> >> isolation on other devices and platforms. >>>>>>>>> Therefore >>>>>>>>> >> we’re planning to align the usage of SABs >>>>>>>>> across all >>>>>>>>> >> platforms gated behind >>>>>>>>> ‘crossOriginIsolated’. >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> Timeline and plan >>>>>>>>> >> >>>>>>>>> >> _Right now_: Add deprecation warnings and >>>>>>>>> metrics, >>>>>>>>> >> continue to work with developers and >>>>>>>>> provide >>>>>>>>> >> guidance on how to migrate. Probably add an >>>>>>>>> >> enterprise policy of some sort as an >>>>>>>>> opt-out. >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> _After the holiday season (Jan 2021_): >>>>>>>>> More outreach >>>>>>>>> >> to current users of SABs which need to >>>>>>>>> opt-in to >>>>>>>>> >> crossOriginIsolated via COOP/COEP headers >>>>>>>>> to >>>>>>>>> >> continue to use this API starting from >>>>>>>>> M91. For >>>>>>>>> >> testing purposes a flag will be added to >>>>>>>>> gate the >>>>>>>>> >> API already behind a flag. We think about >>>>>>>>> gating the >>>>>>>>> >> API on pre-release channels (M89 or M90) >>>>>>>>> earlier as >>>>>>>>> >> on stable. >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> _M91_: Gate by default, assuming we can >>>>>>>>> drive >>>>>>>>> >> numbers down to reasonable levels and >>>>>>>>> start a >>>>>>>>> >> reverse origin trial to allow developers >>>>>>>>> to use SABs >>>>>>>>> >> in none cross-origin isolated environments. >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> _M93_: Planned end of the reverse origin >>>>>>>>> trial in >>>>>>>>> >> case the numbers are reasonable down. If >>>>>>>>> there is >>>>>>>>> >> the need we can extend the OT >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> 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 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. These >>>>>>>>> >> developers are already impacted by the >>>>>>>>> changes >>>>>>>>> >> shipping in Firefox, and it's important >>>>>>>>> that we >>>>>>>>> >> shift our implementation to match theirs >>>>>>>>> as quickly >>>>>>>>> >> as is reasonable in order to ensure that >>>>>>>>> developers >>>>>>>>> >> create isolated environments to protect >>>>>>>>> their users >>>>>>>>> >> from attack. We aim to mitigate these >>>>>>>>> risks by >>>>>>>>> >> adopting a longer-than-usual depreciation >>>>>>>>> period >>>>>>>>> >> with console warnings/issues, along with >>>>>>>>> >> communication via other channels. >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> Gecko: Shipped/Shipping >>>>>>>>> >> ( >>>>>>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1312446) >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> WebKit: No signals >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> Web developers: Positive >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> Will this feature be supported on >>>>>>>>> all six >>>>>>>>> >> Blink platforms (Windows, Mac, >>>>>>>>> Linux, Chrome >>>>>>>>> >> OS, Android, and Android WebView)? >>>>>>>>> >> >>>>>>>>> >> No - >>>>>>>>> >> >>>>>>>>> >> Android was shipped: >>>>>>>>> >> >>>>>>>>> https://chromestatus.com/feature/5171863141482496 >>>>>>>>> >> >>>>>>>>> >> Android WebView is currently not >>>>>>>>> supporting COOP, >>>>>>>>> >> but SABs never worked on WebView >>>>>>>>> >> >>>>>>>>> >> All other platforms are affected by this >>>>>>>>> change >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> Is this feature fully tested by >>>>>>>>> >> web-platform-tests >>>>>>>>> >> < >>>>>>>>> https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md >>>>>>>>> >? >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> For SABs >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> https://github.com/tc39/test262/tree/master/test/built-ins/SharedArrayBuffer >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> https://github.com/tc39/test262/tree/master/test/built-ins/Atomics >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> For gated SAB usage on Android/Desktop >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/web_tests/external/wpt/html/infrastructure/safe-passing-of-structured-data/shared-array-buffers/no-coop-coep.https.any.js >>>>>>>>> >> >>>>>>>>> >> Addition test might get added during the >>>>>>>>> development >>>>>>>>> >> of the Desktop gating >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> Tracking bug >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1144104 >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> Old bug to enable them on Desktop with site >>>>>>>>> >> isolation: >>>>>>>>> >> >>>>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=709179 >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> 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 >>>>>>>>> > >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> Link to entry on the Chrome >>>>>>>>> Platform Status >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> https://chromestatus.com/feature/4570991992766464 >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> (Android one: >>>>>>>>> >> >>>>>>>>> https://chromestatus.com/feature/5171863141482496) >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> This intent message was generated by >>>>>>>>> Chrome Platform >>>>>>>>> >> Status <https://www.chromestatus.com/>. >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> Lutz Vahl >>>>>>>>> >> >>>>>>>>> >> Technical Program Manager >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> Google Germany GmbH >>>>>>>>> >> >>>>>>>>> >> Erika-Mann-Strasse 36 >>>>>>>>> >> >>>>>>>>> >> 80636 München >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> Geschäftsführer: Paul Manicle, Halimah >>>>>>>>> DeLaine Prado >>>>>>>>> >> >>>>>>>>> >> Registergericht und -nummer: Hamburg, HRB >>>>>>>>> 86891 >>>>>>>>> >> >>>>>>>>> >> Sitz der Gesellschaft: Hamburg >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> Diese E-Mail ist vertraulich. Falls Sie >>>>>>>>> diese >>>>>>>>> >> fälschlicherweise erhalten haben sollten, >>>>>>>>> leiten Sie >>>>>>>>> >> diese bitte nicht an jemand anderes >>>>>>>>> weiter, löschen >>>>>>>>> >> Sie alle Kopien und Anhänge davon und >>>>>>>>> lassen Sie >>>>>>>>> >> mich bitte wissen, dass die E-Mail an die >>>>>>>>> falsche >>>>>>>>> >> Person gesendet wurde. >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> This e-mail is confidential. If you >>>>>>>>> received this >>>>>>>>> >> communication by mistake, please don't >>>>>>>>> forward it to >>>>>>>>> >> anyone else, please erase all copies and >>>>>>>>> >> attachments, and please let me know that >>>>>>>>> it has gone >>>>>>>>> >> to the wrong person. >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> -- >>>>>>>>> >> 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 >>>>>>>>> >> [email protected] >>>>>>>>> >> <mailto:[email protected]>. >>>>>>>>> >> To view this discussion on the web visit >>>>>>>>> >> >>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH0ixBNHgCAdCAorgU_qPcjTneVhpMvtQB6nhEzSOz%2BMBrJ-YA%40mail.gmail.com >>>>>>>>> >> < >>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH0ixBNHgCAdCAorgU_qPcjTneVhpMvtQB6nhEzSOz%2BMBrJ-YA%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 >>>>>>>>> >> [email protected] >>>>>>>>> >> <mailto:[email protected]>. >>>>>>>>> >> To view this discussion on the web visit >>>>>>>>> >> >>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEg%2BKRCFrQ-pLfWabAJd_09U-eCbf46mkEhX0Bd1AXG%3DaQ%40mail.gmail.com >>>>>>>>> >> < >>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEg%2BKRCFrQ-pLfWabAJd_09U-eCbf46mkEhX0Bd1AXG%3DaQ%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 [email protected] >>>>>>>>> >> <mailto:[email protected]>. >>>>>>>>> >> To view this discussion on the web visit >>>>>>>>> >> >>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEjX5tw2EjpOrHwr%2BeSzQWGT7szz1PpnjHbQsjK3gdxMQA%40mail.gmail.com >>>>>>>>> >> < >>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEjX5tw2EjpOrHwr%2BeSzQWGT7szz1PpnjHbQsjK3gdxMQA%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 [email protected]. >>>>>>>>> To view this discussion on the web visit >>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7d7d2060-efe4-bd7e-87c7-fd8af21b5e5b%40gmail.com >>>>>>>>> . >>>>>>>>> >>>>>>>> -- >>>>>>>> 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 [email protected]. >>>>>>>> To view this discussion on the web visit >>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9idBpi0nF9aZPDM5xbBvXbdjv9EV3c2Sb%2Bp3HK_utcCQ%40mail.gmail.com >>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9idBpi0nF9aZPDM5xbBvXbdjv9EV3c2Sb%2Bp3HK_utcCQ%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 [email protected]. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH0ixBOwUUhY93WEJcXj4OvS%2B7DKyRbQOQbrWDn9LWeibaBJBg%40mail.gmail.com >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH0ixBOwUUhY93WEJcXj4OvS%2B7DKyRbQOQbrWDn9LWeibaBJBg%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 [email protected]. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_frHFHac1DFLWgjCECFJRT72LMvM%3DuMb4gysCcSwEm-g%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_frHFHac1DFLWgjCECFJRT72LMvM%3DuMb4gysCcSwEm-g%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 [email protected]. >>>> >>> To view this discussion on the web visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH0ixBOf4EXV3j7_7e2GhigWg4CWbPn_rbgONc7Va6NjojEi_w%40mail.gmail.com >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH0ixBOf4EXV3j7_7e2GhigWg4CWbPn_rbgONc7Va6NjojEi_w%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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH0ixBMifOYpxC9Mj2ZhKxoHAh0_7qLCGkQ93qS4T-EJUCH5kw%40mail.gmail.com.
