[blink-dev] Intent to Ship: Opaque Response Blocking (ORB, aka CORB++) v0.2

['Daniel Vogelheim' via blink-dev]

Contact emailsvogelh...@chromium.org

Specificationhttps://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 componentInternals>Sandbox>SiteIsolation


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

TAG review statusNot 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 nameOpaqueResponseBlockingV02

Requires code in //chrome?False

Tracking bughttps://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 changesNone

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
.

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

Re: [blink-dev] Intent to Ship: Opaque Response Blocking (ORB, aka CORB++) v0.2

[Yoav Weiss]

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

> Contact emailsvogelh...@chromium.org
>
> Specificationhttps://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 componentInternals>Sandbox>SiteIsolation
> 
>
> TAG reviewNone
> (A TAG review of a particular aspect happened in:
> https://github.com/w3ctag/design-reviews/issues/618)
>
> TAG review statusNot 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?


>
>
> *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 nameOpaqueResponseBlockingV02
>
> Requires code in //chrome?False
>
> Tracking bughttps://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 changesNone
>
> 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
> .
>
> --
> 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/CALG6KPPNdN%3DO0j0MhcfudkBtMoYnELhVRJ5nLftB8c1T1UdwbQ%40mail.gmail.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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXOn7JstY_4wVeSzso3i9E0wA7r4K-CDJ35OV48ZeEPCg%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Opaque Response Blocking (ORB, aka CORB++) v0.2

['Daniel Vogelheim' via blink-dev]

On Mon, Jul 24, 2023 at 5:24 PM Yoav Weiss  wrote:

> On Fri, Jul 21, 2023 at 5:53 PM 'Daniel Vogelheim' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Contact emailsvogelh...@chromium.org
>>
>> Specificationhttps://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 componentInternals>Sandbox>SiteIsolation
>> 
>>
>> TAG reviewNone
>> (A TAG review of a particular aspect happened in:
>> https://github.com/w3ctag/design-reviews/issues/618)
>>
>> TAG review statusNot 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.




>
>
>>
>>
>> *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 nameOpaqueResponseBlockingV02
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://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 changesNone
>>
>> 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
>> .
>>
>> --
>> 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/CALG6KPPNdN%3DO0j0MhcfudkBtMoYnELhVRJ5nLftB8c1T1UdwbQ%40mail.gmail.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-

Re: [blink-dev] Intent to Ship: Opaque Response Blocking (ORB, aka CORB++) v0.2

[Yoav Weiss]

On Mon, Jul 24, 2023 at 5:44 PM Daniel Vogelheim 
wrote:

> On Mon, Jul 24, 2023 at 5:24 PM Yoav Weiss  wrote:
>
>> On Fri, Jul 21, 2023 at 5:53 PM 'Daniel Vogelheim' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Contact emailsvogelh...@chromium.org
>>>
>>> Specificationhttps://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 componentInternals>Sandbox>SiteIsolation
>>> 
>>>
>>> TAG reviewNone
>>> (A TAG review of a particular aspect happened in:
>>> https://github.com/w3ctag/design-reviews/issues/618)
>>>
>>> TAG review statusNot 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?)

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

Re: [blink-dev] Intent to Ship: Opaque Response Blocking (ORB, aka CORB++) v0.2

['Daniel Vogelheim' via blink-dev]

On Mon, Jul 24, 2023 at 5:55 PM Yoav Weiss  wrote:

> On Mon, Jul 24, 2023 at 5:44 PM Daniel Vogelheim 
> wrote:
>
>> On Mon, Jul 24, 2023 at 5:24 PM Yoav Weiss 
>> wrote:
>>
>>> On Fri, Jul 21, 2023 at 5:53 PM 'Daniel Vogelheim' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
 Contact emailsvogelh...@chromium.org

 Specificationhttps://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 componentInternals>Sandbox>SiteIsolation
 

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

 TAG review statusNot 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.


>

 *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 nameOpaqueResponseBlockingV02

 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 changesNone

 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 Chro

Re: [blink-dev] Intent to Ship: Opaque Response Blocking (ORB, aka CORB++) v0.2

[Yoav Weiss]

On Mon, Jul 24, 2023 at 7:27 PM Daniel Vogelheim 
wrote:

> On Mon, Jul 24, 2023 at 5:55 PM Yoav Weiss  wrote:
>
>> On Mon, Jul 24, 2023 at 5:44 PM Daniel Vogelheim 
>> wrote:
>>
>>> On Mon, Jul 24, 2023 at 5:24 PM Yoav Weiss 
>>> wrote:
>>>
 On Fri, Jul 21, 2023 at 5:53 PM 'Daniel Vogelheim' via blink-dev <
 blink-dev@chromium.org> wrote:

> Contact emailsvogelh...@chromium.org
>
> Specificationhttps://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 componentInternals>Sandbox>SiteIsolation
> 
>
> TAG reviewNone
> (A TAG review of a particular aspect happened in:
> https://github.com/w3ctag/design-reviews/issues/618)
>
> TAG review statusNot 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.
>

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?


>
>
>>
>
> *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 nameOpaqueResponseBlockingV02
>
> Requires code in //chrome?False
>
> Tracking bug
> https://bugs.chromium.org/p/chromium/issues/detail?id=1463725
>
> Estimated milestones
> Ship

Re: [blink-dev] Intent to Ship: Opaque Response Blocking (ORB, aka CORB++) v0.2

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

Specificationhttps://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.

On Tue, Jul 25, 2023 at 3:10 AM Yoav Weiss  wrote:

>
>
> On Mon, Jul 24, 2023 at 7:27 PM Daniel Vogelheim 
> wrote:
>
>> On Mon, Jul 24, 2023 at 5:55 PM Yoav Weiss 
>> wrote:
>>
>>> On Mon, Jul 24, 2023 at 5:44 PM Daniel Vogelheim 
>>> wrote:
>>>
 On Mon, Jul 24, 2023 at 5:24 PM Yoav Weiss 
 wrote:

> On Fri, Jul 21, 2023 at 5:53 PM 'Daniel Vogelheim' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Contact emailsvogelh...@chromium.org
>>
>> Specificationhttps://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 componentInternals>Sandbox>SiteIsolation
>> 
>>
>> TAG reviewNone
>> (A TAG review of a particular aspect happened in:
>> https://github.com/w3ctag/design-reviews/issues/618)
>>
>> TAG review statusNot 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.
>>
>
> 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 thr

Re: [blink-dev] Intent to Ship: Opaque Response Blocking (ORB, aka CORB++) v0.2

[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



On Tue, Jul 25, 2023 at 6:16 PM Dominic Farolino  wrote:

> *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?
>
> Specificationhttps://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.
>
> On Tue, Jul 25, 2023 at 3:10 AM Yoav Weiss  wrote:
>
>>
>>
>> On Mon, Jul 24, 2023 at 7:27 PM Daniel Vogelheim 
>> wrote:
>>
>>> On Mon, Jul 24, 2023 at 5:55 PM Yoav Weiss 
>>> wrote:
>>>
 On Mon, Jul 24, 2023 at 5:44 PM Daniel Vogelheim 
 wrote:

> On Mon, Jul 24, 2023 at 5:24 PM Yoav Weiss 
> wrote:
>
>> On Fri, Jul 21, 2023 at 5:53 PM 'Daniel Vogelheim' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Contact emailsvogelh...@chromium.org
>>>
>>> Specificationhttps://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 componentInternals>Sandbox>SiteIsolation
>>> 
>>>
>>> TAG reviewNone
>>> (A TAG review of a particular aspect happened in:
>>> https://github.com/w3ctag/design-reviews/issues/618)
>>>
>>> TAG review statusNot 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 oft

Re: [blink-dev] Intent to Ship: Opaque Response Blocking (ORB, aka CORB++) v0.2

['Daniel Vogelheim' via blink-dev]

On Tue, Jul 25, 2023 at 9:10 AM Yoav Weiss  wrote:

> On Mon, Jul 24, 2023 at 7:27 PM Daniel Vogelheim 
> wrote:
>
>> On Mon, Jul 24, 2023 at 5:55 PM Yoav Weiss 
>> wrote:
>>
>>> On Mon, Jul 24, 2023 at 5:44 PM Daniel Vogelheim 
>>> wrote:
>>>
 On Mon, Jul 24, 2023 at 5:24 PM Yoav Weiss 
 wrote:

> On Fri, Jul 21, 2023 at 5:53 PM 'Daniel Vogelheim' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Contact emailsvogelh...@chromium.org
>>
>> Specificationhttps://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 componentInternals>Sandbox>SiteIsolation
>> 
>>
>> TAG reviewNone
>> (A TAG review of a particular aspect happened in:
>> https://github.com/w3ctag/design-reviews/issues/618)
>>
>> TAG review statusNot 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.
>>
>
> 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?
>

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


>
>>
>> *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
>>
>>
>> D

Re: [blink-dev] Intent to Ship: Opaque Response Blocking (ORB, aka CORB++) v0.2

['Daniel Vogelheim' via blink-dev]

On Tue, Jul 25, 2023 at 6:00 PM Olli Pettay  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.)

On Tue, Jul 25, 2023 at 6:16 PM Dominic Farolino  wrote:
>
>> *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?
>>
>> Specificationhttps://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.
>>
>> On Tue, Jul 25, 2023 at 3:10 AM Yoav Weiss 
>> wrote:
>>
>>>
>>>
>>> On Mon, Jul 24, 2023 at 7:27 PM Daniel Vogelheim 
>>> wrote:
>>>
 On Mon, Jul 24, 2023 at 5:55 PM Yoav Weiss 
 wrote:

> On Mon, Jul 24, 2023 at 5:44 PM Daniel Vogelheim 
> wrote:
>
>> On Mon, Jul 24, 2023 at 5:24 PM Yoav Weiss 
>> wrote:
>>
>>> On Fri, Jul 21, 2023 at 5:53 PM 'Daniel Vogelheim' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
 Contact emailsvogelh...@chromium.org

 Specificationhttps://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 componentInternals>Sandbox>SiteIsolation
 

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

 TAG review statusNot 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 

Re: [blink-dev] Intent to Ship: Opaque Response Blocking (ORB, aka CORB++) v0.2

[Yoav Weiss]

On Tue, Jul 25, 2023 at 6:48 PM Daniel Vogelheim 
wrote:

> On Tue, Jul 25, 2023 at 9:10 AM Yoav Weiss  wrote:
>
>> On Mon, Jul 24, 2023 at 7:27 PM Daniel Vogelheim 
>> wrote:
>>
>>> On Mon, Jul 24, 2023 at 5:55 PM Yoav Weiss 
>>> wrote:
>>>
 On Mon, Jul 24, 2023 at 5:44 PM Daniel Vogelheim 
 wrote:

> On Mon, Jul 24, 2023 at 5:24 PM Yoav Weiss 
> wrote:
>
>> On Fri, Jul 21, 2023 at 5:53 PM 'Daniel Vogelheim' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Contact emailsvogelh...@chromium.org
>>>
>>> Specificationhttps://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 componentInternals>Sandbox>SiteIsolation
>>> 
>>>
>>> TAG reviewNone
>>> (A TAG review of a particular aspect happened in:
>>> https://github.com/w3ctag/design-reviews/issues/618)
>>>
>>> TAG review statusNot 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.
>>>
>>
>> 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?
>>
>
> 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. :-/
>

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)

Re: [blink-dev] Intent to Ship: Opaque Response Blocking (ORB, aka CORB++) v0.2

['Daniel Vogelheim' via blink-dev]

On Wed, Jul 26, 2023 at 11:29 AM Yoav Weiss  wrote:

> On Tue, Jul 25, 2023 at 6:48 PM Daniel Vogelheim 
> wrote:
>
>> On Tue, Jul 25, 2023 at 9:10 AM Yoav Weiss 
>> wrote:
>>
>>> On Mon, Jul 24, 2023 at 7:27 PM Daniel Vogelheim 
>>> wrote:
>>>
 On Mon, Jul 24, 2023 at 5:55 PM Yoav Weiss 
 wrote:

> On Mon, Jul 24, 2023 at 5:44 PM Daniel Vogelheim 
> wrote:
>
>> On Mon, Jul 24, 2023 at 5:24 PM Yoav Weiss 
>> wrote:
>>
>>> On Fri, Jul 21, 2023 at 5:53 PM 'Daniel Vogelheim' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
 Contact emailsvogelh...@chromium.org

 Specificationhttps://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 componentInternals>Sandbox>SiteIsolation
 

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

 TAG review statusNot 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.

>>>
>>> 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?
>>>
>>
>> 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. :-/
>>
>
> 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 c

Re: [blink-dev] Intent to Ship: Opaque Response Blocking (ORB, aka CORB++) v0.2

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

On Fri, Aug 11, 2023 at 2:50 AM 'Daniel Vogelheim' via blink-dev <
blink-dev@chromium.org> wrote:

> On Wed, Jul 26, 2023 at 11:29 AM Yoav Weiss 
> wrote:
>
>> On Tue, Jul 25, 2023 at 6:48 PM Daniel Vogelheim 
>> wrote:
>>
>>> On Tue, Jul 25, 2023 at 9:10 AM Yoav Weiss 
>>> wrote:
>>>
 On Mon, Jul 24, 2023 at 7:27 PM Daniel Vogelheim 
 wrote:

> On Mon, Jul 24, 2023 at 5:55 PM Yoav Weiss 
> wrote:
>
>> On Mon, Jul 24, 2023 at 5:44 PM Daniel Vogelheim <
>> vogelh...@google.com> wrote:
>>
>>> On Mon, Jul 24, 2023 at 5:24 PM Yoav Weiss 
>>> wrote:
>>>
 On Fri, Jul 21, 2023 at 5:53 PM 'Daniel Vogelheim' via blink-dev <
 blink-dev@chromium.org> wrote:

> Contact emailsvogelh...@chromium.org
>
> Specificationhttps://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 componentInternals>Sandbox>SiteIsolation
> 
>
> TAG reviewNone
> (A TAG review of a particular aspect happened in:
> https://github.com/w3ctag/design-reviews/issues/618)
>
> TAG review statusNot 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.
>

 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?

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

Re: [blink-dev] Intent to Ship: Opaque Response Blocking (ORB, aka CORB++) v0.2

[Yoav Weiss]

LGTM2

On Wed, Aug 16, 2023 at 7:23 PM Chris Harrelson 
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.
>
> On Fri, Aug 11, 2023 at 2:50 AM 'Daniel Vogelheim' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> On Wed, Jul 26, 2023 at 11:29 AM Yoav Weiss 
>> wrote:
>>
>>> On Tue, Jul 25, 2023 at 6:48 PM Daniel Vogelheim 
>>> wrote:
>>>
 On Tue, Jul 25, 2023 at 9:10 AM Yoav Weiss 
 wrote:

> On Mon, Jul 24, 2023 at 7:27 PM Daniel Vogelheim 
> wrote:
>
>> On Mon, Jul 24, 2023 at 5:55 PM Yoav Weiss 
>> wrote:
>>
>>> On Mon, Jul 24, 2023 at 5:44 PM Daniel Vogelheim <
>>> vogelh...@google.com> wrote:
>>>
 On Mon, Jul 24, 2023 at 5:24 PM Yoav Weiss 
 wrote:

> On Fri, Jul 21, 2023 at 5:53 PM 'Daniel Vogelheim' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Contact emailsvogelh...@chromium.org
>>
>> Specificationhttps://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 componentInternals>Sandbox>SiteIsolation
>> 
>>
>> TAG reviewNone
>> (A TAG review of a particular aspect happened in:
>> https://github.com/w3ctag/design-reviews/issues/618)
>>
>> TAG review statusNot 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.
>>
>
> 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?
>

 Turning this on via server-side experiments (an

Re: [blink-dev] Intent to Ship: Opaque Response Blocking (ORB, aka CORB++) v0.2

[Mike Taylor]

LGTM3

On 8/22/23 10:37 AM, Yoav Weiss wrote:

LGTM2

On Wed, Aug 16, 2023 at 7:23 PM Chris Harrelson 
 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.

On Fri, Aug 11, 2023 at 2:50 AM 'Daniel Vogelheim' via blink-dev
 wrote:

On Wed, Jul 26, 2023 at 11:29 AM Yoav Weiss
 wrote:

On Tue, Jul 25, 2023 at 6:48 PM Daniel Vogelheim
 wrote:

On Tue, Jul 25, 2023 at 9:10 AM Yoav Weiss
 wrote:

On Mon, Jul 24, 2023 at 7:27 PM Daniel Vogelheim
 wrote:

On Mon, Jul 24, 2023 at 5:55 PM Yoav Weiss
 wrote:

On Mon, Jul 24, 2023 at 5:44 PM Daniel
Vogelheim  wrote:

On Mon, Jul 24, 2023 at 5:24 PM Yoav
Weiss  wrote:

On Fri, Jul 21, 2023 at 5:53 PM
'Daniel Vogelheim' via blink-dev
 wrote:


Contact emails

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

Re: [blink-dev] Intent to Ship: Opaque Response Blocking (ORB, aka CORB++) v0.2

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

On Tue, Aug 22, 2023 at 10:45 AM Mike Taylor  wrote:

> LGTM3
> On 8/22/23 10:37 AM, Yoav Weiss wrote:
>
> LGTM2
>
> On Wed, Aug 16, 2023 at 7:23 PM Chris Harrelson 
> 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.
>>
>> On Fri, Aug 11, 2023 at 2:50 AM 'Daniel Vogelheim' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> On Wed, Jul 26, 2023 at 11:29 AM Yoav Weiss 
>>> wrote:
>>>
 On Tue, Jul 25, 2023 at 6:48 PM Daniel Vogelheim 
 wrote:

> On Tue, Jul 25, 2023 at 9:10 AM Yoav Weiss 
> wrote:
>
>> On Mon, Jul 24, 2023 at 7:27 PM Daniel Vogelheim <
>> vogelh...@google.com> wrote:
>>
>>> On Mon, Jul 24, 2023 at 5:55 PM Yoav Weiss 
>>> wrote:
>>>
 On Mon, Jul 24, 2023 at 5:44 PM Daniel Vogelheim <
 vogelh...@google.com> wrote:

> On Mon, Jul 24, 2023 at 5:24 PM Yoav Weiss 
> wrote:
>
>> On Fri, Jul 21, 2023 at 5:53 PM 'Daniel Vogelheim' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Contact emails vogelh...@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
 on

Re: [blink-dev] Intent to Ship: Opaque Response Blocking (ORB, aka CORB++) v0.2

['Daniel Vogelheim' via blink-dev]

On Tue, Aug 22, 2023 at 5:02 PM Dominic Farolino  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.

-- 
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/CALG6KPNVCdsRpi4KP1CXkK-R75YrCU%2Bxb2NP%2BoYSzizU7spwew%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Opaque Response Blocking (ORB, aka CORB++) v0.2

['Daniel Vogelheim' via blink-dev]

Hello all, it's been a while.

On Wed, Aug 16, 2023 at 7:23 PM Chris Harrelson 
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


On Fri, Aug 11, 2023 at 2:50 AM 'Daniel Vogelheim' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> On Wed, Jul 26, 2023 at 11:29 AM Yoav Weiss 
>> wrote:
>>
>>> On Tue, Jul 25, 2023 at 6:48 PM Daniel Vogelheim 
>>> wrote:
>>>
 On Tue, Jul 25, 2023 at 9:10 AM Yoav Weiss 
 wrote:

> On Mon, Jul 24, 2023 at 7:27 PM Daniel Vogelheim 
> wrote:
>
>> On Mon, Jul 24, 2023 at 5:55 PM Yoav Weiss 
>> wrote:
>>
>>> On Mon, Jul 24, 2023 at 5:44 PM Daniel Vogelheim <
>>> vogelh...@google.com> wrote:
>>>
 On Mon, Jul 24, 2023 at 5:24 PM Yoav Weiss 
 wrote:

> On Fri, Jul 21, 2023 at 5:53 PM 'Daniel Vogelheim' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Contact emailsvogelh...@chromium.org
>>
>> Specificationhttps://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 componentInternals>Sandbox>SiteIsolation
>> 
>>
>> TAG reviewNone
>> (A TAG review of a particular aspect happened in:
>> https://github.com/w3ctag/design-reviews/issues/618)
>>
>> TAG review statusNot 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

Re: [blink-dev] Intent to Ship: Opaque Response Blocking (ORB, aka CORB++) v0.2

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

On Tue, Oct 24, 2023 at 8:41 AM 'Daniel Vogelheim' via blink-dev <
blink-dev@chromium.org> wrote:

> Hello all, it's been a while.
>
> On Wed, Aug 16, 2023 at 7:23 PM Chris Harrelson 
> 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
>
>
> On Fri, Aug 11, 2023 at 2:50 AM 'Daniel Vogelheim' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> On Wed, Jul 26, 2023 at 11:29 AM Yoav Weiss 
>>> wrote:
>>>
 On Tue, Jul 25, 2023 at 6:48 PM Daniel Vogelheim 
 wrote:

> On Tue, Jul 25, 2023 at 9:10 AM Yoav Weiss 
> wrote:
>
>> On Mon, Jul 24, 2023 at 7:27 PM Daniel Vogelheim <
>> vogelh...@google.com> wrote:
>>
>>> On Mon, Jul 24, 2023 at 5:55 PM Yoav Weiss 
>>> wrote:
>>>
 On Mon, Jul 24, 2023 at 5:44 PM Daniel Vogelheim <
 vogelh...@google.com> wrote:

> On Mon, Jul 24, 2023 at 5:24 PM Yoav Weiss 
> wrote:
>
>> On Fri, Jul 21, 2023 at 5:53 PM 'Daniel Vogelheim' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Contact emailsvogelh...@chromium.org
>>>
>>> Specificationhttps://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 componentInternals>Sandbox>SiteIsolation
>>> 
>>>
>>> TAG reviewNone
>>> (A TAG review of a particular aspect happened in:
>>> https://github.com/w3ctag/design-reviews/issues/618)
>>>
>>> TAG review statusNot 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 networ