I share Daniel's concerns regarding the potential impact here. Essentially, we have 2 types of content that use CCNS: content that really shouldn't be brought back from BFCache (as it contains user sensitive data) and content where these headers were added as (excessive) measures to avoid storing the resource in regular cache.
Do we have a way to validate the heuristics y'all came up with and understand what would be their hit rate vs. miss rate? What makes us confident that no sensitive data would be caught in those heuristics as cacheable content? On Wed, Jul 19, 2023 at 11:07 PM Daniel Bratell <bratel...@gmail.com> wrote: > To me this seems to be touching a sensitive area and I'm not certain how > this will play out in the real world. > > Even if cache-control: no-store is being badly overused, and the numbers > you list seem to indicate that is the case, hasn't there been a promise to > web developers that such a resource will be forever gone once the page is > no longer shown, and is that a promise that can reasonably be broken? > > I really don't know. > > /Daniel > On 2023-07-11 17:11, Mike Taylor 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/d0aac097-9f2c-29dc-6f9b-03a757528151%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d0aac097-9f2c-29dc-6f9b-03a757528151%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/892c9b75-e073-97cb-1a20-9dd6c0c01042%40gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/892c9b75-e073-97cb-1a20-9dd6c0c01042%40gmail.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/CAL5BFfUG_%3DR8MROQ8vEG1wsgY8pcZeC7jS96Yskfvy%3D3VnxtFw%40mail.gmail.com.
