Intent to Ship: Opaque Response Blocking (ORB, aka CORB++) v0.2

[Daniel Vogelheim]

Contact emails

voge...@chromium.org

Specification

https://github.com/whatwg/fetch/pull/1442

Summary

Opaque Response Blocking (ORB) is a replacement for Cross-Origin Read Blocking (CORB - https://chromestatus.com/feature/5629709824032768). CORB and ORB are both heuristics that attempt to prevent cross-origin disclosure of “no-cors” subresources. This entry tracks "v0.2" of ORB - Chrome's second step towards a full ORB implementation. ORB specifies error handling for blocked resources differently from CORB: ORB raises network errors, while CORB injects an empty response. ORB "v0.1" still used CORB-style response injection. This change brings our implementation more in line with the ORB proposal, by changing the error handling of all fetches (except when initiated by a script) to be compliant with ORB. We've made a carve-out for script-initiated fetches (where we retain CORB behaviour for now) to limit compatibility risk.

Blink component

Internals>Sandbox>SiteIsolation

TAG review

None

(A TAG review of a particular aspect happened in: https://github.com/w3ctag/design-reviews/issues/618)

TAG review status

Not applicable

Risks

Interoperability and Compatibility

This release does not modify blocking behaviour, but only how a blocked resource is represented. Ideally, this change shouldn't break any existing code since any resource that loads (or gets blocked) before will continue to do so after. However, it is possible to distinguish between the different types of error handling, and it may well happen that an application inadvertently relies on blocked resources "succeeding". In our examinations so far, this chiefly concerns fetches using the `fetch()` API, where blocking with a network error results in a failed promise (instead of a success with an empty response). For this reason, we have carved out script-initiated fetches from "v0.2" and intend to handle them at a later date.

Gecko: No signal (https://bugzilla.mozilla.org/show_bug.cgi?id=1532642) In implementation.

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/64)

Web developers: No signals

Other signals: https://github.com/w3ctag/design-reviews/issues/618

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes (https://wpt.fyi/results/fetch/orb)

Flag name on chrome://flags

Finch feature name

OpaqueResponseBlockingV02

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1463725

Estimated milestones

Shipping on desktop	117
DevTrial on desktop	115

Shipping on Android	117
DevTrial on Android	115

Shipping on WebView

117

Anticipated spec changes

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5166834424217600

Links to previous Intent discussions

https://groups.google.com/a/chromium.org/g/blink-dev/c/ScjhKz3Z6U4

This intent message was generated by Chrome Platform Status.

[Yoav Weiss]

On Fri, Jul 21, 2023 at 5:53 PM 'Daniel Vogelheim' via blink-dev <blin...@chromium.org> wrote:

Contact emails

voge...@chromium.org

Specification

https://github.com/whatwg/fetch/pull/1442

Summary

Opaque Response Blocking (ORB) is a replacement for Cross-Origin Read Blocking (CORB - https://chromestatus.com/feature/5629709824032768). CORB and ORB are both heuristics that attempt to prevent cross-origin disclosure of “no-cors” subresources. This entry tracks "v0.2" of ORB - Chrome's second step towards a full ORB implementation. ORB specifies error handling for blocked resources differently from CORB: ORB raises network errors, while CORB injects an empty response. ORB "v0.1" still used CORB-style response injection. This change brings our implementation more in line with the ORB proposal, by changing the error handling of all fetches (except when initiated by a script) to be compliant with ORB. We've made a carve-out for script-initiated fetches (where we retain CORB behaviour for now) to limit compatibility risk.

Blink component

Internals>Sandbox>SiteIsolation

TAG review

None

(A TAG review of a particular aspect happened in: https://github.com/w3ctag/design-reviews/issues/618)

TAG review status

Not applicable

Risks

Interoperability and Compatibility

This release does not modify blocking behaviour, but only how a blocked resource is represented. Ideally, this change shouldn't break any existing code since any resource that loads (or gets blocked) before will continue to do so after. However, it is possible to distinguish between the different types of error handling, and it may well happen that an application inadvertently relies on blocked resources "succeeding". In our examinations so far, this chiefly concerns fetches using the `fetch()` API, where blocking with a network error results in a failed promise (instead of a success with an empty response). For this reason, we have carved out script-initiated fetches from "v0.2" and intend to handle them at a later date.

OK, so how would this change be web exposed? Are there scenarios where an "error" event would now fire instead of a "load" event?

 

--
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/CALG6KPPNdN%3DO0j0MhcfudkBtMoYnELhVRJ5nLftB8c1T1UdwbQ%40mail.gmail.com.

[Daniel Vogelheim]

On Mon, Jul 24, 2023 at 5:24 PM Yoav Weiss <yoav...@chromium.org> wrote:

On Fri, Jul 21, 2023 at 5:53 PM 'Daniel Vogelheim' via blink-dev <blin...@chromium.org> wrote:

Contact emails

voge...@chromium.org

Specification

https://github.com/whatwg/fetch/pull/1442

Summary

Opaque Response Blocking (ORB) is a replacement for Cross-Origin Read Blocking (CORB - https://chromestatus.com/feature/5629709824032768). CORB and ORB are both heuristics that attempt to prevent cross-origin disclosure of “no-cors” subresources. This entry tracks "v0.2" of ORB - Chrome's second step towards a full ORB implementation. ORB specifies error handling for blocked resources differently from CORB: ORB raises network errors, while CORB injects an empty response. ORB "v0.1" still used CORB-style response injection. This change brings our implementation more in line with the ORB proposal, by changing the error handling of all fetches (except when initiated by a script) to be compliant with ORB. We've made a carve-out for script-initiated fetches (where we retain CORB behaviour for now) to limit compatibility risk.

Blink component

Internals>Sandbox>SiteIsolation

TAG review

None

(A TAG review of a particular aspect happened in: https://github.com/w3ctag/design-reviews/issues/618)

TAG review status

Not applicable

Risks

Interoperability and Compatibility

This release does not modify blocking behaviour, but only how a blocked resource is represented. Ideally, this change shouldn't break any existing code since any resource that loads (or gets blocked) before will continue to do so after. However, it is possible to distinguish between the different types of error handling, and it may well happen that an application inadvertently relies on blocked resources "succeeding". In our examinations so far, this chiefly concerns fetches using the `fetch()` API, where blocking with a network error results in a failed promise (instead of a success with an empty response). For this reason, we have carved out script-initiated fetches from "v0.2" and intend to handle them at a later date.

OK, so how would this change be web exposed? Are there scenarios where an "error" event would now fire instead of a "load" event?

Yes, exactly. If a site is waiting for an onload event - despite not really caring about whether the load is actually meaningful, since it currently already loads empty - then it would see a behavioural change.

[Yoav Weiss]

On Mon, Jul 24, 2023 at 5:44 PM Daniel Vogelheim <voge...@google.com> wrote:

On Mon, Jul 24, 2023 at 5:24 PM Yoav Weiss <yoav...@chromium.org> wrote:

On Fri, Jul 21, 2023 at 5:53 PM 'Daniel Vogelheim' via blink-dev <blin...@chromium.org> wrote:

Contact emails

voge...@chromium.org

Specification

https://github.com/whatwg/fetch/pull/1442

Summary

Opaque Response Blocking (ORB) is a replacement for Cross-Origin Read Blocking (CORB - https://chromestatus.com/feature/5629709824032768). CORB and ORB are both heuristics that attempt to prevent cross-origin disclosure of “no-cors” subresources. This entry tracks "v0.2" of ORB - Chrome's second step towards a full ORB implementation. ORB specifies error handling for blocked resources differently from CORB: ORB raises network errors, while CORB injects an empty response. ORB "v0.1" still used CORB-style response injection. This change brings our implementation more in line with the ORB proposal, by changing the error handling of all fetches (except when initiated by a script) to be compliant with ORB. We've made a carve-out for script-initiated fetches (where we retain CORB behaviour for now) to limit compatibility risk.

Blink component

Internals>Sandbox>SiteIsolation

TAG review

None

(A TAG review of a particular aspect happened in: https://github.com/w3ctag/design-reviews/issues/618)

TAG review status

Not applicable

Risks

Interoperability and Compatibility

This release does not modify blocking behaviour, but only how a blocked resource is represented. Ideally, this change shouldn't break any existing code since any resource that loads (or gets blocked) before will continue to do so after. However, it is possible to distinguish between the different types of error handling, and it may well happen that an application inadvertently relies on blocked resources "succeeding". In our examinations so far, this chiefly concerns fetches using the `fetch()` API, where blocking with a network error results in a failed promise (instead of a success with an empty response). For this reason, we have carved out script-initiated fetches from "v0.2" and intend to handle them at a later date.

OK, so how would this change be web exposed? Are there scenarios where an "error" event would now fire instead of a "load" event?

Yes, exactly. If a site is waiting for an onload event - despite not really caring about whether the load is actually meaningful, since it currently already loads empty - then it would see a behavioural change.

Do we have stats on how often that would happen? (e.g. how often an onload event fires on an ORB empty resource?) 

[Daniel Vogelheim]

On Mon, Jul 24, 2023 at 5:55 PM Yoav Weiss <yoav...@chromium.org> wrote:

On Mon, Jul 24, 2023 at 5:44 PM Daniel Vogelheim <voge...@google.com> wrote:

On Mon, Jul 24, 2023 at 5:24 PM Yoav Weiss <yoav...@chromium.org> wrote:

On Fri, Jul 21, 2023 at 5:53 PM 'Daniel Vogelheim' via blink-dev <blin...@chromium.org> wrote:

Contact emails

voge...@chromium.org

Specification

https://github.com/whatwg/fetch/pull/1442

Summary

Opaque Response Blocking (ORB) is a replacement for Cross-Origin Read Blocking (CORB - https://chromestatus.com/feature/5629709824032768). CORB and ORB are both heuristics that attempt to prevent cross-origin disclosure of “no-cors” subresources. This entry tracks "v0.2" of ORB - Chrome's second step towards a full ORB implementation. ORB specifies error handling for blocked resources differently from CORB: ORB raises network errors, while CORB injects an empty response. ORB "v0.1" still used CORB-style response injection. This change brings our implementation more in line with the ORB proposal, by changing the error handling of all fetches (except when initiated by a script) to be compliant with ORB. We've made a carve-out for script-initiated fetches (where we retain CORB behaviour for now) to limit compatibility risk.

Blink component

Internals>Sandbox>SiteIsolation

TAG review

None

(A TAG review of a particular aspect happened in: https://github.com/w3ctag/design-reviews/issues/618)

TAG review status

Not applicable

Risks

Interoperability and Compatibility

This release does not modify blocking behaviour, but only how a blocked resource is represented. Ideally, this change shouldn't break any existing code since any resource that loads (or gets blocked) before will continue to do so after. However, it is possible to distinguish between the different types of error handling, and it may well happen that an application inadvertently relies on blocked resources "succeeding". In our examinations so far, this chiefly concerns fetches using the `fetch()` API, where blocking with a network error results in a failed promise (instead of a success with an empty response). For this reason, we have carved out script-initiated fetches from "v0.2" and intend to handle them at a later date.

OK, so how would this change be web exposed? Are there scenarios where an "error" event would now fire instead of a "load" event?

Yes, exactly. If a site is waiting for an onload event - despite not really caring about whether the load is actually meaningful, since it currently already loads empty - then it would see a behavioural change.

Do we have stats on how often that would happen? (e.g. how often an onload event fires on an ORB empty resource?) 

No. I didn't realize I could measure onload events firing specifically for ORB-blocked resources. So I unfortunately don't have that data.

The number of page views with any CORB/ORB-blocked resource in it hovers around 0.35% of page loads. That should provide an upper bound, but doesn't tell us how many of them care about the onload/onerror events. 

[Yoav Weiss]

One way to avoid a 2 months delay while we're waiting on data could be to add the use counters + a base feature and go ahead with a removal, but turning it off if we see that the actual breakage exceeds some threshold.

Thoughts?

[Dominic Farolino]

Gecko: No signal (https://bugzilla.mozilla.org/show_bug.cgi?id=1532642) In implementation.

"In implementation" and "No signal" sound a little conflicting. Is the feature definitely being implemented in Firefox? Can we file for a proper standards signal to be sure?

Specification

https://github.com/whatwg/fetch/pull/1442

It looks like the spec PR here has been dormant for something like ~9 months. Are there any plans to help drive it to the finish line, especially given the TODOs listed in the OP? How should we all think about whatever work might remain there, and possibly deviate from what Chrome plans on shipping?

Is this feature fully tested by web-platform-tests?

Yes (https://wpt.fyi/results/fetch/orb)

Just to double check, are we confident that the tests in that directory assert what the spec PR currently requires? I only ask because the spec has seemed quiet for a while (as mentioned above) and that makes it easy for things to accidentally get out of sync.

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

[Olli Pettay]

Gecko has a variant of ORB enabled currently in early beta and earlier https://bugzilla.mozilla.org/show_bug.cgi?id=1821682

We had full ORB, but had to relax the rules a bit similarly to what Blink has done, if I understood correctly.

And there is also an experiment ongoing.

But I can't recall the details whether Gecko's implementation matches Blink v0.2 exactly (and some folks are on vacation atm so I can't ask right now).

-Olli

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAP-uykDddQpLPP%3DehPYSDdTVLi1qxMaOtsU5JXd9H%3DcLJRD5%2Bg%40mail.gmail.com.

--

-Olli

[Daniel Vogelheim]

Turning this on via server-side experiments (and thus being able to turn it off quickly on problem reports) is easy to do. It might make sense to have it enabled on beta 50/50 for a while, to see whether anyone notices.

I find it surprisingly hard to implement the use counters: The code that knows the network status (and thus _why_ a response might be empty) is separated by several layers from the code that knows the element and whether it has any event handlers. :-/

[Daniel Vogelheim]

On Tue, Jul 25, 2023 at 6:00 PM Olli Pettay <olli....@gmail.com> wrote:

Gecko has a variant of ORB enabled currently in early beta and earlier https://bugzilla.mozilla.org/show_bug.cgi?id=1821682

We had full ORB, but had to relax the rules a bit similarly to what Blink has done, if I understood correctly.

And there is also an experiment ongoing.

But I can't recall the details whether Gecko's implementation matches Blink v0.2 exactly (and some folks are on vacation atm so I can't ask right now).

Thanks for the update!

I don't think it's an exact match; for example, we don't deal with JS/JSON yet. (That should be the next step for us.)

[Yoav Weiss]

I agree that piping that information over from the browser to the renderer would be an overkill (and may have security implications on its own). In that case, a careful Finch may be sufficient.

One last thought - maybe it's possible to report the information to UKM from both sides of the code, and join it at analysis time? (if that's not too complex)

[Daniel Vogelheim]

I've now landed the usecounter CL. What I'd like to do is: Enable the feature on beta now and wait for numbers to arrive from the usecounters. This would give us two signals on compatibility.

According to the current schedule, the counters will make it into 118.

[Chris Harrelson]

LGTM1 to turn it on in M118 beta and report back to this group about use counter results/bugs reported on beta before it reaches stable.

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

[Yoav Weiss]

LGTM2

[Mike Taylor]

LGTM3

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

[Dominic Farolino]

It looks like the spec PR here has been dormant for something like ~9 months. Are there any plans to help drive it to the finish line, especially given the TODOs listed in the OP? How should we all think about whatever work might remain there, and possibly deviate from what Chrome plans on shipping?

Hello, I'm still a little curious if there are plans to advance the spec PR anymore, so that it matches what we're attempting to ship? Or is there something new that has superseded that work, making it (and my question) obsolete?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3ccd3d3a-ca7d-4df1-aa4c-69d62279d924%40chromium.org.

[Daniel Vogelheim]

On Tue, Aug 22, 2023 at 5:02 PM Dominic Farolino <d...@chromium.org> wrote:

It looks like the spec PR here has been dormant for something like ~9 months. Are there any plans to help drive it to the finish line, especially given the TODOs listed in the OP? How should we all think about whatever work might remain there, and possibly deviate from what Chrome plans on shipping?

Hello, I'm still a little curious if there are plans to advance the spec PR anymore, so that it matches what we're attempting to ship? Or is there something new that has superseded that work, making it (and my question) obsolete?

The spec PR is still the latest.

We had settled on a gradual CORB -> ORB transition, where this is the 2nd step. We initially had quite a few carveouts due to compat concerns, and we're working through them with this series of changes. I still hope that in the end we'll have a pretty good approximation of ORB and won't actually have many change requests to the current proposal. The thing is that right now, I wouldn't know what to ask for. So my plan is to keep implementing the proposed spec until I hit roadblocks, and then go back to the proposal.

One new thing that may change this dynamic a bit is that FF is also working on it (see Olli's post). But the info I've got so far is that their carve-outs are similar to ours, except they've implemented the JS/JSON-distinguisher step. Which I'd like to be our next step, "v0.3". The end goal is certainly that the two implementations & the spec should match exactly.

[Daniel Vogelheim]

Hello all, it's been a while.

On Wed, Aug 16, 2023 at 7:23 PM Chris Harrelson <chri...@chromium.org> wrote:

LGTM1 to turn it on in M118 beta and report back to this group about use counter results/bugs reported on beta before it reaches stable.

As requested, I have added use counters to measure ORB-blocked resources on elements (script and img/video/media) with event handlers. On current stable, I get this: (source)

-  0.006% of page loads have a script or media element with an event handler (and thus potential compatibility impact from this change; although we don't know what the impact would be)

- 0.0075 % of page loads have a script or media element without any event handlers (and thus guaranteed without compatibility impact from this change)

- The majority of pages with any event handler seem to have both handlers - onload and onerror - set.

I'll note that the sum of those (with any + without any) are much lower than the numbers I previously reported in this thread. I believe that's because of 1, here we only count specific HTML elements (but not e.g. the ping attribute on links), and 2, the carveout for fetch()-initiated requests. The previously reported metric counted ORB-related blocks across all page-initiated responses, regardless of whether it might be script-visible or not.

Daniel  

[Chris Harrelson]

These numbers sound good to me. I have no concerns with continuing the rollout, and you don't need any more approvals from us to continue.

Thanks for reporting back.

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