Hello!
The goal of this email is to:
* Seek LGTMs from Blink API owners for the intent to ship ORB v0.1
<https://chromestatus.com/feature/4933785622675456> 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
<https://bugzilla.mozilla.org/show_bug.cgi?id=1532642#c19> 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
<https://mimesniff.spec.whatwg.org/#html-mime-type> or XML mime
type <https://mimesniff.spec.whatwg.org/#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:
o https://crrev.com/c/3554875: Always allowing all audio/* and
video/* reduces the risk of breaking range responses.
o 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
<https://mimesniff.spec.whatwg.org/#audio-or-video-type-pattern-matching-algorithm>
or image sniffing
<https://mimesniff.spec.whatwg.org/#image-type-pattern-matching-algorithm>
algorithms used by ORB, and that 3) *do* sniff as HTML, JSON, or XML.
o *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
<https://mimesniff.spec.whatwg.org/#audio-or-video-type-pattern-matching-algorithm>
algorithms used by ORB.
o Example: hypothetical future/under-development/new video
format served as application/octet-stream or text/html and
requested via range requests.
o Example: format covered by the sniffing spec
<https://mimesniff.spec.whatwg.org/#matching-a-mime-type-pattern>,
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.
o 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).
o 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
<https://docs.google.com/document/d/1MbYQbL4WQyZdCQcZcKyzxHA0UxbHTC0O4bQXFgm8o6A/edit?usp=sharing>”
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
o 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).
o 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:
o We want to avoid gathering URLs of HTTP resources, since they
may be PII (Personally Identifiable Information). We also
note that Rappor
<https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/42852.pdf>
is deprecated and UKM only allows logging of certain, limited
URLs (e.g. URLs of top-level pages, and of installed Chrome
Extensions).
o Non-PII information gathered via temporary crash keys
<https://chromium-review.googlesource.com/c/chromium/src/+/3465612>
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
o 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).
o Recommending to use a more specific MIME type in the
Content-Type HTTP response header.
o 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
<https://docs.google.com/document/d/1qUbE2ySi6av3arUEw5DNdFJIKKBbWGRGsXz_ew3S7HQ/edit#heading=h.mptmm5bpjtdn>”
section in the “Gradual CORB -> ORB transition
<https://docs.google.com/document/d/1qUbE2ySi6av3arUEw5DNdFJIKKBbWGRGsXz_ew3S7HQ/edit?usp=sharing>”
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:*
luka...@chromium.org, cr...@chromium.org, vogelh...@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
--
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/CAA_NCUH%3Df4KJK7F1rZ9PugP4O9kPQ%2BSzot0VjD6hyxZ%3Dqn_Bjw%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA_NCUH%3Df4KJK7F1rZ9PugP4O9kPQ%2BSzot0VjD6hyxZ%3Dqn_Bjw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
