early design review: bfcache/prerendering eviction APIs

[fergald]

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,

inactiveDocumentController.invalidationSignals.cookies = ['SID'];

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,

inactiveDocumentController.invalidationSignals.sessionStorage = ['authToken'];

• Explainer¹ (minimally containing user needs and example code): https://github.com/fergald/explainer-bfcache-ccns/blob/main/api.md
• Security and Privacy self-review²: https://github.com/fergald/explainer-bfcache-ccns/blob/main/api.md#tag-security-and-privacy-questionnaire
• GitHub repo (if you prefer feedback filed there): https://github.com/fergald/explainer-bfcache-ccns
• Primary contacts (and their relationship to the specification):
  • Primary contacts (and their relationship to the specification):
    Fergal Daly (fergald), Google - designing/specifying/implementing in Chrome
• Organization/project driving the design: Google (BFCache team)
• External status/issue trackers for this feature (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/5197945132023808

Further details:

• [Yes ] I have reviewed the TAG's Web Platform Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): WICG
• The group where standardization of this work is intended to be done ("unknown" if not known): WHATWG
• Existing major pieces of multi-stakeholder review or discussion of this design:
  • allow back-forward cache to no-store pages as long as cookies do not change whatwg/html#7189
  • Add an API to opt-out of back-forward cache? whatwg/html#5744
  • Back-forward cache: Specifying ineligibility? whatwg/html#5879
  • https://docs.google.com/document/d/1YZvkd0nMk0VlaikLCcBtzX0CCUo9lLxoOUtEPbK2IYk/edit#heading=h.1pnql7664imc (2nd half)
• Major unresolved issues with or opposition to this design: None
• This work is being funded by: Google

You should also know that...

This the first step of a plan to allow pages with Cache-Control: no-store into 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/.

[fergald]

FYI, chrome is close to origin trial of the cookie-related parts of this along with unblock BFCache entry for pages with Cache-Control: no-store. The storage-related parts need some revision and add a lot more compexity, so are shelved for the time-being.

[torgo]

Hi @fergald is there any information on multi-stakeholder support? Also do you have any info you can share from any experimentation with developers? Have you explored the non js-centric solution any further?

[cynthia]

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.

[cynthia]

We think the use cases are valid, but still have some concerns around potential misuse patterns as we mentioned above. Closing with concerns as we haven't heard back and we don't think small delta changes in the API as it stands likely will change that.