On Mon, Jul 24, 2023 at 7:27 PM Daniel Vogelheim <[email protected]> wrote:
> On Mon, Jul 24, 2023 at 5:55 PM Yoav Weiss <[email protected]> wrote: > >> On Mon, Jul 24, 2023 at 5:44 PM Daniel Vogelheim <[email protected]> >> wrote: >> >>> On Mon, Jul 24, 2023 at 5:24 PM Yoav Weiss <[email protected]> >>> wrote: >>> >>>> On Fri, Jul 21, 2023 at 5:53 PM 'Daniel Vogelheim' via blink-dev < >>>> [email protected]> wrote: >>>> >>>>> Contact [email protected] >>>>> >>>>> 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 >>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ESandbox%3ESiteIsolation> >>>>> >>>>> 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 >>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>> ?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 >>>>> <https://chromestatus.com/>. >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "blink-dev" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPPNdN%3DO0j0MhcfudkBtMoYnELhVRJ5nLftB8c1T1UdwbQ%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPPNdN%3DO0j0MhcfudkBtMoYnELhVRJ5nLftB8c1T1UdwbQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVY%2BTDQMku-TkjrnkkeDu_%2B7Gf_d1u3UTs-AxZ9SxdXZA%40mail.gmail.com.
