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/CAL5BFfUn7cyWYwP043TRQ6e_EX8KrTvqdhMTWp%3Dx_%2BJF9XiKpw%40mail.gmail.com.
