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: - 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 <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. - *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. - 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 <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. - 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 <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 - 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 <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). - 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 - 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 <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.
