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/CAKXHy%3Dds%3DxO0z3y%2BeN0LFkg6qerBjtBNdmQ0_u4Q0tdqyV%3DDjA%40mail.gmail.com.
