I talked to Daniel Vogelheim about this and we agreed that the best way to document this intermediary, Chromium-only state is with in-tree documentation, which Daniel is working on.
LGTM2 to ship, once that clearer documentation lands. On Tuesday, May 24, 2022 at 9:52:27 PM UTC+2 Łukasz Anforowicz wrote: > On Wed, May 18, 2022 at 12:33 AM Yoav Weiss <yoavwe...@chromium.org> > wrote: > >> Anne has put together a PR draft >> <https://github.com/whatwg/fetch/pull/1442>. Thanks Anne! :) >> >> Can y'all provide feedback on it? >> > > Yup - I've replied to some of the questions in ORB's issue tracker. > Removing CORB and replacing it with full ORB in the Fetch spec LGTM. > > >> Also, how far is the PR draft from what y'all are planning to ship? >> > > Not sure how to describe the distance. Maybe one way would be to share > some facts and estimates/guesses about WPT coverage: > > > - 100% of the currently existing wpt/fetch/corb tests continue to pass > with ORBv0.1. > - CORB and ORB differ (see also https://crbug.com/827633) in how they > block things like JSON or HTML: CORB replaces the old response with an > empty response body; ORB triggers a network error. Once that difference > is gone: > > > - 95+% of the existing CORB and ORBv0.1 tests under wpt/fetch/corb > should also apply to full ORB. The remaining 5% is mostly tests that > deal > with JSON parser breakers (https://github.com/annevk/orb/issues/30). > - ORB will require extra tests, in addition to the ones currently > under wpt/fetch/corb. I would estimate that ORBv0.1 would pass at > least > 50% of the final set of WPT tests. > > Another way to judge the distance between ORBv0.1 and full ORB is to look > at the differences listed in the docs that I've mentioned earlier in this > thread: > > Notably, the "Gradual CORB -> ORB transition" 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. > > > > -Lukasz > > >> 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/418ea310-7447-436c-8994-9a571d0ab27fn%40chromium.org.
