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@ <https://lists.webkit.org/pipermail/webkit-dev/2022-March/032167.html>). That said, I have two questions:
1. The ORB telemetry results - Mar 2022 <https://docs.google.com/document/d/1MbYQbL4WQyZdCQcZcKyzxHA0UxbHTC0O4bQXFgm8o6A/edit?usp=sharing> 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 On Mon, May 9, 2022 at 8:26 PM Łukasz Anforowicz <[email protected]> wrote: > On Fri, May 6, 2022 at 4:45 PM Mike Taylor <[email protected]> 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 > <https://github.com/w3ctag/design-reviews/issues/618#issuecomment-806017154> > 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 > <https://www.chromium.org/blink/launching-features/#web-developer-facing-change-to-existing-code>" > path instead. > > Thanks, > > -Lukasz > > >> On 5/5/22 2:02 PM, Łukasz Anforowicz wrote: >> >> 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:* >> [email protected], [email protected], [email protected] >> >> *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 [email protected]. >> 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> >> . >> >> >> -- > 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/CAA_NCUGAOpNbCx-gZsttKo1cSGAoHugVJJBEjGrqA9AjQ1KtOw%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA_NCUGAOpNbCx-gZsttKo1cSGAoHugVJJBEjGrqA9AjQ1KtOw%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/CAKXHy%3DdLugdOmdv7mZQpR-mFGPVsz6LYE3cC1M4U8xQ1p3UtUQ%40mail.gmail.com.
