Re: Intent to Ship: HTTPS pages with Cache-control: no-store and Back/Forward Cache

[Fergal Daly‏]

[BCC chrome-...@google.com]

On Tue, 11 Jul 2023 at 15:16, Mingyu Lei <le...@google.com> wrote:

+chrome-bfcache 

On Tue, Jul 11, 2023 at 1:08 PM Mingyu Lei <le...@google.com> wrote:

Contact emails

kenji...@chromium.org, fer...@chromium.org, deno...@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

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

Search tags

bfcache

TAG review

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Gecko: No signal

WebKit: No signal

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?

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.

[Mingyu Lei‏]

[Mingyu Lei‏]

+chrome-bfcache 

On Tue, Jul 11, 2023 at 1:08 PM Mingyu Lei <le...@google.com> wrote:

[Mike Taylor‏]

On 7/11/23 2:19 AM, 'Fergal Daly' via blink-dev wrote:

[BCC chrome-...@google.com]

On Tue, 11 Jul 2023 at 15:16, Mingyu Lei <le...@google.com> wrote:

+chrome-bfcache 

On Tue, Jul 11, 2023 at 1:08 PM Mingyu Lei <le...@google.com> wrote:

Contact emails

kenji...@chromium.org, fer...@chromium.org, deno...@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

Search 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?

--
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+...@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.

[Daniel Bratell‏]

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

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.

[Yoav Weiss‏]

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?  

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.

[Mingyu Lei‏]

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

[Mingyu Lei‏]

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.

[Yoav Weiss‏]

Hey Mingyu & Fergal,

Given the fact that getting this heuristic wrong can have *significant* negative implications on impacted users, I think we need to be very careful here.

I'd love to see a plan to validate the heuristic we'd pick here such that its coverage is as close to 100% as we can in terms of hitting the "excessive cache limits" bucket (and missing the "user sensitive data" bucket). Alternatively, maybe we could use a mix of outreach and a new API (or fix Clear-Site-Data) to help us fish out the "excessive cache limits" crowd?

Cheers :)

Yoav

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAN_fHtnGnrwo9wQXehgHkfoCYXa7icVqivTUC-ZuimKHkGbY1g%40mail.gmail.com.

[Mike Taylor‏]

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

[Kenji Baheux‏]

On Sat, Jul 29, 2023 at 3:03 AM Mike Taylor <mike...@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"...

no-cache means it's ok to cache but you must revalidate before re-using what you have.

must-revalidate seems more strict than no-cache because of the following bits: "In all circumstances a cache MUST obey the must-revalidate directive; in particular, if a cache cannot reach the origin server for any reason, it MUST generate a 504 (Gateway Timeout) response.". no-cache doesn't have these extra details.

So, maybe this 3 directives combo could be interpreted as this-is-quite-sensitive-stuff, or it could be a mix of that and folks copy-pasting cache-control recipes.

Note: there is also the "private" directive and guidance from Fastly to combine no-store and private. On the other hand, MDN disagrees that this even makes sense, but in practice it's apparently what folks have to do with some CDNs (discussion in Japanese) to avoid edge cases such as race conditions.

Fergal, should / could we add a histogram of cache-control values and combos?

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/561ff7c5-45aa-0c9e-8157-924199f82fb4%40chromium.org.

--

Kenji BAHEUX (my how-to)

Product Manager - Chrome

Google Japan

[Daniel Bratell‏]

In this whole discussion I am missing input from web developers. They must have expectations and opinions on these flags, but what do we know about their expectations and opinons? What is best industry practices? Is there a way to get more of that kind of input?

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADWWn7Uz7cBv1ux4oGkUG%3Dm6YxYpuZ5RDdNSEyT1ECVPVHC10Q%40mail.gmail.com.

[Fergal Daly‏]

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 Fri, 28 Jul 2023 at 13:57, Yoav Weiss <yoav...@chromium.org> wrote:

Hey Mingyu & Fergal,

Given the fact that getting this heuristic wrong can have *significant* negative implications on impacted users, I think we need to be very careful here.

I'd love to see a plan to validate the heuristic we'd pick here such that its coverage is as close to 100% as we can in terms of hitting the "excessive cache limits" bucket (and missing the "user sensitive data" bucket). Alternatively, maybe we could use a mix of outreach and a new API (or fix Clear-Site-Data) to help us fish out the "excessive cache limits" crowd?

> 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?  

It's important to clarify something. Our goal is not to avoid restoring pages containing *any* sensitive data. Our goal is to avoid restoring pages containing sensitive data that the user no longer has access to. If cookies have not changed, then the browser's HTTP request will be the same as last time and our assumption is that the decisions about access will also be the same. We know this assumption is not entirely correct, resources could be deleted or access could be changed on the server, hence our shorter timeout. We can break the problem down as follows

• changes on the client result is loss of access (e.g. cookies/access-tokens changed/deleted) - we believe this is covered

• changes on the server results in loss of access - this breaks down further

• site has implemented a way to immediately reflect those changes to open pages, e.g. using EventSource - this will continue to work either by causing them to be evicted or by delivering events as soon as they are restored from BFCache

• site has not implemented a way to immediately reflect those changes to open pages - in this case users can hold onto this data indefinitely. We are adding an additional window where this data could also reappear from BFCache. It would be surprising for a site to be concerned about the latter but not with the former.

XMLHttpRequest, fetch, WebTransport, WebRTC, WebSocket complicate this as they give a route for sensitive data to appear in the page outside of navigation-driven requests and that is why we block restoring if we see any of those (for XHR and fetch we only block if the response is CCNS, for the others we simply have to assume that all data is sensitive).

Given all that, we don't have any way to estimate how often it would happen that sensitive content that the user has lost access to would appear from BFCache. If we had a way to measure it, we would probably use that as a heuristic to prevent BFCaching. We believe it would only happen if e.g. a server-side change removed the user's access to the data as discussed above.

Daniel:

> 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?

There is no explicit promise that CCNS prevents BFCaching. The CCNS header, or in general, all the Cache-control directives, are intended to control the HTTP caching, so the explicit promise is about HTTP cache. BFCache is not part of the HTTP caching, and developers should not interpret the CCNS header as a promise that the page will not be BFCached. Indeed, there is a consensus about not providing any explicit way of preventing BFCache to avoid abuse. This web.dev article also touches on the difference between BFCache and HTTP cache with the Cache-control header.

There is an implicit promise that comes from the fact that CCNS has blocked BFCache. It’s inevitable that some sites have already set their expectations on the CCNS header blocking BFCache. Some sites will malfunction when they start to be restored from BFCache. This was also true when we launched BFCache for non-CCNS sites.

We believe that BFCache is a huge user benefit. We launched it knowing that some pages would malfunction. The benefit to users outweighs the cost of some devs having to update their sites to work with BFCache. We don't think CCNS sites should get a special pass. The concern with CCNS-sites is that they often deal with sensitive information and that is why we have put so much effort into making sure that that kind of information is not inappropriately resurfaced as a result of BFCache. There may be other types of malfunction due to BFCache. It seems like those kinds of problems should be subject to the same calculus of user benefit vs dev cost as went into the original BFCache launch.

F

[Fergal Daly‏]

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 <mike...@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. 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

[Daniel Bratell‏]

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAozHL%3D0vS96LyxmMgf7C7U93FudaP6k7OLX0MKq5jdW5fNZzA%40mail.gmail.com.

[Mingyu Lei‏]

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

[Vladimir Levin‏]

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.

Is there a simple solution to this if CCNS doesn't prevent BFCache?

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

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.

[Fergal Daly‏]

On Thu, 7 Sept 2023 at 00:21, Daniel Bratell <brat...@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?

It's a sliding scale. At 3 minutes we expect to lose about 16% of cache hits to timeout (some will have some other blocking reason). At 2 minutes that's 22% and at 1 minute it's 34%. 

Any site that has a shorter timeout and wants to preserve would needs to check for it in pageshow when coming back from BFCache.

Again, it comes down to a trade-off between some small number of sites who have very short timeouts vs the performance benefit,

F

[Fergal Daly‏]

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

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,

F

 

[Vladimir Levin‏]

On Mon, Sep 11, 2023 at 8:46 AM 'Fergal Daly' via blink-dev <blin...@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 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 :)

 

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.

[Yoav Weiss‏]

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 <blin...@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?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2O%3DgcdgvJdsCJmP6oG6qf4k0hXM4UePqzGH1ZfQZDMEZg%40mail.gmail.com.

[Vladimir Levin‏]

On Sat, Sep 16, 2023 at 7:14 AM Yoav Weiss <yoav...@chromium.org> wrote:

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 <blin...@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?

I would be concerned if we recommend this particular snippet as a solution. The visual behavior of CCNS and this snippet are not the same, even if you ignore performance.

Compare:

https://rocky-merciful-creek.glitch.me/nostore/one.html?delay=1000&nostore=1 

and:

https://rocky-merciful-creek.glitch.me/nostore/one.html?delay=1000&nostore=0

Both these sites have a 1000ms server delay. In the first case, where we use CCNS, when you go back, the delay is spent looking at a page before navigation happens. In the latter case, where we use the snippet, we are looking at a blank page that reloads. 

I understand the fact that CCNS is preventing a lot of BFCache usage and appreciate the desire to fix this _in cases that are abusing it_. For me, the problem is that there are use-cases where the situation is not about cookies or security, where the developer is correctly using CCNS to refresh the contents of a frequently changing (on the server) page. 

I know this is impossible to measure, but is there a sense / gut feeling for how large is CCNS use for "non-security, refresh the content" cases? If it's small enough then recommending app specific script solutions seems ok, although I think it will also be impossible to measure how many sites resort to that. 

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.

[Chris Harrelson‏]

Please also make sure to complete all of the other shipping gate reviews.

Thanks!

Chris

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2MNvQL%2BCUUbYa2bfN0JYPxrd9JV%3DrY_zR8Nw3kFjGp6bQ%40mail.gmail.com.

[Jason Robbins‏]

On Friday, September 29, 2023 at 1:01:54 PM UTC-7 Chris Harrelson wrote:

Please also make sure to complete all of the other shipping gate reviews.

I think a bug in ChromeStatus may have caused some confusion on this feature entry.  The feature entry has type "Web developer facing code change", so its bilnk-dev thread should have had subject line prefix "Web-facing change PSA" rather than "Intent to ship".  And, according to the launching-features doc, it does not require any approvals, which is why there are no other gates offered in the ChromeStatus UI.  A fix for that subject-line prefix bug should go live today.

Of course, the point of a PSA is to allow concerns to be raised and I see that this is a very active thread.  So, all that should be worked through.  Its a mater of the the API Owners prerogative to request any other reviews that they think are appropriate, but it is not automatically required by the process for this feature type.  Also, I see that the launch entry had some approvals.

Thanks,

jason! 

[Jason Robbins‏]

At this morning's API Owners meeting, they asked me to add all review gate types to all of the "web developer facing code change" features that are currently under review, including this one.  So, I have added Privacy, Security, Enterprise, Debuggability, and Testing gates to your feature entry. 

Please click the gate chips in the "Prepare to ship" stage on your feature detail page.  For each one, answer survey questions and request that of the cross-functional review.  You can request them all in parallel.  In cases where you already have the go/launch bit approved, you can note that in a comment on that gate for a potentially faster review.

Thanks,

jason!

[Yoav Weiss‏]

I just discussed this with Fergal offline:

• The risky scenario is one where revocation of sensitive info (logout, access revoked) happens on the server-side only without a client-side update.
• In such a scenario on a shared computer, someone could back-button their way into someone else's sensitive info. 
• It might be interesting to talk to security folks (and maybe Project Zero folks) to see if this is not happening already with content that's not CCNS decorated.
• It would be good to run a survey of potentially-sensitive services and try to get a signal from them on how many of them are properly doing revocation on the client side.
• I'd love ideas on how we can scale such a survey beyond manual inspection of a few known services.
• It could be interesting to try and ship a version of this with a shorter timeout, to minimize the risk of users leaving the machine unattended.
• If we go that route, it'd be good to think through how we'd be able to increase that timeout over time, after gaining more confidence that the risky scenario isn't happening in the wild.

[Vladimir Levin‏]

Are there any spec changes planned for this feature? I'm not sure if the README linked under Specification is meant to make it into WHATWG, maybe to close out https://github.com/whatwg/html/issues/7189

The only spec I could find about CCNS is https://www.rfc-editor.org/rfc/rfc9111#section-5.2.1.5, so I'm not sure how to reconcile possibly contradicting language in the specs

Thanks!

vmpstr

--

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+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUszpq%3DS%3DOZ4k_GnopJMRcTnL_trq5iF8J-kAzeYEiqKA%40mail.gmail.com.

[Yoav Weiss‏]

On Thu, Oct 12, 2023 at 3:56 PM Vladimir Levin <vmp...@chromium.org> wrote:

Are there any spec changes planned for this feature? I'm not sure if the README linked under Specification is meant to make it into WHATWG, maybe to close out https://github.com/whatwg/html/issues/7189

The only spec I could find about CCNS is https://www.rfc-editor.org/rfc/rfc9111#section-5.2.1.5, so I'm not sure how to reconcile possibly contradicting language in the specs

Great questions! Fergal - can you answer that?

Also, Vlad previously asked about the recommended pattern for folks to handle credential revocation with BFCache and his concerns with the snippet suggested upthread. It'd be great to address that.

[Fergal Daly‏]

On Sat, 16 Sept 2023 at 15:14, Yoav Weiss <yoav...@chromium.org> wrote:

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 <blin...@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?

We recommend people write their pages to correctly handle BFCache, e.g. by updating the content to be correct in pageshow (with persisted==true). How to do that is highly dependent on the page, so there's no universally applicable advice or code-snippet. The snippet above is the last-resort for pages sites that don't want to do it "properly",

F

[Fergal Daly‏]

On Thu, 12 Oct 2023 at 23:05, Yoav Weiss <yoav...@chromium.org> wrote:

On Thu, Oct 12, 2023 at 3:56 PM Vladimir Levin <vmp...@chromium.org> wrote:

Are there any spec changes planned for this feature? I'm not sure if the README linked under Specification is meant to make it into WHATWG, maybe to close out https://github.com/whatwg/html/issues/7189

The only spec I could find about CCNS is https://www.rfc-editor.org/rfc/rfc9111#section-5.2.1.5, so I'm not sure how to reconcile possibly contradicting language in the specs

Great questions! Fergal - can you answer that?

RFC9111 is about HTTP caches. BFCache is not a HTTP cache, so RFC 9111 does not apply. Of course the reality of implementations and expectations vs spec is a problem. Some more discussion here

BFCache and cases where it can/can't be used are specced in the HTML standard. We have had very little engagement from other vendors on this particular idea but Safari tried to cache all CCNS pages in the past. I am hoping that if we demonstrate a way to cache some of them safely, they would be on board. Also any browser is free to be *more* conservative than the spec while still staying in-spec as BFCaching at all is always optional.

Here is cdumez of Safari

Safari / WebKit shipped with all pages going into the bfcache no matter what (including cache-control: no-store). The only push back we received was the fact that after you log out of a site, you could still go back and see a page you should no longer be able to see. We agreed that this feedback was valid and our short-term fix was to bypass the bfcache when the page uses cache-control: no-store. Sadly, many sites use this and their intention is likely not to prevent the bfcache. This is not something we like for the long term.

F

[Vladimir Levin‏]

On Fri, Oct 13, 2023 at 12:00 AM 'Fergal Daly' via blink-dev <blin...@chromium.org> wrote:

On Thu, 12 Oct 2023 at 23:05, Yoav Weiss <yoav...@chromium.org> wrote:

On Thu, Oct 12, 2023 at 3:56 PM Vladimir Levin <vmp...@chromium.org> wrote:

Are there any spec changes planned for this feature? I'm not sure if the README linked under Specification is meant to make it into WHATWG, maybe to close out https://github.com/whatwg/html/issues/7189

The only spec I could find about CCNS is https://www.rfc-editor.org/rfc/rfc9111#section-5.2.1.5, so I'm not sure how to reconcile possibly contradicting language in the specs

Great questions! Fergal - can you answer that?

RFC9111 is about HTTP caches. BFCache is not a HTTP cache, so RFC 9111 does not apply. Of course the reality of implementations and expectations vs spec is a problem. Some more discussion here

I'm not sure I agree with this, or the reasoning in the link. First of all, this intent thread is about ignoring CCNS in _some cases_. In other cases, CCNS is respected, so it seems like BFCache is de facto subject to RFC 9111.

This is, I guess, a bit philosophical but the spec says:

the cache MUST NOT intentionally store the information in non-volatile storage and MUST make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it.

Note that the spec here does not make any exceptions for things like cookie state not changing or anything else. The document when frozen is indeed a volatile storage of the server response, processed and stored in some particular format (ie the DOM tree). I admit it's a bit weird to think about it this way, since the live document is technically also this cache. Whereas I agree that BFCache is not strictly an HTTP Cache, I don't quite follow why CCNS should not apply to the BFCache in some cases.

To me, BFCache seems like "a better http cache" which already has rendered results, not a completely separate cache that is not subject to CCNS.

But I'm late to the game, and I see that the topic of "BFCache is not HTTP Cache" has already been discussed a lot. I'm not convinced by existing arguments, but I also don't think I'll be able to convince anyone of my position.

My problem with the consensus in https://github.com/whatwg/html/issues/5744 is the following. People seem to agree that we don't want a *new* api that specifically prevents pages from entering BFCache. I don't believe it's appropriate to draw a conclusion that there is consensus that BFCache should not be subject to any *existing* APIs that prevent pages from entering it. This might be true independently, but I don't think one follows from the other.  To quote this comment:

"... And what is the problem with the bank case? I'd expect bank may want to ensure its page doesn't enter bfcache, or any other cache, by using no-store (and other) header(s) or something ..."

That comment sounds to me like "the status quo is good enough, because there are already ways of preventing any cache, including bfcache." If we were to claim consensus on doing this work, I'd personally want to see a more explicit "let's make it so pages still enter BFCache despite CCNS in these cases." The comment from cdumez you quoted is good, but maybe following-up there is worthwhile.

I concede though that I'm by no means an expert here, so I don't want to block moving this forward any longer. I just want to say that it's typically easy to be fast if you show stale data, and shifting the blame to the site for using CCNS instead of refreshing needed content in script doesn't seem appropriate. I personally would not want to be the judge of whether CCNS use is appropriate or not since I don't know what "appropriate" is in this case.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAozHLkA5eFwcvRsTAZhy728KFaBjd5W5EZpP2%3DMmC42ngMUuQ%40mail.gmail.com.

[Yoav Weiss‏]

Thanks David!

It's great to see that this will be disabled in modes where we *know* the machine is shared.

Fergal - could you address concerns about web developer advice? What should we tell web developers to do on their logout pages?

On Fri, Nov 10, 2023 at 8:37 AM David Dworken <ddwo...@google.com> wrote:

Chiming in to say that we discussed the security concerns around this proposal quite extensively internally and overall we believe that with the short timeout, the security risks are acceptable. The residual security risk is for servers that implement purely server-side logouts and is only exploitable for a very short period of time (3 minutes). In addition, other mitigations like this one further reduce the risk such that we believe it is unlikely that this will lead to new security issues.  

[Fergal Daly‏]

On Fri, 10 Nov 2023 at 17:29, Yoav Weiss <yoav...@chromium.org> wrote:

Thanks David!

It's great to see that this will be disabled in modes where we *know* the machine is shared.

Fergal - could you address concerns about web developer advice? What should we tell web developers to do on their logout pages?

Yes, we are in discussion with dev-rel about this. They were already looking at producing advice for auth best practices. We will ensure that this is covered in that,

F

[David Dworken‏]

Chiming in to say that we discussed the security concerns around this proposal quite extensively internally and overall we believe that with the short timeout, the security risks are acceptable. The residual security risk is for servers that implement purely server-side logouts and is only exploitable for a very short period of time (3 minutes). In addition, other mitigations like this one further reduce the risk such that we believe it is unlikely that this will lead to new security issues.  

On Friday, October 13, 2023 at 7:14:46 AM UTC-7 vmp...@chromium.org wrote:

[Daniel Bratell‏]

Thanks for getting the security people to weigh in on this because that was really the main question for me. And it will still be controllable by a finch flag.

LGTM1 dependent on there being a published document outlining the options for web developers (i.e. the document you are already working on).

/Daniel

[Mike Taylor‏]

+1, thank you. LGTM2 w/ same condition.

[Yoav Weiss‏]

LGTM3 with the same condition.

[Vladimir Levin‏]

If possible, can you share this document on this thread when it is available?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXz6RHMEbN4uVKw9pcS7nNyZT-zoQAwf1iSoS6THqAcfw%40mail.gmail.com.

[Fergal Daly‏]

Thanks everyone. Yes we will keep this thread up to date before releasing this (we'll go to canary/dev very soon so that we start getting stability and impact signals),

F

[Thorsten Dencker‏]

SAP does fully support your intentions to get more webpages making use of the Back/Forward Cache (BFCache), because it is indeed a feature, which is improving user experience a lot. Still, we do see at least two risks associated with the current plan of storing also pages served with HTTP header cache-control: no-store (CCNS) – and the planned evictions:

1.       According to the proposals here and here you intent to evict webpages from the BFCache in case an HttpOnly cookie has changed. This is crucial for SAP’s web applications. We would like to ask you to ensure that this holds true for cross-origin iframes within the document as well. The webpage should be also evicted from the BFCache in case an HttpOnly cookie of a document inside a cross-origin iframe of the webpage has changed.

2.       In general we do see the risk for developers not being aware of all these exemptions for the CCNS header. Yes, one could argue that theoretically the BFCache does not fall under RFC 9111, section 5.2.1.5. However in the end the BFCache is storing information including confidential data for later use and indeed prohibits subsequent HTTP requests. With this it acts like a cache and these newly planned exemptions for CCNS are some kind of counter-intuitive. Therefor we would like to ask you to get this change of behavior officially documented, if possible in an RFC standard.

Richard & Thorsten

[Fergal Daly‏]

We now have a published doc that covers best practices for BFCache/CCNS (and much more) during logout. Please let us know if you have any feedback on it.

We will proceed with cautiously rolling out this change. Thanks everyone,

F

[Vladimir Levin‏]

Thank you for the update!

This is a good write up. One comment / question below

From the doc:

> Note that the pageshow event will trigger before the page is rendered for the first time upon being restored from a back/forward navigation, which guarantees that your login state check will let you reset the page to a non sensitive state.

Correct me if I'm wrong, but I think the viz surface displaying the persisted contents may be embedded and shown before the page produces a new frame. So although technically it is correct that this event will fire before the page produces a rendering and a new frame, a version of the content may be shown prior to that.

I'm not sure if I'm being overly pedantic here, or whether my understanding of this flow is incorrect.

Thanks again for the write up

Vlad

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAozHLmtJkE1f6GRF3f5NGvYSp%3DZvgU9H2oGxRza9jpeYbr_pQ%40mail.gmail.com.

[Fergal Daly‏]

On Wed, 6 Dec 2023 at 12:29, Vladimir Levin <vmp...@chromium.org> wrote:

Thank you for the update!

This is a good write up. One comment / question below

From the doc:

> Note that the pageshow event will trigger before the page is rendered for the first time upon being restored from a back/forward navigation, which guarantees that your login state check will let you reset the page to a non sensitive state.

Correct me if I'm wrong, but I think the viz surface displaying the persisted contents may be embedded and shown before the page produces a new frame. So although technically it is correct that this event will fire before the page produces a rendering and a new frame, a version of the content may be shown prior to that.

I'm not sure if I'm being overly pedantic here, or whether my understanding of this flow is incorrect.

I don't know if that's correct. I didn't think we kept any of the pixels while in BFCache. If you are correct, that sounds like a bug. I've filed https://crbug.com/1508728. Do you know who would know the answer to this?

The same issue comes up in discussions of a back-preview (e.g. on mobile when gesturing the go back, we could show a snapshot of the page) and the intention there is to never do this with CCNS pages,

F

[Fergal Daly‏]

On Wed, 6 Dec 2023 at 13:55, Fergal Daly <fer...@google.com> wrote:

On Wed, 6 Dec 2023 at 12:29, Vladimir Levin <vmp...@chromium.org> wrote:

Thank you for the update!

This is a good write up. One comment / question below

From the doc:

> Note that the pageshow event will trigger before the page is rendered for the first time upon being restored from a back/forward navigation, which guarantees that your login state check will let you reset the page to a non sensitive state.

Correct me if I'm wrong, but I think the viz surface displaying the persisted contents may be embedded and shown before the page produces a new frame. So although technically it is correct that this event will fire before the page produces a rendering and a new frame, a version of the content may be shown prior to that.

I'm not sure if I'm being overly pedantic here, or whether my understanding of this flow is incorrect.

I don't know if that's correct. I didn't think we kept any of the pixels while in BFCache. If you are correct, that sounds like a bug. I've filed https://crbug.com/1508728. Do you know who would know the answer to this?

This is weird. Here's a test page https://fergald.github.io/random/bfcache/pixels/ When it's restored from BFCache it has a pageshow handlers that

- pauses for 5s

- flips the colour from red->blue or blue->red.

What's weird is that going fwd/back

on desktop:

- the old BG-Colour is shown for 5s (but the page seems to be blank apart from that)

- then the content appears and the colour changes

on mobile:

- the current page is shown for 5s

- then the content appears and the colour changes

I'm not sure which behaviour I would describe as correct. I guess it's best to keep showing the old content rather than flashing an empty page if pageshow is taking a long time.

Either way, in both cases we do not see the old content but I think we should clean this up and also put in something to guard against a change where the old content is shown,

F

[Vladimir Levin‏]

On Wed, Dec 6, 2023 at 1:16 AM 'Fergal Daly' via blink-dev <blin...@chromium.org> wrote:

On Wed, 6 Dec 2023 at 13:55, Fergal Daly <fer...@google.com> wrote:

On Wed, 6 Dec 2023 at 12:29, Vladimir Levin <vmp...@chromium.org> wrote:

Thank you for the update!

This is a good write up. One comment / question below

From the doc:

> Note that the pageshow event will trigger before the page is rendered for the first time upon being restored from a back/forward navigation, which guarantees that your login state check will let you reset the page to a non sensitive state.

Correct me if I'm wrong, but I think the viz surface displaying the persisted contents may be embedded and shown before the page produces a new frame. So although technically it is correct that this event will fire before the page produces a rendering and a new frame, a version of the content may be shown prior to that.

I'm not sure if I'm being overly pedantic here, or whether my understanding of this flow is incorrect.

I don't know if that's correct. I didn't think we kept any of the pixels while in BFCache. If you are correct, that sounds like a bug. I've filed https://crbug.com/1508728. Do you know who would know the answer to this?

This is weird. Here's a test page https://fergald.github.io/random/bfcache/pixels/ When it's restored from BFCache it has a pageshow handlers that

- pauses for 5s

- flips the colour from red->blue or blue->red.

What's weird is that going fwd/back

on desktop:

- the old BG-Colour is shown for 5s (but the page seems to be blank apart from that)

I see the old page being shown for 5 seconds in this case, which I think is the viz surface that can presumably expose sensitive information: https://youtu.be/Bld0EWWpQcQ I don't know if the treatment is different if we have CCNS.

I've cc'ed some people on the bug that would know for sure.

 

Thanks!

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAozHLmTZFOEYcEUoai7WtG3TWJVwLY0J5Hxmu4kb7codQRDYQ%40mail.gmail.com.

[Fergal Daly‏]

On Thu, 7 Dec 2023 at 01:07, Vladimir Levin <vmp...@chromium.org> wrote:

On Wed, Dec 6, 2023 at 1:16 AM 'Fergal Daly' via blink-dev <blin...@chromium.org> wrote:

On Wed, 6 Dec 2023 at 13:55, Fergal Daly <fer...@google.com> wrote:

On Wed, 6 Dec 2023 at 12:29, Vladimir Levin <vmp...@chromium.org> wrote:

Thank you for the update!

This is a good write up. One comment / question below

From the doc:

> Note that the pageshow event will trigger before the page is rendered for the first time upon being restored from a back/forward navigation, which guarantees that your login state check will let you reset the page to a non sensitive state.

Correct me if I'm wrong, but I think the viz surface displaying the persisted contents may be embedded and shown before the page produces a new frame. So although technically it is correct that this event will fire before the page produces a rendering and a new frame, a version of the content may be shown prior to that.

I'm not sure if I'm being overly pedantic here, or whether my understanding of this flow is incorrect.

I don't know if that's correct. I didn't think we kept any of the pixels while in BFCache. If you are correct, that sounds like a bug. I've filed https://crbug.com/1508728. Do you know who would know the answer to this?

This is weird. Here's a test page https://fergald.github.io/random/bfcache/pixels/ When it's restored from BFCache it has a pageshow handlers that

- pauses for 5s

- flips the colour from red->blue or blue->red.

What's weird is that going fwd/back

on desktop:

- the old BG-Colour is shown for 5s (but the page seems to be blank apart from that)

I see the old page being shown for 5 seconds in this case, which I think is the viz surface that can presumably expose sensitive information: https://youtu.be/Bld0EWWpQcQ I don't know if the treatment is different if we have CCNS.

CCNS is not BFCached, so there is likely to be no special treatment of CCNS. Let's figure this out on the bug. Thanks,

F

[Mingyu Lei‏]

Hi everyone,

We have landed the change that will clear the fallback surface if a CCNS page is stored in BFCache, so the pixels from the CCNS page won't appear after navigating back. This change should resolve Vlad's concern mentioned in the most recent email.

The experiment that would restore BFCached CCNS page is now started on dev channel, and we will gradually roll out to beta and stable. Thanks a lot for your reviews and suggestions.

Mingyu

[Mingyu Lei‏]

Hi everyone,

We want to share a quick update that the CCNS experiment has been rolled out to 5% in stable.

Thanks,

Mingyu

[Erwin Hofman‏]

Just being curious here: Any updates regarding roll out percentage?

Op woensdag 29 mei 2024 om 04:45:44 UTC+2 schreef Mingyu Lei:

[Mingyu Lei‏]

Hi Erwin,

We have now decided to roll out the experiment to 10% by Oct 4.

[Barry Pollard‏]

We've also published this post with details and our rollout plans:

https://developer.chrome.com/docs/web-platform/bfcache-ccns#how_chrome_is_changing_this_behavior

You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/GuRqI7zXWMY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAN_fHtm09bRqVsK9JrQiXwNDh5Fuw1GAV05ToAEbs3yZvfyLKA%40mail.gmail.com.