LGTM1 On Tue, Sep 26, 2023 at 9:42 PM David Adrian <dadr...@google.com> wrote:
> To make it easier for people who are not following the IETF to understand > the impact on browsers and Chrome, I have provided a brief explainer: > https://github.com/dadrian/ech-chrome > Thanks for the explainer. A brief paragraph RE the flow could also be useful. I'll try to PR something shortly. > On Wed, Sep 20, 2023 at 1:48 PM David Adrian <dadr...@google.com> wrote: > >> I'll note that Chrome does not require that the HTTPS RR be resolved over >> DoH to use ECH, under the argument that some ECH is still better than no >> ECH. Firefox only uses ECH when they are able to query HTTPS RR records >> over encrypted DNS. >> >> On Wed, Sep 20, 2023 at 12:54 PM David Benjamin <david...@chromium.org> >> wrote: >> >>> I think this discussion is conflating two different things: >>> >>> 1. Whether some content (sections 1 and 3 of the spec) was extracted >>> into an explainer. >>> 2. Particular questions about the spec that Blink API owners wanted >>> answers for. >>> >>> With the expectation that, had there been something under an explainer, >>> the questions in (2) would have been automatically answered. But if we >>> wrote an explainer, it would simply have contained sections 1 and 3. As >>> this is a TLS and networking feature, everything is naturally all written >>> from that context, including explainers. The norms and audiences are very >>> different from, say, a JavaScript API. In the same way that a web platform >>> explainer doesn't explain what origins, frames, documents, windows, and the >>> DOM are, yet folks in the TLS community won't necessarily know how webpages >>> are organized. (I can't tell you how many times I've had to explain the >>> implications of subresources in a browser to TLSWG folks!) >>> >>> That's not to say non-TLS folks can't look at this... we're certainly >>> interested in feedback from you all! But I'd suggest that, if something is >>> unclear to you all, keep in mind the different context and not assume it's >>> just due to the specification formats. Instead, just ask us! To sort out >>> the formalities, I've updated chromestatus.com to just link to sections >>> 1 and 3 of the spec under explainer, but that doesn't do anything to change >>> this fundamental difference in context. >>> >>> To your example question, ECH is orthogonal[*] to DNS over HTTPS. Since >>> it's orthogonal, I don't think we'd have covered that in the explainer >>> anyway. Rather your question is about how DoH works, independently of ECH. >>> (Even without ECH, HTTPS still depends on DNS!) But I can still answer: >>> >>> When you visit example.com, you query A, AAAA, and HTTPS-RR records for >>> example.com from your DNS resolver. (Confusingly, the DNS records are >>> also called "HTTPS". I've taken to writing "HTTPS-RR" to disambiguate.) The >>> ECH keys are in HTTPS-RR. Note HTTPS-RR is not specific to ECH and already >>> launched. ECH is just using one more piece of service information from >>> there. If we get any keys, we pass them to TLS, just as the A/AAAA >>> information is passed to TCP setup. >>> >>> If your DNS resolver happens to be DNS over HTTPS, those queries may >>> themselves require setting up a *different* HTTPS connection, to >>> *different* origin. If the DoH origin is specified by IP address, >>> there's no DNS lookup, including no HTTPS-RR lookup and we just don't do >>> ECH for that connection. (DoH or non-DoH, ECH, deployed with keys from DNS, >>> only works for DNS-based origins and not IP-based origins. But there is >>> also less to protect for an IP-based origin.) If the DoH origin is >>> specified by a DNS name, we indeed need a DNS lookup. That is not new with >>> ECH... before ECH, we needed to look up A and AAAA anyway. If that DNS >>> lookup went through DNS over HTTPS, that would indeed be a circular >>> dependency, but nothing to do with ECH. Just DoH. As that's unrelated to >>> this launch, I don't know the exact details, but I believe we just use the >>> system, non-DoH resolver to look up information for the DoH server. If we >>> get ECH keys as part of that, we'll use them, otherwise we won't. >>> >>> Are there other questions we can help answer? >>> >>> [*] Or rather, it is mechanically orthogonal. Of course, if you're using >>> cleartext DNS, the server name may be leaked from your DNS queries rather >>> than the ClientHello. Whether or not that's useful will depend a bit on >>> network vantage points, etc. E.g. it could be that our "cleartext" DNS >>> resolver is actually pointing to a localhost caching resolver that, itself, >>> forwards onto DoH outside the browser. Then ECH would be useful. We, from >>> the browser side, can't tell whether that's happening, so it's simplest to >>> just treat it as orthogonal. >>> >>> On Wed, Sep 20, 2023 at 12:25 PM Daniel Bratell <bratel...@gmail.com> >>> wrote: >>> >>>> We are fine with being flexible with the details when the defaults >>>> don't work out, but every field/question has an underlying purpose that we >>>> try to satisfy through some means. Sometimes some fields might seem >>>> superfluous, but the explainer field is one that is always valuable. >>>> >>>> The "explainer" has a couple of different consumers (not quite >>>> overlapping but why make it too easy). It serves as a way to introduce >>>> non-experts to a feature, it serves as an executive summary of a >>>> complicated feature and it serves to fill in some non-technical gaps for >>>> web developers, possibly with usage examples. When there is a public >>>> announcement of a feature in a certain Chromium version, that is most often >>>> based on the explainer, not any specification. >>>> >>>> Just as an example of something an explainer might have mentioned is >>>> why this involves keys in DNS and if HTTPS depends on DNS, what about DNS >>>> over HTTPS? It often say things that are obvious to area experts, but might >>>> not be obvious to everyone exposed to this change. >>>> >>>> Quite often an explainer can be lifted/extracted from another source, >>>> like a previous blog post, or the human friendly part of specification, but >>>> it still has to be packaged in non-scary way. You mentioned a release note, >>>> maybe that one was all that was needed? >>>> >>>> /Daniel >>>> On 2023-09-19 01:04, 'David Adrian' via blink-dev wrote: >>>> >>>> > Could we please request a signal? >>>> >>>> Done (and positive!). I had forgotten to add it to Chrome Status. >>>> https://github.com/WebKit/standards-positions/issues/46 >>>> >>>> As for the explainer, between sending the I2S and now, I updated the >>>> Chrome Status description to cover most of what David Benjamin discussed, >>>> and match what was previously communicated in Chrome release notes. I >>>> should have done this before sending the I2S, although I was under the >>>> impression that an RFC would be a sufficient explainer. >>>> >>>> I think specific sections in the RFC could be, when they provide a high-level overview before diving into the details. > I do understand why it is useful to provide information at a slightly >>>> higher and holistic level---I hope the updated description and David >>>> Benjamin's comments can stand as that for this Intent. >>>> >>>> More broadly, David Benjamin is right that we are effectively jamming a >>>> TLS change from the IETF through a process designed for the Web Platform >>>> and W3C. We mostly do this so that launches show up in Chrome Status, and >>>> organizations who are interested in following TLS changes can see them >>>> there. >>>> >>>> Now that launches show up in Chrome Status regardless of whether or not >>>> they are a Blink launch, we may want to consider no longer sending TLS >>>> launches through the Intent process, since they exist outside of the Web >>>> Platform >>>> >>>> I think that would be a suboptimal outcome. The Blink process provides transparency and visibility to the changes shipped in Chromium, and I think that network/TLS launches are not different in that respect. I'm more than happy to discuss how we can improve the process to make it less painful to ship TLS-y things through it. , and primarily cause discussion about process confusion (we're trying our >>>> best to fit them in!), and not actual impact. >>>> >>>> >>>> >>>> >>>> >>>> On Mon, Sep 18, 2023 at 9:53 AM David Benjamin <david...@chromium.org> >>>> wrote: >>>> >>>>> On Mon, Sep 18, 2023 at 10:06 AM Yoav Weiss <yoavwe...@chromium.org> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Sat, Sep 16, 2023 at 5:35 PM David Benjamin <david...@chromium.org> >>>>>> wrote: >>>>>> >>>>>>> On Sat, Sep 16, 2023 at 1:12 AM Yoav Weiss <yoavwe...@chromium.org> >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Sep 15, 2023 at 10:05 PM Mike Taylor < >>>>>>>> miketa...@chromium.org> wrote: >>>>>>>> >>>>>>>>> On 9/11/23 6:34 PM, 'David Adrian' via blink-dev wrote: >>>>>>>>> >>>>>>>>> Contact emails david...@chromium.org, dadr...@google.com >>>>>>>>> >>>>>>>>> Explainer None >>>>>>>>> >>>>>>>>> I think a short explainer that outlines what this is and what's >>>>>>>> the typical flow would be helpful. While that content could've been >>>>>>>> part of >>>>>>>> the draft, that doesn't seem to be the case, at least at a glance. >>>>>>>> >>>>>>> >>>>>>> This is a process mismatch that comes up for every networking >>>>>>> protocol. The expected audiences and also style of spec are very >>>>>>> different. >>>>>>> Explainers make sense for W3C-style specs where the other consumer of >>>>>>> the >>>>>>> feature is a web developer who wants to understand how to use the API >>>>>>> and >>>>>>> not how to implement it step-by-step. The audience for a network >>>>>>> protocol >>>>>>> is completely different. The other consumer of the feature is a TLS >>>>>>> server >>>>>>> software implementer, who *also* needs to understand the full >>>>>>> protocol. >>>>>>> >>>>>> >>>>>> Explainers are not destined only for web developers. >>>>>> In this particular case, I'd think the audience for this is the API >>>>>> owners (who may or may not have time to read the full I-D), as well as >>>>>> the >>>>>> broader Blink community that keeps tabs on what we're shipping, and may >>>>>> want to understand more about this feature and what it gives them as >>>>>> users. >>>>>> Note that I'm not necessarily asking for a long and complex document - a >>>>>> short explainer that outlines the status quo, what this is changing and >>>>>> how >>>>>> the new flow works would do the trick. >>>>>> >>>>>> >>>>>>> >>>>>>> When it gets filtered up to web developers and server operators, all >>>>>>> they see is how to configure their server software, which is specific to >>>>>>> that software. I.e. they would need to refer to their server software >>>>>>> documentation. >>>>>>> >>>>>>> As for an overview for a non-participant to understand the protocol, >>>>>>> section 1 gives an introduction, and section 3 of the draft covers the >>>>>>> typical flow. Keep in mind this is not a web platform API, but a TLS >>>>>>> extension that lives far, far below the HTTP abstraction, so one should >>>>>>> not >>>>>>> expect discussion of anything particularly webby. And, as noted above, >>>>>>> anything at the level of configuring server software will be >>>>>>> server-software-specific, so that also would not make sense here. >>>>>>> >>>>>> >>>>>> The intro in section 1 is great, but the flow could use a simpler >>>>>> explanation. >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Specification >>>>>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni >>>>>>>>> >>>>>>>>> Summary >>>>>>>>> >>>>>>>>> The TLS Encrypted ClientHello (ECH) extension enables clients to >>>>>>>>> encrypt ClientHello messages, which are normally sent in cleartext, >>>>>>>>> under a >>>>>>>>> server’s public key. This allows websites to opt-in to avoid leaking >>>>>>>>> sensitive fields, like the server name, to the network by hosting a >>>>>>>>> special >>>>>>>>> HTTPS RR DNS record. (Earlier iterations of this extension were called >>>>>>>>> Encrypted Server Name Indication, or ESNI.) >>>>>>>>> >>>>>>>>> >>>>>>>>> Blink component Internals>Network>SSL >>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork%3ESSL> >>>>>>>>> >>>>>>>>> Search tags ech <https://chromestatus.com/features#tags:ech>, esni >>>>>>>>> <https://chromestatus.com/features#tags:esni>, tls >>>>>>>>> <https://chromestatus.com/features#tags:tls>, ssl >>>>>>>>> <https://chromestatus.com/features#tags:ssl> >>>>>>>>> >>>>>>>>> TAG review Not applicable; this is a protocol under IETF >>>>>>>>> >>>>>>>>> TAG review status Not applicable >>>>>>>>> >>>>>>>>> Risks >>>>>>>>> >>>>>>>>> >>>>>>>>> Interoperability and Compatibility >>>>>>>>> >>>>>>>>> As a networking protocol, interoperability risks look different >>>>>>>>> from a web platform API: This is a draft of a developing protocol, so >>>>>>>>> the >>>>>>>>> final standard will differ from what we ship now. We manage this as in >>>>>>>>> other protocol work: the draft uses different codepoints in the DNS >>>>>>>>> record >>>>>>>>> and ClientHello, set up to not conflict with the final standard. >>>>>>>>> There is >>>>>>>>> also a risk of breaking buggy servers or network middleware. ECH is >>>>>>>>> DNS-gated, so non-ECH servers won't be exposed to ECH itself. We do >>>>>>>>> implement ECH's GREASE mechanism (section 6.2 of the draft), but this >>>>>>>>> should appear as any normal unrecognized extension to non-ECH servers. >>>>>>>>> Servers and network elements that are compliant with RFC 8446, >>>>>>>>> section 9.3, >>>>>>>>> should not be impacted. We will be monitoring for these issues as >>>>>>>>> part of >>>>>>>>> the experiment, comparing error rates and handshake times both for >>>>>>>>> HTTPS >>>>>>>>> servers as a whole, and the subset of those that advertise ECH in DNS. >>>>>>>>> >>>>>>>>> >>>>>>>>> *Gecko*: In development ( >>>>>>>>> https://blog.mozilla.org/security/2021/01/07/encrypted-client-hello-the-future-of-esni-in-firefox >>>>>>>>> ) >>>>>>>>> >>>>>>>>> *WebKit*: No signal >>>>>>>>> >>>>>>>>> Could we please request a signal? >>>>>>>>> >>>>>>>>> https://github.com/WebKit/standards-positions/issues/new/choose >>>>>>>>> >>>>>>>>> >>>>>>>>> *Web developers*: Positive ( >>>>>>>>> https://blog.cloudflare.com/encrypted-client-hello) >>>>>>>>> >>>>>>>>> *Other signals*: >>>>>>>>> >>>>>>>>> Ergonomics >>>>>>>>> >>>>>>>>> ECH is part of TLS, so it is largely abstracted away from web >>>>>>>>> platform APIs themselves. >>>>>>>>> >>>>>>>>> >>>>>>>>> Activation >>>>>>>>> >>>>>>>>> This is a network protocol and thus inherently requires server >>>>>>>>> software changes. It also requires keys deployed in the HTTPS DNS >>>>>>>>> record. >>>>>>>>> At this stage in the process, we do not expect ECH to be deployed >>>>>>>>> beyond a >>>>>>>>> few early adopters. Rather, this experiment is part of real-world >>>>>>>>> testing >>>>>>>>> for the developing protocol. The connection with the DNS record is of >>>>>>>>> particular note. It is possible that, due to DNS caching, etc., that >>>>>>>>> the >>>>>>>>> DNS record we fetch is out of sync with the server instance we talk >>>>>>>>> to. ECH >>>>>>>>> has a built-in recovery mechanism to repair these mismatches. >>>>>>>>> >>>>>>>>> Can you expand on these recovery mechanisms? (maybe as part of the >>>>>>>> explainer requested above) >>>>>>>> >>>>>>> >>>>>>> See section 3.2 and 6.1.6 of the draft. >>>>>>> >>>>>>> Broadly, if the server fails to decrypt the inner ClientHello, it >>>>>>> handshakes with the outer one instead and provides replacement keys. >>>>>>> That >>>>>>> handshake is authenticated against the config's public name, which >>>>>>> authenticates the replacement keys and the client retries the >>>>>>> connection. >>>>>>> >>>>>> >>>>>> Here again, an explainer would've been useful, assuming you don't >>>>>> expect reviewers and interested folks to read through the entire I-D. >>>>>> >>>>>> >>>>>>> >>>>>>>> One of the aims of the experiment will be to validate this >>>>>>>>> mechanism. >>>>>>>>> >>>>>>>>> >>>>>>>>> Security >>>>>>>>> >>>>>>>>> See >>>>>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-14#section-10 >>>>>>>>> for security considerations in the specification >>>>>>>>> >>>>>>>>> >>>>>>>>> WebView application risks >>>>>>>>> >>>>>>>>> Does this intent deprecate or change behavior of existing APIs, >>>>>>>>> such that it has potentially high risk for Android WebView-based >>>>>>>>> applications? >>>>>>>>> >>>>>>>>> No WebView-specific risks >>>>>>>>> >>>>>>>>> >>>>>>>>> Debuggability >>>>>>>>> >>>>>>>>> Servers that use ECH are visible in the DevTools security panel. >>>>>>>>> >>>>>>>>> >>>>>>>>> Will this feature be supported on all six Blink platforms >>>>>>>>> (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? >>>>>>>>> Yes >>>>>>>>> >>>>>>>>> While supported on all platforms, ECH requires keys fetched via >>>>>>>>> DNS in the new HTTPS record. Chrome can currently fetch the HTTPS >>>>>>>>> record >>>>>>>>> over DoH and over our built-in DNS resolver. >>>>>>>>> >>>>>>>>> Do we already support the HTTPS record for other purposes? Or >>>>>>>> would this intent also add HTTPS record support? >>>>>>>> >>>>>>> >>>>>>> We already support the HTTPS record. (That support could be >>>>>>> improved, but that's separate from this launch and something for the >>>>>>> loading/networking team to work on. This launch is about using ECH keys >>>>>>> when we manage to fetch them.) >>>>>>> >>>>>>>> >>>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>>>> ? No >>>>>>>>> >>>>>>>>> Can you expand on why? Is it due to implementation complexity of >>>>>>>> network tests in python? >>>>>>>> >>>>>>> >>>>>>> web-platform-tests has never been suitable for testing network >>>>>>> protocols, especially not TLS extensions. In addition to the limitations >>>>>>> caused by Python (not just implementation complexity, it's simply the >>>>>>> wrong >>>>>>> tool for that job), the infrastructure needed for testing network >>>>>>> protocols >>>>>>> is completely different, since it's not based on code running under a >>>>>>> web >>>>>>> page. Like most networking features, ECH is broadly invisible to the web >>>>>>> platform itself. It's all behind the HTTP abstraction. >>>>>>> https://github.com/web-platform-tests/wpt/issues/20159 >>>>>>> >>>>>>> This comes up for every networking protocol launch. Perhaps we need >>>>>>> to refine the processes here, so that networking protocol features go >>>>>>> through a slightly different template? >>>>>>> >>>>>> >>>>>> Alternatively, you could have a generic doc or issue that outlines >>>>>> those issues with WPT and networking tests. Then you could point to it in >>>>>> this section. >>>>>> >>>>> >>>>> The issue is the bug I linked above. In fact, that bug was already >>>>> listed in chromestatus.com entry. It looks like this is actually a >>>>> Blink process bug, where chromestatus.com does not fill this field >>>>> into this section of the email. I've filed >>>>> https://github.com/GoogleChrome/chromium-dashboard/issues/3335 >>>>> >>>>> In the meantime, I guess folks need to remember that the process is >>>>> buggy and you need to go to the chromestatus entry if you see a "No" here >>>>> when reviewing. >>>>> >>>>> >>>>>> Flag name on chrome://flags encrypted-client-hello >>>>>>>>> >>>>>>>>> Finch feature name None >>>>>>>>> >>>>>>>>> Non-finch justification None >>>>>>>>> >>>>>>>>> Requires code in //chrome? False >>>>>>>>> >>>>>>>>> Tracking bug https://crbug.com/1091403 >>>>>>>>> >>>>>>>>> Launch bug https://crbug.com/1349902 >>>>>>>>> >>>>>>>>> Availability expectation Feature is also being launched in >>>>>>>>> Firefox. >>>>>>>>> >>>>>>>>> Sample links >>>>>>>>> https://tls-ech.dev >>>>>>>>> >>>>>>>>> Estimated milestones >>>>>>>>> Shipping on desktop 117 >>>>>>>>> OriginTrial desktop last 116 >>>>>>>>> OriginTrial desktop first 115 >>>>>>>>> DevTrial on desktop 105 >>>>>>>>> Shipping on Android 117 >>>>>>>>> OriginTrial Android last 116 >>>>>>>>> OriginTrial Android first 115 >>>>>>>>> DevTrial on Android 105 >>>>>>>>> >>>>>>>>> Anticipated spec changes >>>>>>>>> >>>>>>>>> Open questions about a feature may be a source of future web >>>>>>>>> compat or interop issues. Please list open issues (e.g. links to known >>>>>>>>> github issues in the project for the feature specification) whose >>>>>>>>> resolution may introduce web compat/interop risk (e.g., changing to >>>>>>>>> naming >>>>>>>>> or structure of the API in a non-backward-compatible way). >>>>>>>>> n/a >>>>>>>>> >>>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>> https://chromestatus.com/feature/6196703843581952 >>>>>>>>> >>>>>>>>> Links to previous Intent discussions Intent to prototype: >>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/YEo4LqB7nWI >>>>>>>>> >>>>>>>>> >>>>>>>>> Intent to Experiment: >>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAF8qwaB488g2%3D1WdmFPnWaAYaXB2pXaVv0-Xe-XXqYFRi5y20A%40mail.gmail.com >>>>>>>>> >>>>>>>>> >>>>>>>>> This intent message was generated by Chrome Platform Status >>>>>>>>> <https://chromestatus.com/>. >>>>>>>>> -- >>>>>>>>> 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/CAGkh42KgSdG0D1YT3H8EjXkm4zys4i5A1jskyZcXGbaedGvxHQ%40mail.gmail.com >>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGkh42KgSdG0D1YT3H8EjXkm4zys4i5A1jskyZcXGbaedGvxHQ%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/d066fa66-d356-4be7-99ec-56db593280b0%40chromium.org >>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d066fa66-d356-4be7-99ec-56db593280b0%40chromium.org?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/CAGkh42JXymYrVqkLD2_-da-FhUVQAS6js1sP9B7ZmrjOC4pnYQ%40mail.gmail.com >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGkh42JXymYrVqkLD2_-da-FhUVQAS6js1sP9B7ZmrjOC4pnYQ%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/CAL5BFfV2b-h5RzqQCoyzXEUzh%3Dw8PAZOs1PXz%3DETN3cdGN%3DdEg%40mail.gmail.com.
