On Tue, Jul 25, 2023 at 6:48 PM Daniel Vogelheim <[email protected]> wrote:
> On Tue, Jul 25, 2023 at 9:10 AM Yoav Weiss <[email protected]> wrote: > >> 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? >> > > 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) > > >> >>>>>>> >>>>>>> *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/CAL5BFfXggzuRYjLBJQOX3Ww_po7SZ7bcGEqCURUbj1jmNjbc8Q%40mail.gmail.com.
