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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> wrote: >> >>> On 7/11/23 2:19 AM, 'Fergal Daly' via blink-dev wrote: >>> >>> [BCC [email protected]] >>> >>> On Tue, 11 Jul 2023 at 15:16, Mingyu Lei <[email protected]> wrote: >>> >>>> +chrome-bfcache <[email protected]> >>>> >>>> On Tue, Jul 11, 2023 at 1:08 PM Mingyu Lei <[email protected]> wrote: >>>> >>>>> Contact emails [email protected], [email protected], >>>>> [email protected], [email protected] >>>>> >>>>> 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 [email protected]. >>> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAozHL%3D0vS96LyxmMgf7C7U93FudaP6k7OLX0MKq5jdW5fNZzA%40mail.gmail.com.
