Anne has put together a PR draft <https://github.com/whatwg/fetch/pull/1442>. Thanks Anne! :)
Can y'all provide feedback on it? Also, how far is the PR draft from what y'all are planning to ship? On Tue, May 17, 2022 at 9:08 AM Mike West <mk...@chromium.org> wrote: > I'm comfortable with the risk here, given both the low overall upper bound > on the number of requests that might be affected (and the presumably lower > number of page views), coupled with the security benefits of hardening CORB > and simplifying the mental model for developers. LGTM1. > > That said, I agree with Yoav that we should get the spec into Fetch to the > extent possible. Given support from Mozilla and us, that could hopefully be > a straightforward replacement of https://fetch.spec.whatwg.org/#corb, > with TODO blocks around the bits we're not sure of yet (JavaScript > sniffing, for instance). Łukasz, perhaps you could collaborate with +Anne > van Kesteren <ann...@annevk.nl> to get that done? If you don't have time, > I can look around for someone to support y'all (+Daniel Vogelheim > <vogelh...@chromium.org>, for instance! Hello, Daniel!). > > -mike > > > On Tue, May 17, 2022 at 8:50 AM Yoav Weiss <yoavwe...@chromium.org> wrote: > >> >> >> On Thu, May 12, 2022 at 12:12 AM Łukasz Anforowicz <luka...@chromium.org> >> wrote: >> >>> >>> >>> On Wed, May 11, 2022 at 12:24 AM Yoav Weiss <yoavwe...@chromium.org> >>> wrote: >>> >>>> >>>> >>>> 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? >>>> >>> >>> No, we don't have such a breakdown of the data. >>> >>> One reason is that ORB (and code gathering ORB's telemetry data) is >>> hosted inside the NetworkService process which is mostly unaware of pages >>> and page views (I think; I guess UKM would require knowing about pages, >>> but I wasn't able to find UKM-related code under //services/network). We >>> could try to count the various ORB outcomes per URLLoaderFactory (which >>> roughly corresponds to a single HTML frame; I note that in the past >>> about:blank frame might have shared a URLLoaderFactory with their >>> opener/parent/initiator - that's probably ok), but getting this data would >>> take time... >>> >> >> OK, would it be fair to assume that at least for no-cors range requests >> (most likely video/audio requests), there would be more than one per page >> view, and hence we could expect page view based %ages to be significantly >> lower? >> >> >>> >>> If the majority of these requests are range requests, there's reason to >>>> believe there was more than one per page view. >>>> >>> >>> We can try to estimate how many responses report HTTP 206 status code. >>> I looked at Net.HttpResponseCode and "206: Partial Content" accounts for >>> around 0.35% - 1.13% of all HTTP responses (depending on the platform I >>> looked at). I've added more detailed data + links to a new section in the >>> ORB >>> telemetry results - Mar 2022 >>> <https://docs.google.com/document/d/1MbYQbL4WQyZdCQcZcKyzxHA0UxbHTC0O4bQXFgm8o6A/edit?usp=sharing> >>> document. >>> >>>> >>>> >>>>> >>>>> >>>>>> >>>>>> 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? >>>> >>> >>> No, we haven't discussed it yet. FWIW @Anne van Kesteren >>> <ann...@annevk.nl> is in CC of this email thread, so maybe they can >>> chime in? >>> >>>> >>>> >>>>> >>>>>> 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/CAL5BFfUU98WAdzrePPPi_R%3D4ow%3D1s0YJg1hMQXF2exDZA1arKA%40mail.gmail.com.
