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 <yoavwe...@chromium.org> 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 >>> <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?) > > > >> >> >>> >>> >>> *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 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 >>> <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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVR5ovqGoQHLM2jTXb9eOCO_PO%3DN1wzj3XqwJZhDhTjew%40mail.gmail.com.
