Intent to Ship: Restriction on SharedArrayBuffers (SABs)

[Lutz Vahl]

Contact emails

va...@chromium.org, bbu...@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 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’. 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

Search tags

SharedArrayBuffer, 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?

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

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.

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.

[Domenic Denicola]

Very excited to see this move toward better interoperability and security.

From: Lutz Vahl <va...@chromium.org>

> Specification
> https://tc39.github.io/ecma262/#sec-sharedarraybuffer-objects

FWIW the specification for the restriction you're specifically implementing is the one introduced in https://github.com/whatwg/html/pull/4734 , i.e. roughly:

- https://html.spec.whatwg.org/#structuredserializeinternal:issharedarraybuffer
- https://html.spec.whatwg.org/#realms-settings-objects-global-objects:cross-origin-isolated

[Hongchan Choi]

> We expect this change to negatively impact developers using `SharedArrayBuffer` today.

Can you elaborate on this? What would be the example of use cases that may be impacted by this change? A lot of Web Audio apps are using SAB for the performant audio processing, so I would like to understand the scope and the scale of this change.

Cheers,

-Hongchan

--
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/MN2PR13MB361352296586E66765BAA00FDFE10%40MN2PR13MB3613.namprd13.prod.outlook.com.

[Yoav Weiss]

The overall plan sounds reasonable to me.

Do you have use counters in place for current usage?

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)

--
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/CAH0ixBNHgCAdCAorgU_qPcjTneVhpMvtQB6nhEzSOz%2BMBrJ-YA%40mail.gmail.com.

[Lutz Vahl]

On Wed, Nov 18, 2020 at 5:49 PM Hongchan Choi <hong...@chromium.org> wrote:

> We expect this change to negatively impact developers using `SharedArrayBuffer` today.

Can you elaborate on this? What would be the example of use cases that may be impacted by this change? A lot of Web Audio apps are using SAB for the performant audio processing, so I would like to understand the scope and the scale of this change.

Sure! SharedArrayBuffer has been available only in Chrome since the spectre vulnerabilities have been identified. Since COOP / COEP are spec'ed out and shipped in Firefox and Chrome this year, we'd like to align the usage of SABs to the platform. This is why SAB usage is planned to be restricted to cross origin isolated contexts.

All current users of SABs need to gate the usage behind cross origin isolation by sending COOP/COEP headers on their main site. They need to do this to enable their services to be used across the platform and continue to use SABs in Chrome starting in M91.

As soon as the apps opt in via COOP/COEP they can continue to use SABs. No additional restrictions are part of this intent.

Cheers,

-Hongchan

On Wed, Nov 18, 2020 at 8:41 AM Domenic Denicola <d...@domenic.me> wrote:

Very excited to see this move toward better interoperability and security.

From: Lutz Vahl <va...@chromium.org>

> Specification
> https://tc39.github.io/ecma262/#sec-sharedarraybuffer-objects

FWIW the specification for the restriction you're specifically implementing is the one introduced in https://github.com/whatwg/html/pull/4734 , i.e. roughly:

- https://html.spec.whatwg.org/#structuredserializeinternal:issharedarraybuffer
- https://html.spec.whatwg.org/#realms-settings-objects-global-objects:cross-origin-isolated

--
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/MN2PR13MB361352296586E66765BAA00FDFE10%40MN2PR13MB3613.namprd13.prod.outlook.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 blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGJqXNubviyhHw3uH3G8oaRehQU94%3DjOBjzFKp8m%2BuG%2BAZxOpg%40mail.gmail.com.

[Lutz Vahl]

On Thu, Nov 19, 2020 at 7:29 AM Yoav Weiss <yo...@yoav.ws> 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 measured all SAB usage until M87. Starting M87 ONLY gated usage is counted. V8SharedArrayBufferConstructedWithoutIsolation was added in M87 to measure usage without isolated (this usage is planned to be blocked)

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.

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.

[Yoav Weiss]

On Thu, Nov 19, 2020 at 9:29 AM Lutz Vahl <va...@chromium.org> wrote:

On Thu, Nov 19, 2020 at 7:29 AM Yoav Weiss <yo...@yoav.ws> 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 measured all SAB usage until M87. Starting M87 ONLY gated usage is counted. 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%...

[Lutz Vahl]

On Thu, Nov 19, 2020 at 9:38 AM Yoav Weiss <yo...@yoav.ws> wrote:

On Thu, Nov 19, 2020 at 9:29 AM Lutz Vahl <va...@chromium.org> wrote:

On Thu, Nov 19, 2020 at 7:29 AM Yoav Weiss <yo...@yoav.ws> 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 measured all SAB usage until M87. Starting M87 ONLY gated usage is counted. 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.

[Yoav Weiss]

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.

[Manuel Rego Casasnovas]

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 <va...@chromium.org
> <mailto:va...@chromium.org>> wrote:
>
>
>
> On Thu, Nov 19, 2020 at 9:38 AM Yoav Weiss <yo...@yoav.ws
> <mailto:yo...@yoav.ws>> wrote:
>
>
>
> On Thu, Nov 19, 2020 at 9:29 AM Lutz Vahl <va...@chromium.org
> <mailto:va...@chromium.org>> wrote:
>
>
>
> On Thu, Nov 19, 2020 at 7:29 AM Yoav Weiss <yo...@yoav.ws
> <mailto:yo...@yoav.ws>> 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

> <va...@chromium.org <mailto:va...@chromium.org>> wrote:
>
>
> Contact emails
>
> va...@chromium.org <mailto:va...@chromium.org>,
> bbu...@chromium.org <mailto:bbu...@chromium.org>,
> cl...@chromium.org <mailto: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
> 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>

> <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
> blink-dev+...@chromium.org

> <mailto:blink-dev+...@chromium.org>.

> 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
> blink-dev+...@chromium.org

> <mailto:blink-dev+...@chromium.org>.

> 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 blink-dev+...@chromium.org

> <mailto:blink-dev+...@chromium.org>.

> 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>.

[Daniel Bratell]

LGTM3 - May the Use Counters be with you

/Daniel

[Rick Byers]

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. 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?

Rick

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/7d7d2060-efe4-bd7e-87c7-fd8af21b5e5b%40gmail.com.

[Lutz Vahl]

Hi Rick,

thanks for the feedback, see my comments below.

On Thu, Nov 19, 2020 at 8:21 PM Rick Byers <rby...@chromium.org> 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.   

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.

[Daniel Bratell]

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

[Lutz Vahl]

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 (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).

Cheers,

Lutz

[Chris Harrelson]

On Fri, Apr 16, 2021 at 4:49 AM Lutz Vahl <va...@chromium.org> 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 (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.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH0ixBOwUUhY93WEJcXj4OvS%2B7DKyRbQOQbrWDn9LWeibaBJBg%40mail.gmail.com.

[Lutz Vahl]

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).

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.

[Chris Harrelson]

Sounds ok to me, thanks for updating the thread.

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.

[Lutz Vahl]

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 to unblock this.

Feel free to submit credentials feedback 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 <steve...@gmail.com> 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?

[Steve Hoek]

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:

[Lutz Vahl]

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%.

To overcome this limitation and make adoption possible, we’re working on multiple solutions:

1. COEP:credentialless - 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

2. 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 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.

3. Anonymous iframes

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

[Yoav Weiss]

I appreciate y'all working with the community based on their feedback, and coming up with APIs that will enable folks to migrate to COI. Given that, it's understandable that designing, specifying, shipping and getting adoption of these APIs requires time. 

Can you send an intent to extend the deprecation trial? That would enable us to keep track of it. I also suspect that since M92-M103 is a bit on the longer side, it may require 3 LGTMs.

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.

[Lutz Vahl]

Thanks for the feedback, Yoav. Sure, I'll kick off a new thread asap.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfX3Qsb3eBdN2BXj8z4Gva0cCv%3D1Aqntqix9Z76dYoWKUw%40mail.gmail.com.