On Wed, May 11, 2022 at 2:56 AM Łukasz Anforowicz <luka...@chromium.org> wrote:
> 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...) > Also, that number is presented as a percentage from HTTP requests. Do you have the data on how this presents itself as a percentage of page views? If the majority of these requests are range requests, there's reason to believe there was more than one per page view. > > >> >> 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? > Another point on that front - we don't typically ship things that are specified in personal repos. While this case is somewhat different than the typical case (that is, it's not a personal repo of someone working on Chrome), it'd still be good to move the spec to a more official space, where more folks feel free to contribute to it. Have y'all talked to Anne about moving the repo to the WHATWG or to some incubation venue? > >> 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA_NCUG3%2ByUxFwTnrA0ahvAuvfXP4%2BKhbMyhO9XPfpLySDF8jg%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/CAL5BFfXgWgEZPe4uZbA1xe0gV0to8KeBkkW-a-qiqMEzOfPZmQ%40mail.gmail.com.
