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%
o *No cookie modification: 6.70%*
o With non-HttpOnly cookie modifications only: 1.38%
o With HttpOnly or non-HttpOnly cookie modifications: 0.55%
* With RPC containing CCNS response header: 10.13%
o No cookie modification: 1.01%
o With non-HttpOnly cookie modifications only: 7.86%
o 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.
On Sat, Jul 22, 2023 at 12:46 AM Mingyu Lei <le...@google.com> wrote:
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
On Wed, Jul 12, 2023 at 12:11 AM Mike Taylor
<miketa...@chromium.org> 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 <mailto: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>.
