On Wed, Jul 26, 2023 at 11:29 AM Yoav Weiss <[email protected]> wrote:
> 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) > I've now landed the usecounter CL. What I'd like to do is: Enable the feature on beta now and wait for numbers to arrive from the usecounters. This would give us two signals on compatibility. According to the current schedule, the counters will make it into 118. > > >> >> >>> >>>>>>>> >>>>>>>> *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/CALG6KPMpGi0K71%3DF8i4SjKt_1RuVnpAiavv1mArDO--rzLSSwA%40mail.gmail.com.
