Hello all, it's been a while. On Wed, Aug 16, 2023 at 7:23 PM Chris Harrelson <chris...@chromium.org> wrote:
> LGTM1 to turn it on in M118 beta and report back to this group about use > counter results/bugs reported on beta before it reaches stable. > As requested, I have added use counters to measure ORB-blocked resources on elements (script and img/video/media) with event handlers. On current stable, I get this: (source <https://uma.googleplex.com/p/chrome/timeline_v2?sid=064bd3472f5dfd2a92f8d34049e5848e> ) - 0.006% of page loads have a script or media element with an event handler (and thus potential compatibility impact from this change; although we don't know what the impact would be) - 0.0075 % of page loads have a script or media element without any event handlers (and thus guaranteed without compatibility impact from this change) - The majority of pages with any event handler seem to have both handlers - onload and onerror - set. I'll note that the sum of those (with any + without any) are much lower than the numbers I previously reported in this thread. I believe that's because of 1, here we only count specific HTML elements (but not e.g. the ping attribute on links), and 2, the carveout for fetch()-initiated requests. The previously reported metric counted ORB-related blocks across all page-initiated responses, regardless of whether it might be script-visible or not. Daniel On Fri, Aug 11, 2023 at 2:50 AM 'Daniel Vogelheim' via blink-dev < > blink-dev@chromium.org> wrote: > >> On Wed, Jul 26, 2023 at 11:29 AM Yoav Weiss <yoavwe...@chromium.org> >> wrote: >> >>> On Tue, Jul 25, 2023 at 6:48 PM Daniel Vogelheim <vogelh...@google.com> >>> wrote: >>> >>>> 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. :-/ >>>> >>> >>> 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 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/CALG6KPMpGi0K71%3DF8i4SjKt_1RuVnpAiavv1mArDO--rzLSSwA%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPMpGi0K71%3DF8i4SjKt_1RuVnpAiavv1mArDO--rzLSSwA%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/CALG6KPOi_sOLKazGH-2fno%3DQXegL7oO6RyDe4c5zudWro3DGdA%40mail.gmail.com.
