LGTM3
On 8/22/23 10:37 AM, Yoav Weiss wrote:
LGTM2
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.
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 emails
vogelh...@chromium.org
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
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/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 blink-dev+unsubscr...@chromium.org.
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.
