search

WebKit / standards-positions

WebKit's positions on emerging web specifications
https://webkit.org/standards-positions/
242 stars 19 forks source link

Allow back-forward cache to no-store pages as long as cookies do not change #256

Open forberg opened 1 year ago

forberg commented 1 year ago

WebKittens

No response

Title of the spec

BFCache: cache-control: no-store

URL to the spec

https://github.com/whatwg/html/issues/7189

URL to the spec's repository

Description

Forking this off from https://github.com/whatwg/html/issues/5744 and https://github.com/whatwg/html/issues/5879.

Looking for feedback. I'm not sure if this is something we would try to spec or not but it's something that could increase BFCache hit-rate.

Cache-control: no-store (CCNS) is the largest BFCache-blocker in Android Chrome. About 15% of history navigations are blocked by CCNS (6% just that reason, 9% are combined with other reasons too, 80-90% of which are not spec-blockers, just things Chrome needs fix but some are timeouts). We do not check if CCNS is present on a subframe, only on the main frame.

The https://github.com/whatwg/html/issues/5744#issuecomment-661997090 that occurred when safari allowed CCNS pages into BFCache was that, on shared devices, the next user could go back to the previous user's logged-in page. It's also a problem that pages in BFCache may be out of date when significant state changes. Cookies usually capture the fact that this state has changed and for the login/logout state, which is critical, they should always capture it.

On Android Chrome we ran an experiment to measure how often cookies change when in BFCache. We considered cookies that > are accessible by the main frame of the page (since we don't block based on subframe CCNS) and we broke it down by HTTP-only cookies and other cookies. The results were very promising.

Of the 15% blocked, we saw that less than 1% had HTTP-only cookie modification while in BFCache and less than 6% had any cookie modification while in BFCache. To be clear, the pages in BFCache did not modify the cookies, some other active page on the same site did.

The most aggressive strategy would be evict CCNS pages only if a HTTP-only cookie is modified. This assumes that sites follow best practice and use HTTP-only cookies for login and other critical info and would increase the hit-rate recover about about 12 percentage points of cache hit-rate.

More conservative would be to evict CCNS pages if any cookie is modified.

There are upcoming changes to authentication (WebAuthn), however I believe these only impact how the user acquires their auth cookie but will not remove the need for auth cookies in the future (if something did, then I expect we would want to use it as an eviction signal too).