> > It looks like the spec PR here has been dormant for something like ~9 > months. Are there any plans to help drive it to the finish line, > especially given the TODOs listed in the OP? How should we all think about > whatever work might remain there, and possibly deviate from what Chrome > plans on shipping? >
Hello, I'm still a little curious if there are plans to advance the spec PR anymore, so that it matches what we're attempting to ship? Or is there something new that has superseded that work, making it (and my question) obsolete? On Tue, Aug 22, 2023 at 10:45 AM Mike Taylor <[email protected]> wrote: > LGTM3 > On 8/22/23 10:37 AM, Yoav Weiss wrote: > > LGTM2 > > On Wed, Aug 16, 2023 at 7:23 PM Chris Harrelson <[email protected]> > 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. >> >> On Fri, Aug 11, 2023 at 2:50 AM 'Daniel Vogelheim' via blink-dev < >> [email protected]> wrote: >> >>> 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 emails [email protected] >>>>>>>>>>> >>>>>>>>>>> Specification https://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 component Internals>Sandbox>SiteIsolation >>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ESandbox%3ESiteIsolation> >>>>>>>>>>> >>>>>>>>>>> TAG review None >>>>>>>>>>> (A TAG review of a particular aspect happened in: >>>>>>>>>>> https://github.com/w3ctag/design-reviews/issues/618) >>>>>>>>>>> >>>>>>>>>>> TAG review status Not 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 name OpaqueResponseBlockingV02 >>>>>>>>>>> >>>>>>>>>>> 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 changes None >>>>>>>>>>> >>>>>>>>>>> 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 >>> <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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWcnLZhP39z%2B41fEhWSV-ZfhYCcaAae_EUDDtfXTxUuqw%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWcnLZhP39z%2B41fEhWSV-ZfhYCcaAae_EUDDtfXTxUuqw%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/3ccd3d3a-ca7d-4df1-aa4c-69d62279d924%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3ccd3d3a-ca7d-4df1-aa4c-69d62279d924%40chromium.org?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/CAP-uykC8BmxSgiyBDSC7CPEeWatrqb4RSmD7z0%3DuS3KtViGe5Q%40mail.gmail.com.
