(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.
