Intent to Ship: Opaque Response Blocking (ORB, aka CORB++) v0.1

[Łukasz Anforowicz]

Hello!

The goal of this email is to:

• Seek LGTMs from Blink API owners for the intent to ship ORB v0.1 in Chrome M103.  A formal, semi-automatically-generated intent-to-ship data can be found at the end of this email.
• Provide an overview of ORB, motivations for shipping it, and its (low) risks.
• Highlight scenarios where web developers might want to double-check the MIME types used by their HTTP servers when serving certain resources.

Overview of ORB

Opaque Response Blocking (ORB) is a replacement for Cross-Origin Read Blocking (CORB).  CORB and ORB are both heuristics that attempt to prevent cross-origin disclosure of “no-cors” subresources.  An example attack that ORB and CORB prevent is where an attacker’s frame contains <img src=”https://victim.example.com/secret.json”> which an attacker reads using either Spectre or a compromised renderer.  Site Isolation depends on either CORB or ORB to keep cross-site secrets out of the renderer process.  For more information please see https://www.chromium.org/Home/chromium-security/corb-for-developers.

We are considering replacing CORB with ORB because ORB is more secure: CORB fails open (it only blocks what its heuristics recognize as blockable) and ORB fails closed (it only allows what its heuristics recognize as scripts, stylesheets, images, audio, or video).  Improved security properties mean that ORB is more likely to be a broadly adopted standard.

ORB spec is being iterated on at https://github.com/annevk/orb.  ORB has not been shipped by any browser today (Firefox tracks their efforts in 1532642 and plans to resume the work soon).  CORB is partially covered by https://fetch.spec.whatwg.org/#corb (HTML, JSON, JS-parser-breaker, nor XML sniffing is not covered).  Chromium is the only browser that implements CORB today.

Motivation for ORB v0.1

At this point, there remain open questions about the feasibility of the JS detection heuristics required by full ORB.  Still, the incremental benefits of adopting even a subset of ORB are definitely desirable.  We call this subset ORBv0.1 - the main difference from full ORB is replacing JS sniffing/parsing with CORB’s more limited HTML, JSON, and XML sniffers. In other words, ORBv0.1 still fails open and only blocks a subset of known response types, but it blocks more than CORB.

ORBv0.1 offers incremental security benefits compared to CORB.  ORBv0.1 blocks the following kinds of HTTP responses that CORB wouldn’t block:

• CORB blocks responses that contain HTML and XML only if they are labeled with HTML mime type or XML mime type.  ORBv0.1 blocks responses that contain HTML and XML even if they are mislabeled (e.g. HTML served as application/octet-stream, or XML served as text/html).
• CORB blocks range request responses only if they are labeled with HTML, JSON, or XML mime type.  ORBv0.1 blocks all range request responses, unless they come from a URL that ORBv0.1 has earlier recognized (via sniffing, or via mime type) as audio or video.

Note that both CORB and ORBv0.1 would block responses that contain JSON or JS-parser-breakers.  OTOH, this CORB protection can be bypassed if the victim’s server allows range requests (which are not blocked by CORB, except for HTML, JSON, or XML mime type). ORBv0.1 closes that gap.

ORBv0.1 is also an incremental step toward full ORB compliance.  At the very least ORBv0.1 makes it easier to experiment with JS detection heuristics (including full Javascript parsing if necessary and acceptable from performance perspective).

Shipping ORBv0.1 in Chrome 103

Implementing ORB in Chromium is tracked in https://crbug.com/1178928 - we plan to ship ORBv0.1 in Chrome M103. Chrome’s implementation of CORB and ORBv0.1 covers all platforms except iOS.  This also includes Android WebView.  Chrome’s implementation is hosted in the NetworkService.

Backcompatibility risks of ORBv0.1

The backcompatibility risk of shipping ORB seems low: less than 0.01% of all HTTP requests are at risk because they are blocked by ORB and not by CORB.  Note that this is an *upper* bound for the amount of possible breakage:

• This number includes responses with payload that is *not* valid in no-cors contexts.  For example - <img src=”https://example.com/document.html”> will not work regardless of whether ORB blocks such a response or not.
• This number is based on older telemetry results.  Recent CLs should further reduce the risk:
• https://crrev.com/c/3554875: Always allowing all audio/* and video/* reduces the risk of breaking range responses.
• https://crrev.com/c/3599601: Always allowing “text/css” removes the risk of breaking html/css polyglot documents (which used to be blocked by ORBv0.1 when they sniffed as HTML or has JS-parser-breakers)

Still, there are certain scenarios that have a higher risk profile - ORBv0.1 risks breaking the following scenarios:

• HTTP 200 responses for audio / image / video subresources that 1) are not labeled as audio/*, image/*, nor video/* mime type, and that 2) do *not* sniff as media according to the audio/video or image sniffing algorithms used by ORB, and that 3) *do* sniff as HTML, JSON, or XML.
• *Hypothetical* example: DASH manifests (a format that sniffs as XML), labeled as application/octet-stream or text/html.  These are only *hypothetical* (i.e. there is no real backcompatibility risk), because there is no native DASH support in Chrome - polyfills use CORS-mediated `fetch(...)` and are therefore unaffected by ORB.
• HTTP 206 range request responses for audio / video subresources that are not labeled as audio/*, image/*, nor video/* mime type, and that have not been earlier (e.g. when processing a HTTP 200 response) sniffed as media according to the audio/video sniffing algorithms used by ORB.
• Example: hypothetical future/under-development/new video format served as application/octet-stream or text/html and requested via range requests.
• Example: format covered by the sniffing spec, but not implemented by Chromium sniffers (we have decided against updating Chromium code when discussing https://crrev.com/c/3352765).  For example, AIFF or AVI video served as application/octet-stream or text/html and requested via range requests.
• Example: mp4 video that is labeled as application/octet-stream and requires range requests that start reading the media resources from its middle bytes (giving ORB no chances to sniff the initial bytes as video).
• Telemetry shows that out of all responses blocked by ORB and not by CORB (so out of 0.01% of all HTTP responses) between 4.1% (on Windows) and 39.6% (on Android) have been blocked because of an unexpected range response (this data was gathered before the fix in https://crrev.com/c/3554875).

In the scenarios outlined above, web developers should double-check that the HTTP responses use a Content-Type that indicates multimedia content - e.g. audio/*, video/*, application/dash+xml, application/ogg, text/vtt, etc.

For more details, please see the (Google-internal) “ORB telemetry results - Mar 2022” document.

Managing the backcompatibility risk

Given low risk of shipping ORB v0.1 (less than 0.01% of all HTTP responses), we have considered but ultimately decided against taking the following actions:

• We don’t plan to implement support for a reverse Origin Trial (that could be used by ORB-affected websites in an emergency, to opt-out of ORB).  We believe that a base::Feature-based kill-switch is a sufficient precaution.
• We don’t plan to emit additional notifications about responses blocked by ORB.  We believe that the existing CORB warning in DevTools is sufficient:

Cross-Origin Read Blocking (CORB) blocked cross-origin response https://www.example.com/example.html with MIME type text/html. See https://www.chromestatus.com/feature/5629709824032768 for more details.

• For now we plan to keep referring to the feature as CORB (e.g. in DevTools warnings), because
• ORB builds on top of CORB (e.g. wrt blocking behavior where a blocked response has its HTTP response headers stripped and is injected with an empty response body).
• Plenty of CORB documentation exists and applies equally well to ORB (e.g. rationale and description of security benefits provided at https://www.chromium.org/Home/chromium-security/corb-for-developers).
• We don’t gather additional information about affected HTTP resources:
• We want to avoid gathering URLs of HTTP resources, since they may be PII (Personally Identifiable Information).  We also note that Rappor is deprecated and UKM only allows logging of certain, limited URLs (e.g. URLs of top-level pages, and of installed Chrome Extensions).
• Non-PII information gathered via temporary crash keys have been sufficient for identifying and fixing some incorrect behavior (see https://crrev.com/c/3554875: which fixed handling of range requests).

We did or plan to take the following actions to manage the risk of shipping ORB:

• We tweaked CORB's https://chromestatus.com/feature/5629709824032768 entry to call out what is changing in Chrome 103.
• We plan to respond to bug reports (if any) by
  
• Identifying whether the blocked response affected page behavior, or only changed what type of error occurred (which is the typical outcome for bugs filed about CORB).
• Recommending to use a more specific MIME type in the Content-Type HTTP response header.
• Consider deploying a base::Feature-based kill switch if required (possibly only on some platforms; we’ve determined that deploying the kill-switch on Android-WebView-only is feasible).

Implementation risks

PerFactoryState will be stored per URLLoaderFactory and will remember URLs of cross-origin audio/video responses that didn’t have audio/* nor video/* mime type, but that sniffed as audio/video.  We think that the additional memory pressure should be acceptable.  We will monitor existing memory metrics during launch.

Plans beyond ORB v0.1

Shipping ORB v0.1 will allow the following tasks to move forward:

• Deleting code associated with CORB.
• Removing remaining differences between ORB spec and Chrome’s ORB implementation.  For more details please see the “ORB v0.1 vs full ORB differences” section in the “Gradual CORB -> ORB transition” document.  Lack of Javascript sniffing is one major difference, but there are also minor other differences (e.g. blocking by injecting an empty response body VS a network error).

Thanks,

Lukasz Anforowicz (on behalf of the Chrome Security Architecture team)

PS. Below is the more formal, automatically-generated(-and-then-slightly-edited) intent-to-ship data based on https://chromestatus.com/feature/4933785622675456:

Contact emails:
luk...@chromium.org, cr...@chromium.org, voge...@chromium.org

Specification:
https://github.com/annevk/orb

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.1 of ORB - Chrome's first step toward full ORB implementation.

For interop web authors should check Content-Type headers of their resources and indicate multimedia content when needed (e.g. audio/*, application/dash+xml, etc).

Blink component:
Internals>Sandbox>SiteIsolation

TAG review status:
Not applicable

Interoperability and Compatibility Risk:
The backcompatibility risk of shipping ORB v0.1 seems low: less than 0.01% of all HTTP requests are at risk because they are blocked by ORB and not by CORB.

For more information, see the draft of the "Backcompatibility risks of ORBv0.1" and the "Managing the backcompatibility risk" sections at https://docs.google.com/document/d/1dO1NP6xchEiCN990zMczXcSvgcRzSnWBtAgflVBXoTg/edit?usp=sharing

Gecko: In development (https://bugzilla.mozilla.org/show_bug.cgi?id=1532642).

WebKit: No signal

Web developers: No signals

Other signals:

Ergonomics:
N/A (no public API)

Activation:
N/A

Security:
N/A

WebView application risks:
No known WebView-specific risks

Debuggability:
No changes compared to CORB - mostly relying on a DevTools console warning that gets emitted when CORB/ORB block a HTTP response.

Is this feature fully tested by web-platform-tests?
Not really…

CORB and ORBv0.1 do have coverage via wpt/fetch/corb but:

1. CORB and ORBv0.1 are Chrome-only technologies (the latter is a step toward adopting the full, cross-browser ORB standard).  And therefore right now wpt/fetch/corb are Chrome-specific tests.
2. Covering full ORB will require significant refactoring of the tests - among other things we might need to change whether a blocked response is verified by checking for A) an empty response body VS B) a network/fetch error.

Flag name:
--enable-features=OpaqueResponseBlockingV01

Requires code in //chrome?:
False

Tracking bug:
https://crbug.com/1178928

Measurement:
Google-internal "ORB telemetry results - Mar 2022" doc can be found at https://docs.google.com/document/d/1MbYQbL4WQyZdCQcZcKyzxHA0UxbHTC0O4bQXFgm8o6A/edit?usp=sharing

Estimated milestones:
Shipping on desktop 103
Shipping on Android 103

[Mike Taylor]

Hi there,

While we review this, can we ask WebKit for a signal? (bit.ly/blink-signals). Also, https://github.com/w3ctag/design-reviews/issues/618 is the TAG review for this, correct?

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA_NCUH%3Df4KJK7F1rZ9PugP4O9kPQ%2BSzot0VjD6hyxZ%3Dqn_Bjw%40mail.gmail.com.

[Łukasz Anforowicz]

On Fri, May 6, 2022 at 4:45 PM Mike Taylor <mike...@chromium.org> wrote:

Hi there,

While we review this, can we ask WebKit for a signal? (bit.ly/blink-signals).

Done - see: https://lists.webkit.org/pipermail/webkit-dev/2022-May/032222.html

 

Also, https://github.com/w3ctag/design-reviews/issues/618 is the TAG review for this, correct?

Not quite.  This was a review of just one aspect of ORB - having a list of MIME types for which it is never allowed to have a response in mode=no-cors (this aspect is shared across ORB and CORB) .  OTOH some comments in this review did highlight that ORB has no impact on behavior and functionality (assuming HTTP responses use correct `Content-Type`).

For now, I assume that no additional reviews are needed given that

• No new API surface
• No behavior change if HTTP responses use correct `Content-Type`.
• If an incorrect or inaccurate `Content-Type` is used, then ORB v0.1 introduces minimal change in behavior compared to CORB (blocking additional 0.01% of HTTP responses;  see the original email for more details and examples).

FWIW, since ORB does cause known changes in 0.01% of HTTP responses, we thought that an official intent-to-ship route is the safest path going forward.  OTOH, feel free to guide us toward another process if needed - e.g. maybe an argument can be made to use the "web developer facing change to existing code" path instead.

Thanks,

-Lukasz

[Mike West]

Hey Łukasz,

I'm in favor of shipping this change. It will harden our defenses against side-channel attacks at minimal web-visible cost, and clear a path for a WebKit implementation that some folks have expressed interest in (see the CORB thread on webkit-dev@). That said, I have two questions:

1. The ORB telemetry results - Mar 2022 document suggests a substantially smaller impact than the 0.01% number you mention a few times in this intent: 0.002% - 0.006% (it would be ideal if you could create a public version of that document :) ). Can you help me understand the distinctions between those measurements?
   
   
2. The current specification situation is confusing. https://fetch.spec.whatwg.org/#corb doesn't match what Chrome does, and https://github.com/annevk/orb doesn't match what this v0.1 implementation does. Is there something we can point developers to which would explain Chrome's behavior once we ship this initial stab at ORB?

Thanks!

-mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA_NCUGAOpNbCx-gZsttKo1cSGAoHugVJJBEjGrqA9AjQ1KtOw%40mail.gmail.com.

[Łukasz Anforowicz]

On Mon, May 9, 2022 at 11:35 PM Mike West <mk...@chromium.org> wrote:

Hey Łukasz,

I'm in favor of shipping this change. It will harden our defenses against side-channel attacks at minimal web-visible cost, and clear a path for a WebKit implementation that some folks have expressed interest in (see the CORB thread on webkit-dev@). That said, I have two questions:

1. The ORB telemetry results - Mar 2022 document suggests a substantially smaller impact than the 0.01% number you mention a few times in this intent: 0.002% - 0.006% (it would be ideal if you could create a public version of that document :) ). Can you help me understand the distinctions between those measurements?
   

0.01% is just a conservative rounding of the 0.002%-0.006% numbers from the other doc.  (Sorry about that... https://xkcd.com/2585/ seems somewhat applicable I guess...)

 

1. 
   
2. The current specification situation is confusing. https://fetch.spec.whatwg.org/#corb doesn't match what Chrome does, and https://github.com/annevk/orb doesn't match what this v0.1 implementation does. Is there something we can point developers to which would explain Chrome's behavior once we ship this initial stab at ORB?

Hmmm... this is a fair point.  We have some docs, but I am not sure if they are distilled/clear enough for public consumption.  Notably, the "Gradual CORB -> ORB transition" doc talks about the main difference between full ORB and ORB v0.1 (JS sniffing -vs- HTML/JSON/XML sniffing) and also provides a fairly comprehensive list of other, minor differences is in the "Appendix: ORB v0.1 vs full ORB differences" section of the doc.

But... I think that explaining Chrome behavior can be done by just referring to the full ORB spec.  Chrome's ORB v0.1 blocks only a subset of resources that full ORB would block, but the ones that are blocked by Chrome can be explained by the full ORB algorithm (adding a disclaimer to that explanation as needed and pointing out that Chrome only implements a subset of the full ORB algorithm).  Does that seem reasonable?

[Yoav Weiss]

On Wed, May 11, 2022 at 2:56 AM Łukasz Anforowicz <luk...@chromium.org> wrote:

On Mon, May 9, 2022 at 11:35 PM Mike West <mk...@chromium.org> wrote:

Hey Łukasz,

I'm in favor of shipping this change. It will harden our defenses against side-channel attacks at minimal web-visible cost, and clear a path for a WebKit implementation that some folks have expressed interest in (see the CORB thread on webkit-dev@). That said, I have two questions:

1. The ORB telemetry results - Mar 2022 document suggests a substantially smaller impact than the 0.01% number you mention a few times in this intent: 0.002% - 0.006% (it would be ideal if you could create a public version of that document :) ). Can you help me understand the distinctions between those measurements?
   

0.01% is just a conservative rounding of the 0.002%-0.006% numbers from the other doc.  (Sorry about that... https://xkcd.com/2585/ seems somewhat applicable I guess...)

Also, that number is presented as a percentage from HTTP requests. Do you have the data on how this presents itself as a percentage of page views?

If the majority of these requests are range requests, there's reason to believe there was more than one per page view.

 

 

1. 
   
2. The current specification situation is confusing. https://fetch.spec.whatwg.org/#corb doesn't match what Chrome does, and https://github.com/annevk/orb doesn't match what this v0.1 implementation does. Is there something we can point developers to which would explain Chrome's behavior once we ship this initial stab at ORB?

Hmmm... this is a fair point.  We have some docs, but I am not sure if they are distilled/clear enough for public consumption.  Notably, the "Gradual CORB -> ORB transition" doc talks about the main difference between full ORB and ORB v0.1 (JS sniffing -vs- HTML/JSON/XML sniffing) and also provides a fairly comprehensive list of other, minor differences is in the "Appendix: ORB v0.1 vs full ORB differences" section of the doc.

But... I think that explaining Chrome behavior can be done by just referring to the full ORB spec.  Chrome's ORB v0.1 blocks only a subset of resources that full ORB would block, but the ones that are blocked by Chrome can be explained by the full ORB algorithm (adding a disclaimer to that explanation as needed and pointing out that Chrome only implements a subset of the full ORB algorithm).  Does that seem reasonable?

Another point on that front - we don't typically ship things that are specified in personal repos. While this case is somewhat different than the typical case (that is, it's not a personal repo of someone working on Chrome), it'd still be good to move the spec to a more official space, where more folks feel free to contribute to it.

Have y'all talked to Anne about moving the repo to the WHATWG or to some incubation venue?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA_NCUG3%2ByUxFwTnrA0ahvAuvfXP4%2BKhbMyhO9XPfpLySDF8jg%40mail.gmail.com.

[Łukasz Anforowicz]

On Wed, May 11, 2022 at 12:24 AM Yoav Weiss <yoav...@chromium.org> wrote:

On Wed, May 11, 2022 at 2:56 AM Łukasz Anforowicz <luk...@chromium.org> wrote:

On Mon, May 9, 2022 at 11:35 PM Mike West <mk...@chromium.org> wrote:

Hey Łukasz,

I'm in favor of shipping this change. It will harden our defenses against side-channel attacks at minimal web-visible cost, and clear a path for a WebKit implementation that some folks have expressed interest in (see the CORB thread on webkit-dev@). That said, I have two questions:

1. The ORB telemetry results - Mar 2022 document suggests a substantially smaller impact than the 0.01% number you mention a few times in this intent: 0.002% - 0.006% (it would be ideal if you could create a public version of that document :) ). Can you help me understand the distinctions between those measurements?
   

0.01% is just a conservative rounding of the 0.002%-0.006% numbers from the other doc.  (Sorry about that... https://xkcd.com/2585/ seems somewhat applicable I guess...)

Also, that number is presented as a percentage from HTTP requests. Do you have the data on how this presents itself as a percentage of page views?

No, we don't have such a breakdown of the data.

One reason is that ORB (and code gathering ORB's telemetry data) is hosted inside the NetworkService process which is mostly unaware of pages and page views (I think;  I guess UKM would require knowing about pages, but I wasn't able to find UKM-related code under //services/network).  We could try to count the various ORB outcomes per URLLoaderFactory (which roughly corresponds to a single HTML frame;  I note that in the past about:blank frame might have shared a URLLoaderFactory with their opener/parent/initiator - that's probably ok), but getting this data would take time...

If the majority of these requests are range requests, there's reason to believe there was more than one per page view.

We can try to estimate how many responses report HTTP 206 status code.  I looked at Net.HttpResponseCode and "206: Partial Content" accounts for around 0.35% - 1.13% of all HTTP responses (depending on the platform I looked at).  I've added more detailed data + links to a new section in the ORB telemetry results - Mar 2022 document.

 

 

1. 
   
2. The current specification situation is confusing. https://fetch.spec.whatwg.org/#corb doesn't match what Chrome does, and https://github.com/annevk/orb doesn't match what this v0.1 implementation does. Is there something we can point developers to which would explain Chrome's behavior once we ship this initial stab at ORB?

Hmmm... this is a fair point.  We have some docs, but I am not sure if they are distilled/clear enough for public consumption.  Notably, the "Gradual CORB -> ORB transition" doc talks about the main difference between full ORB and ORB v0.1 (JS sniffing -vs- HTML/JSON/XML sniffing) and also provides a fairly comprehensive list of other, minor differences is in the "Appendix: ORB v0.1 vs full ORB differences" section of the doc.

But... I think that explaining Chrome behavior can be done by just referring to the full ORB spec.  Chrome's ORB v0.1 blocks only a subset of resources that full ORB would block, but the ones that are blocked by Chrome can be explained by the full ORB algorithm (adding a disclaimer to that explanation as needed and pointing out that Chrome only implements a subset of the full ORB algorithm).  Does that seem reasonable?

Another point on that front - we don't typically ship things that are specified in personal repos. While this case is somewhat different than the typical case (that is, it's not a personal repo of someone working on Chrome), it'd still be good to move the spec to a more official space, where more folks feel free to contribute to it.

Have y'all talked to Anne about moving the repo to the WHATWG or to some incubation venue?

No, we haven't discussed it yet.  FWIW @Anne van Kesteren is in CC of this email thread, so maybe they can chime in?

[Yoav Weiss]

On Thu, May 12, 2022 at 12:12 AM Łukasz Anforowicz <luk...@chromium.org> wrote:

On Wed, May 11, 2022 at 12:24 AM Yoav Weiss <yoav...@chromium.org> wrote:

On Wed, May 11, 2022 at 2:56 AM Łukasz Anforowicz <luk...@chromium.org> wrote:

On Mon, May 9, 2022 at 11:35 PM Mike West <mk...@chromium.org> wrote:

Hey Łukasz,

I'm in favor of shipping this change. It will harden our defenses against side-channel attacks at minimal web-visible cost, and clear a path for a WebKit implementation that some folks have expressed interest in (see the CORB thread on webkit-dev@). That said, I have two questions:

1. The ORB telemetry results - Mar 2022 document suggests a substantially smaller impact than the 0.01% number you mention a few times in this intent: 0.002% - 0.006% (it would be ideal if you could create a public version of that document :) ). Can you help me understand the distinctions between those measurements?
   

0.01% is just a conservative rounding of the 0.002%-0.006% numbers from the other doc.  (Sorry about that... https://xkcd.com/2585/ seems somewhat applicable I guess...)

Also, that number is presented as a percentage from HTTP requests. Do you have the data on how this presents itself as a percentage of page views?

No, we don't have such a breakdown of the data.

One reason is that ORB (and code gathering ORB's telemetry data) is hosted inside the NetworkService process which is mostly unaware of pages and page views (I think;  I guess UKM would require knowing about pages, but I wasn't able to find UKM-related code under //services/network).  We could try to count the various ORB outcomes per URLLoaderFactory (which roughly corresponds to a single HTML frame;  I note that in the past about:blank frame might have shared a URLLoaderFactory with their opener/parent/initiator - that's probably ok), but getting this data would take time...

OK, would it be fair to assume that at least for no-cors range requests (most likely video/audio requests), there would be more than one per page view, and hence we could expect page view based %ages to be significantly lower?

[Mike West]

I'm comfortable with the risk here, given both the low overall upper bound on the number of requests that might be affected (and the presumably lower number of page views), coupled with the security benefits of hardening CORB and simplifying the mental model for developers. LGTM1.

That said, I agree with Yoav that we should get the spec into Fetch to the extent possible. Given support from Mozilla and us, that could hopefully be a straightforward replacement of https://fetch.spec.whatwg.org/#corb, with TODO blocks around the bits we're not sure of yet (JavaScript sniffing, for instance). Łukasz, perhaps you could collaborate with +Anne van Kesteren to get that done? If you don't have time, I can look around for someone to support y'all (+Daniel Vogelheim, for instance! Hello, Daniel!).

-mike

[Yoav Weiss]

Anne has put together a PR draft. Thanks Anne! :)

Can y'all provide feedback on it? Also, how far is the PR draft from what y'all are planning to ship?

[Łukasz Anforowicz]

On Wed, May 18, 2022 at 12:33 AM Yoav Weiss <yoav...@chromium.org> wrote:

Anne has put together a PR draft. Thanks Anne! :)

Can y'all provide feedback on it?

Yup - I've replied to some of the questions in ORB's issue tracker.  Removing CORB and replacing it with full ORB in the Fetch spec LGTM.

 

Also, how far is the PR draft from what y'all are planning to ship?

 

Not sure how to describe the distance.  Maybe one way would be to share some facts and estimates/guesses about WPT coverage:

• 100% of the currently existing wpt/fetch/corb tests continue to pass with ORBv0.1.
• CORB and ORB differ (see also https://crbug.com/827633) in how they block things like JSON or HTML: CORB replaces the old response with an empty response body;  ORB triggers a network error.  Once that difference is gone: 

• 95+% of the existing CORB and ORBv0.1 tests under wpt/fetch/corb should also apply to full ORB.  The remaining 5% is mostly tests that deal with JSON parser breakers (https://github.com/annevk/orb/issues/30).
• ORB will require extra tests, in addition to the ones currently under wpt/fetch/corb.  I would estimate that ORBv0.1 would pass at least 50% of the final set of WPT tests.

Another way to judge the distance between ORBv0.1 and full ORB is to look at the differences listed in the docs that I've mentioned earlier in this thread:

Notably, the "Gradual CORB -> ORB transition" doc talks about the main difference between full ORB and ORB v0.1 (JS sniffing -vs- HTML/JSON/XML sniffing) and also provides a fairly comprehensive list of other, minor differences is in the "Appendix: ORB v0.1 vs full ORB differences" section of the doc.

-Lukasz

[Yoav Weiss]

I talked to Daniel Vogelheim about this and we agreed that the best way to document this intermediary, Chromium-only state is with in-tree documentation, which Daniel is working on.

LGTM2 to ship, once that clearer documentation lands.

 

Thanks!

-mike

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA_NCUH%3Df4KJK7F1rZ9PugP4O9kPQ%2BSzot0VjD6hyxZ%3Dqn_Bjw%40mail.gmail.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+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA_NCUGAOpNbCx-gZsttKo1cSGAoHugVJJBEjGrqA9AjQ1KtOw%40mail.gmail.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+unsubscribe@chromium.org.

[Daniel Bratell]

LGTM3 (modulo Yoav's request).

There is a clear compatibility risk here so it was good that it was filed as an intent (regarding some comments a month ago), and I wish we knew more about the requests that now will be blocked, but I agree that the risk is just low enough to ship.

You may have to stay vigilant during the canary/beta phase to pick up signals of something going wrong (which is true for most features).

/Daniel

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/418ea310-7447-436c-8994-9a571d0ab27fn%40chromium.org.

[Daniel Vogelheim]

On Wed, Jun 8, 2022 at 9:45 AM Yoav Weiss <yoav...@chromium.org> wrote:

I talked to Daniel Vogelheim about this and we agreed that the best way to document this intermediary, Chromium-only state is with in-tree documentation, which Daniel is working on.

It landed here: services/network/public/cpp/corb/README.md. Please note the appendix about ORB/ORB "v0.1" differences.  Thanks all for your patience.

[Łukasz Anforowicz]

One more quick status update here: the CL to enable ORB v0.1 has landed in r1013464 and was initially released in 105.0.5119.0.