On Tue, Jul 25, 2023 at 9:10 AM Yoav Weiss <yoavwe...@chromium.org> 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 <yoavwe...@chromium.org> >> 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 <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?) >>> >> >> 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 >>>>>> >>>>>> >>>>>> 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/CALG6KPPjGgVdTwDrDATfrCEfDqz1BF%2B4VnMGyO9%3DPRMWJLGqcA%40mail.gmail.com.
