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