On Wed, May 18, 2022 at 12:33 AM Yoav Weiss <[email protected]> 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 <[email protected]> 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 <[email protected]> to get >> that done? If you don't have time, I can look around for someone to support >> y'all (+Daniel Vogelheim <[email protected]>, for instance! Hello, >> Daniel!). >> >> -mike >> >> >> On Tue, May 17, 2022 at 8:50 AM Yoav Weiss <[email protected]> >> wrote: >> >>> >>> >>> On Thu, May 12, 2022 at 12:12 AM Łukasz Anforowicz <[email protected]> >>> wrote: >>> >>>> >>>> >>>> On Wed, May 11, 2022 at 12:24 AM Yoav Weiss <[email protected]> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Wed, May 11, 2022 at 2:56 AM Łukasz Anforowicz < >>>>> [email protected]> wrote: >>>>> >>>>>> On Mon, May 9, 2022 at 11:35 PM Mike West <[email protected]> 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 >>>> <[email protected]> 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 < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> On Fri, May 6, 2022 at 4:45 PM Mike Taylor <[email protected]> >>>>>>>> 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:* >>>>>>>>> [email protected], [email protected], [email protected] >>>>>>>>> >>>>>>>>> *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 [email protected]. >>>>>>>>> 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 [email protected]. >>>>>>>> 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 [email protected]. >>>>>> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA_NCUH1WAMA%3DTGfCZaqjkmPCj6tLgHtf9HVH1-om1ZK2ynZpA%40mail.gmail.com.
