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/CAN_fHtm7NTkEphkqhxegCGOZ1V0b8mCs2a%2B5%3D4GpCZW1_9ZEUA%40mail.gmail.com.
