Thanks for your answers Fergal. Now it's my turn to apologize for the late
reply..
My main concern is with pages that will not revoke cookies on the
client, but do so on the server.
Such pages will not reveal sensitive information with a regular history
navigation (as the server will no longer provide that info), but
would provide it after a BFCache navigation.
I agree it's very hard to know when this is happening. One experiment that
might shed some light on this could be one where we store e.g. hashes such
pages' HTML/JSON resources instead of BFCaching them, and then comparing
those with the actual HTML/JSON downloaded in cases where the user performs
a history navigation. Essentially, I think we could compare the would-be
BFCache navigation with the equivalent history navigation, in order to get
a sense of the risk. Ideally, we could then collect a list of origins/URLs
where such discrepancies are happening, and deep dive into a sample of
them, to estimate the number of cases with actual user risk (vs. cases
where the page just randomly changed over the timeout's period, which are
not scary)
On Mon, Sep 11, 2023 at 12:32 PM Vladimir Levin <vmp...@chromium.org> wrote:
>
>
> On Mon, Sep 11, 2023 at 8:46 AM 'Fergal Daly' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>>
>>
>> On Fri, 8 Sept 2023 at 02:21, Vladimir Levin <vmp...@chromium.org> wrote:
>>
>>> This is potentially a naive question, since I'm not familiar with all of
>>> the CC headers, but how would the following situation work (or rather how
>>> is this meant to work?):
>>>
>>> I have an "overview" page that lists some items that come from a
>>> database. This page has an input box with a button to add a new item. The
>>> way the button works is it POSTs to the same page to add an entry into some
>>> database, and then redirects to a new "details" page. The "overview" page
>>> also currently sends CCNS, so that when the user clicks back from the
>>> "details" page, they see an updated list which was re-fetched from the
>>> server. Without CCNS, going back hits BFCache and the list is not up to
>>> date.
>>>
>>
>> That seems correct and is a problem with BFCache in general. E.g. you hit
>> back and your shopping cart has the wrong number of items.
>>
>>
>>> Is there a simple solution to this if CCNS doesn't prevent BFCache?
>>>
>>
>> The one-size-fits-all solutions is something like
>>
>> addEventListener("pageshow", e => {
>> if (e.persisted) {
>> document.body.innerHTML = "";
>> location.reload();
>> }
>> })
>>
>
>> Which is not great for users
>>
>
Is this a pattern we want to recommend? What would be the performance
implications if this pattern becomes common?
but also not terrible, the time to load will be increased by the duration
>> of a BFCache restore which is mostly < 100ms and much less on a fast device.
>>
>
>
> I suspect that this will defeat things like paint holding. That is, the
> behavior of non-bfcache load is to typically to show the painted output of
> the last page while the navigation commits and shows a frame of the new
> page (within timeout limit). With this script, this will quickly show a
> blank page (at the speed of BFCache restore + one frame), and then begin
> the reload().
>
> So although I agree with your timing estimates, I think the behavior would
> look substantially worse than just a 100ms delay.
>
>
>>
>> The better UX would be to have a `pageshow` handler that refreshes just
>> the data that needs refreshing. The difficulty of doing that is heavily
>> dependent on the site design,
>>
>
> That's a fair point. This seems non-trivial though :)
>
>
>
>>
>> F
>>
>>
>>> This is a toy example:
>>> https://rocky-merciful-creek.glitch.me/nostore/one.html?nostore=1
>>> if you click the link and go back, the number changes. If query
>>> nostore=0 then it doesn't. The query parameter just controls whether CCNS
>>> is sent
>>>
>>> Thanks!
>>> vmpstr
>>>
>>>
>>>
>>> On Thu, Sep 7, 2023 at 5:40 AM 'Mingyu Lei' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
>>>> (Not to answer how the 3 minutes was originally decided, but just to
>>>> share a bit of the context.)
>>>>
>>>> The default BFCache timeout was set to 3 minutes on Chrome for a long
>>>> time. Only after Sep 2022, it was increased to 10 minutes after evaluating
>>>> the hit rate improvement and other impacts (https://crbug.com/1305878).
>>>> For CCNS pages, we will follow the old timeout of 3 minutes, or in other
>>>> words, the changes that increase BFCache timeout from last year won't be
>>>> applied to CCNS pages.
>>>>
>>>>
>>>> On Thu, Sep 7, 2023 at 12:21 AM Daniel Bratell <bratel...@gmail.com>
>>>> wrote:
>>>>
>>>>> Thanks for your answers. I think we are on the same page since I too
>>>>> consider this to be of high value to users. The difference in perceived
>>>>> performance is so large that I understand that it is worth adding some
>>>>> magic for.
>>>>>
>>>>> On the other hand, as you also know, there is a risk and I want to be
>>>>> sure that it is fully understood. You have mentioned a shorter timeout a
>>>>> couple of times, and the explainer says it will be 3 minutes instead of
>>>>> the
>>>>> default 10 minute cache timeout. I'm well aware of sites that time out
>>>>> authentications server side after a couple of minutes of inactivity and I
>>>>> guess 3 would be in the same ball park. Did you pick that particular
>>>>> number
>>>>> for any particular reason. Is it the lowest number that still gives any
>>>>> benefits?
>>>>>
>>>>> /Daniel
>>>>> On 2023-09-01 10:05, 'Fergal Daly' via blink-dev wrote:
>>>>>
>>>>> Sorry for the slow reply, I've had to focus on some other things in
>>>>> the last month. The reply below covers a few overlapping topics that were
>>>>> brought up in this thread by Yoav Weiss and Daniel Bratell.
>>>>>
>>>>>
>>>>> On Sat, 29 Jul 2023 at 03:03, Mike Taylor <miketa...@chromium.org>
>>>>> wrote:
>>>>>
>>>>>> Thanks for the additional analysis. Another question I have, if a
>>>>>> site sends:
>>>>>>
>>>>>> "Cache-Control: no-cache, no-store, must-revalidate" (copypasta from
>>>>>> https://stackoverflow.com/a/2068407),
>>>>>> would it be treated differently as "Cache-Control: no-store"? I'm trying
>>>>>> to think of signals that might be useful as
>>>>>> heuristics for "no seriously don't ever cache this"...
>>>>>>
>>>>>>
>>>>> We would prefer not to do this and other browsers are in agreement
>>>>> <https://github.com/whatwg/html/issues/5744>. If we give any kind of
>>>>> simple header that prevents BFCaching, it will become the wide-spread
>>>>> stack-exchange-documented way to opt out of BFCache. Any site that truly
>>>>> cannot tolerate its data entering BFCache and doesn't already fall under
>>>>> one of our conditions for avoiding BFCache, can erase content in a
>>>>> `pagehide` handler as they enter BFCache and reload it in a `pageload`
>>>>> handler if restored. This is pretty simple to do for anyone who truly
>>>>> needs it
>>>>> (worst case they trigger a reload from JS when leaving BFCache,
>>>>> obviously not a good user experience but we have to weight that against
>>>>> block BFCache for many users) but it still provides a little bit of a
>>>>> barrier, so hopefully people think twice and instead correctly support
>>>>> BFCache rather than casually opting out,
>>>>>
>>>>> F
>>>>>
>>>>> On 7/27/23 9:04 AM, Mingyu Lei wrote:
>>>>>>
>>>>>> Hi Mike,
>>>>>>
>>>>>> Following our previous response, we would like to share the usage
>>>>>> data that we have collected from the beta channel. 18.76% of history
>>>>>> navigations are not restored from BFCache because of the CCNS header
>>>>>> only.
>>>>>> The following are the breakdowns:
>>>>>>
>>>>>> - No RPC containing CCNS response header: 8.63%
>>>>>> - *No cookie modification: 6.70%*
>>>>>> - With non-HttpOnly cookie modifications only: 1.38%
>>>>>> - With HttpOnly or non-HttpOnly cookie modifications: 0.55%
>>>>>> - With RPC containing CCNS response header: 10.13%
>>>>>> - No cookie modification: 1.01%
>>>>>> - With non-HttpOnly cookie modifications only: 7.86%
>>>>>> - With HttpOnly or non-HttpOnly cookie modifications: 1.26%
>>>>>>
>>>>>> Based on these figures, we will update the proposal to evict the
>>>>>> BFCache entry with any cookie modification for the current phase. This
>>>>>> should give us 6.70% improvement in cache hit rate.
>>>>>>
>>>>>> We could continue the HttpOnly cookie discussion in the future.
>>>>>>
>>>>>> On Sat, Jul 22, 2023 at 12:46 AM Mingyu Lei <le...@google.com> wrote:
>>>>>>
>>>>>>> Hi Mike,
>>>>>>>
>>>>>>> Thanks for the comments. We have discussed the concerns you raised
>>>>>>> before and please find the replies below.
>>>>>>>
>>>>>>>
>>>>>>>> https://github.com/fergald/explainer-bfcache-ccns/blob/main/README.md#secure-cookies
>>>>>>>> references "HTTPS-only" cookies, as well as "secure" vs "insecure"
>>>>>>>> cookies.
>>>>>>>> By "HTTPS-only", do you mean a cookie that sets the "secure" attribute
>>>>>>>> (including "__Secure-" prefixes), _and_ sets "HttpOnly"? Or something
>>>>>>>> else?
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Later in
>>>>>>>> https://github.com/fergald/explainer-bfcache-ccns/blob/main/README.md#allow-ccns-documents-to-be-bfcached-without-the-api,
>>>>>>>> the proposal is that CCNS pages are safe to bfcache if no "HTTP-only"
>>>>>>>> cookies have changed. Are these cookies setting only the "HttpOnly"
>>>>>>>> attribute, or is this intended to say "HTTPS-only" as above?
>>>>>>>>
>>>>>>>
>>>>>>> The short answer is that we will only monitor HttpOnly cookies,
>>>>>>> regardless of whether they are secure or not. The terms in the explainer
>>>>>>> were unclear, and we will fix them.
>>>>>>>
>>>>>>> I see that
>>>>>>>> https://github.com/w3ctag/design-reviews/issues/786#issuecomment-1515742477
>>>>>>>> references this work. Did we learn anything from experimentation in the
>>>>>>>> wild (not sure if y'all ran an experiment)?
>>>>>>>>
>>>>>>>> I'm curious if y'all have looked at stats on the uptake of
>>>>>>>> secure/httponly cookies vs "non-secure" cookies being set by pages
>>>>>>>> returned
>>>>>>>> from RPCs sent with an Authorization header (though I wouldn't be
>>>>>>>> surprised
>>>>>>>> if we don't have UMA for that... perhaps just globally would be useful
>>>>>>>> to
>>>>>>>> consider).
>>>>>>>>
>>>>>>>
>>>>>>> We are currently conducting a Finch experiment to collect the hit
>>>>>>> rate on beta, and the data will be available next week. We will share it
>>>>>>> with you again after we have the data.
>>>>>>>
>>>>>>> With that data, we will be able to tell the percentage of page loads
>>>>>>> that observe HttpOnly cookie changes, any cookie changes, or no cookie
>>>>>>> changes. There will also be another dimension about whether the page had
>>>>>>> sent out RPC with CCNS response. There is no pre-existing UMA for this,
>>>>>>> but
>>>>>>> we have recorded the reasons why BFCache is not restored.
>>>>>>>
>>>>>>> My only concern (which may not be grounded in reality) would be for
>>>>>>>> sites not following best practices...
>>>>>>>
>>>>>>>
>>>>>>> We expect that there will be cases where pages are restored
>>>>>>> inappropriately where sites are not following good practice. We don't
>>>>>>> have
>>>>>>> an idea of the size of this problem. We will have data from the beta
>>>>>>> channel soon that will tell us what the difference would be in terms of
>>>>>>> BFCache hit-rate between *monitoring all cookies* and *only
>>>>>>> monitoring HttpOnly cookies*. Our thought process looks like this:
>>>>>>>
>>>>>>> If *monitoring all cookies* already gives us large hit-rate
>>>>>>> improvement, *or* the difference between *monitoring all cookies*
>>>>>>> and *only monitoring HttpOnly cookies* is small, then we are happy
>>>>>>> to just be conservative and go with *monitoring all cookies*.
>>>>>>> Otherwise*, we would like to discuss this further.
>>>>>>>
>>>>>>>
>>>>>>> ** "Otherwise" means monitoring all cookies will only give us
>>>>>>> negligible cache hit-rate improvement, and monitoring HttpOnly cookies
>>>>>>> will
>>>>>>> give us a much larger increase.*
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Mingyu
>>>>>>>
>>>>>>> On Wed, Jul 12, 2023 at 12:11 AM Mike Taylor <miketa...@chromium.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On 7/11/23 2:19 AM, 'Fergal Daly' via blink-dev wrote:
>>>>>>>>
>>>>>>>> [BCC chrome-bfca...@google.com]
>>>>>>>>
>>>>>>>> On Tue, 11 Jul 2023 at 15:16, Mingyu Lei <le...@google.com> wrote:
>>>>>>>>
>>>>>>>>> +chrome-bfcache <chrome-bfca...@google.com>
>>>>>>>>>
>>>>>>>>> On Tue, Jul 11, 2023 at 1:08 PM Mingyu Lei <le...@google.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Contact emails kenjibah...@chromium.org, fer...@chromium.org,
>>>>>>>>>> denom...@chromium.org, le...@chromium.org
>>>>>>>>>>
>>>>>>>>>> Specification
>>>>>>>>>> https://github.com/fergald/explainer-bfcache-ccns/blob/main/README.md
>>>>>>>>>>
>>>>>>>>>> Design docs
>>>>>>>>>> https://docs.google.com/document/d/1qX1w6L6laTzpFTh78dvT7wwC1060Z3he2Azp4BAwsUE/edit?usp=sharing
>>>>>>>>>>
>>>>>>>>>> https://github.com/fergald/explainer-bfcache-ccns/blob/main/README.md
>>>>>>>>>>
>>>>>>>>> This is a really well-written explainer, thank you!
>>>>>>>>
>>>>>>>> One point of clarification:
>>>>>>>>
>>>>>>>>
>>>>>>>> https://github.com/fergald/explainer-bfcache-ccns/blob/main/README.md#secure-cookies
>>>>>>>> references "HTTPS-only" cookies, as well as "secure" vs "insecure"
>>>>>>>> cookies.
>>>>>>>> By "HTTPS-only", do you mean a cookie that sets the "secure" attribute
>>>>>>>> (including "__Secure-" prefixes), _and_ sets "HttpOnly"? Or something
>>>>>>>> else?
>>>>>>>>
>>>>>>>> Later in
>>>>>>>> https://github.com/fergald/explainer-bfcache-ccns/blob/main/README.md#allow-ccns-documents-to-be-bfcached-without-the-api,
>>>>>>>> the proposal is that CCNS pages are safe to bfcache if no "HTTP-only"
>>>>>>>> cookies have changed. Are these cookies setting only the "HttpOnly"
>>>>>>>> attribute, or is this intended to say "HTTPS-only" as above?
>>>>>>>>
>>>>>>>> Summary
>>>>>>>>>>
>>>>>>>>>> A behavior change to safely store (and restore) pages in the
>>>>>>>>>> Back/Forward Cache despite the presence of a "Cache-control:
>>>>>>>>>> no-store" HTTP
>>>>>>>>>> header on HTTPS pages. This would allow pages to enter BFCache and be
>>>>>>>>>> restored as long as there are no changes to cookies or to RPCs using
>>>>>>>>>> the
>>>>>>>>>> `Authorization:` header.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Blink component UI>Browser>Navigation>BFCache
>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:UI%3EBrowser%3ENavigation%3EBFCache>
>>>>>>>>>>
>>>>>>>>>> Search tags bfcache
>>>>>>>>>> <https://chromestatus.com/features#tags:bfcache>
>>>>>>>>>>
>>>>>>>>>> TAG review
>>>>>>>>>>
>>>>>>>>> I see that
>>>>>>>> https://github.com/w3ctag/design-reviews/issues/786#issuecomment-1515742477
>>>>>>>> references this work. Did we learn anything from experimentation in the
>>>>>>>> wild (not sure if y'all ran an experiment)?
>>>>>>>>
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> TAG review status Not applicable
>>>>>>>>>>
>>>>>>>>>> Risks
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Interoperability and Compatibility
>>>>>>>>>>
>>>>>>>>> I'm curious if y'all have looked at stats on the uptake of
>>>>>>>> secure/httponly cookies vs "non-secure" cookies being set by pages
>>>>>>>> returned
>>>>>>>> from RPCs sent with an Authorization header (though I wouldn't be
>>>>>>>> surprised
>>>>>>>> if we don't have UMA for that... perhaps just globally would be useful
>>>>>>>> to
>>>>>>>> consider).
>>>>>>>>
>>>>>>>> My only concern (which may not be grounded in reality) would be for
>>>>>>>> sites not following best practices...
>>>>>>>>
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> *Gecko*: No signal
>>>>>>>>>>
>>>>>>>>>> *WebKit*: No signal
>>>>>>>>>>
>>>>>>>>> Can we request signals?
>>>>>>>>
>>>>>>>>
>>>>>>>>>> *Web developers*: No signals
>>>>>>>>>>
>>>>>>>>>> *Other signals*:
>>>>>>>>>>
>>>>>>>>>> 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?
>>>>>>>>>>
>>>>>>>>>> None
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Debuggability
>>>>>>>>>>
>>>>>>>>>> Will this feature be supported on all six Blink platforms
>>>>>>>>>> (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
>>>>>>>>>> No
>>>>>>>>>>
>>>>>>>>>> BFCache is not supported on WebView, so this change has no impact
>>>>>>>>>> there.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Is this feature fully tested by web-platform-tests
>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>>>>>>>>>> ? No
>>>>>>>>>>
>>>>>>>>>> Flag name on chrome://flags
>>>>>>>>>>
>>>>>>>>>> Finch feature name CacheControlNoStoreEnterBackForwardCache
>>>>>>>>>>
>>>>>>>>>> Requires code in //chrome? False
>>>>>>>>>>
>>>>>>>>>> Tracking bug
>>>>>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1228611
>>>>>>>>>>
>>>>>>>>>> Launch bug https://launch.corp.google.com/launch/4251651
>>>>>>>>>>
>>>>>>>>>> Estimated milestones
>>>>>>>>>> DevTrial on desktop 116
>>>>>>>>>> DevTrial on Android 116
>>>>>>>>>>
>>>>>>>>>> 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).
>>>>>>>>>> None
>>>>>>>>>>
>>>>>>>>>> Link to entry on the Chrome Platform Status
>>>>>>>>>> https://chromestatus.com/feature/6705326844805120
>>>>>>>>>>
>>>>>>>>>> Links to previous Intent discussions
>>>>>>>>>>
>>>>>>>>>> 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/CAAozHLkbL7vmubNOsrA2PKngz4xeV%3DXyuLN73oS4XBea50Xe9A%40mail.gmail.com
>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAozHLkbL7vmubNOsrA2PKngz4xeV%3DXyuLN73oS4XBea50Xe9A%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/CAAozHL%3D0vS96LyxmMgf7C7U93FudaP6k7OLX0MKq5jdW5fNZzA%40mail.gmail.com
>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAozHL%3D0vS96LyxmMgf7C7U93FudaP6k7OLX0MKq5jdW5fNZzA%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/CAN_fHtmo4p9pYZ3HNGqped8MCBfTWXuNd_VC%3DoV4PHEVi73W%3DA%40mail.gmail.com
>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAN_fHtmo4p9pYZ3HNGqped8MCBfTWXuNd_VC%3DoV4PHEVi73W%3DA%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/CAAozHLmW2XCFC1d61x1r%2B1c8z_PqoukKOs0EDgDct9cPvRc4eQ%40mail.gmail.com
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAozHLmW2XCFC1d61x1r%2B1c8z_PqoukKOs0EDgDct9cPvRc4eQ%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/CADsXd2O%3DgcdgvJdsCJmP6oG6qf4k0hXM4UePqzGH1ZfQZDMEZg%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2O%3DgcdgvJdsCJmP6oG6qf4k0hXM4UePqzGH1ZfQZDMEZg%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/CAL5BFfXTPGWGogayj_ohBcq4kmKYwUetrmOtNH%3DzVLRzjnn%2BRg%40mail.gmail.com.
