#786: early design review: bfcache/prerendering eviction APIs
Discussions
2023-04-tokyo
Fergal: another thing - cache-control no-store.. If you set cache-control no-store then it doesn't go into bfcache.. e.g. on mdn. but deleted from mdn. No longer good advice. It's a large blocker... across all the browsers... what if we just monitor cookies .. if we see cookies changing then we don't restore from bfcache... a few other ideas... End proposal is: you tell us what cookies you care about and if any of those change then we evict your pages, and if we see you using the authentication header at all then we evict... This is kind of risky... don't know if that covers everything... 19% pages on desktop blocked from cache-control no-store. If you don't tell us what cookies you care about then we default to all https cookies.
Tess: what group?
Fergal: not in any...
Tess: wicg? requires statement of interest...
Dan: would be good to see it going to a venue...
2023-07-03
Peter: we haven't looked at this yet
Tess: at a glance this seems reasonable. One of the complaints from e.g. banks with bf cache - I'm on a page, i log out, a hit the back button, i can still see my balance. Off hand this seems reasonable.
Yves: i looked at it and had the same feeling that it was OK.
Rossen: when they say it's an "early review" - do we know if there's experimentation happening?
Dan: question on multi-stakeholder - so far no info.
Dan: leaves comment
Rossen: in considered alterantives they've listed a header... choice to use js api is "arbitrary" ... appreciate transparency but curious... open to both...
Yves: there's a difference between not storing in a bfcache and not storing... I think that going to header only might be more difficult.
Dan: it's possible to use bfcache without javascript so... normally we would encourgae a non-js-centric solution...
Rossen: it seems like this is really "early"...
Dan: cache-control: no-store would be inapproproate because...
Yves: it's a different kind of cache and there is a use case for purging the bfcache only at logout while keeping it active during the navigation. Using headers at logout would be possible but it raise the issue of invalidating pages that are not related to the requested URI and possibly not considered anymore as part of the navigation.
2023-07-mos-eisley
We've discussed and looked at this during our vF2F. The API surface/design, use cases this attempts to solve seem valid - and is articulated through a well-written explainer.
The part that we *are* concerned about this proposal is more philosophical - the question that remains to be asked is whether exposing cache control going to work this time. If it doesn't this will potentially end up with a widely-used antipattern which eventually makes everyone's life difficult. This has happened in the past, and given how cache is a complex problem - there is a non-zero chance this will happen in the future. If the risks of (unintentional, e.g. "preventing cache on everything fixes a simple problem I have!" pattern for example.) misuse is higher than the gains of exposing this, then maybe this shouldn't be exposed.
OpenedNov 18, 2022
Wotcher TAG!
I'm requesting a TAG review of to invalidate documents in BFCache or prerendering when cookies or storage keys change.
We propose to add an API that allows a document to declare that it must be invalidated (evicted from BFCache or prerendering cancelled) if certain cookies or storage keys change while it is in inactive.
For example, the following JS snippet will cause any documents from this document’s origin which are currently inactive to be invalidated if the ‘SID’ cookie changes,
Similarly, the following JS snippet will cause any documents from this document’s origin which are currently inactive to be invalidated if the value of the key ‘authToken’ in session storage changes,
Further details:
You should also know that...
This the first step of a plan to allow pages with
Cache-Control: no-storeinto BFCache.We'd prefer the TAG provide feedback as (please delete all but the desired option):
☂️ open a single issue in our GitHub repo for the entire review
¹ For background, see our explanation of how to write a good explainer. We recommend the explainer to be in Markdown.
² Even for early-stage ideas, a Security and Privacy questionnaire helps us understand potential security and privacy issues and mitigations for your design, and can save us asking redundant questions. See https://www.w3.org/TR/security-privacy-questionnaire/.