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@ > <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? > > 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 <http:///>" 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 <https://docs.google.com/document/d/1qUbE2ySi6av3arUEw5DNdFJIKKBbWGRGsXz_ew3S7HQ/edit#heading=h.mptmm5bpjtdn>" 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? > Thanks! > > -mike > > > On Mon, May 9, 2022 at 8:26 PM Łukasz Anforowicz <luka...@chromium.org> > wrote: > >> 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 >> <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 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_NCUG3%2ByUxFwTnrA0ahvAuvfXP4%2BKhbMyhO9XPfpLySDF8jg%40mail.gmail.com.
