On Fri, May 6, 2022 at 4:45 PM Mike Taylor <miketa...@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 <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:* > 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> > . > > > -- 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_NCUGAOpNbCx-gZsttKo1cSGAoHugVJJBEjGrqA9AjQ1KtOw%40mail.gmail.com.
