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%
- *No cookie modification: 6.70%*
- With non-HttpOnly cookie modifications only: 1.38%
- With HttpOnly or non-HttpOnly cookie modifications: 0.55%
- With RPC containing CCNS response header: 10.13%
- No cookie modification: 1.01%
- With non-HttpOnly cookie modifications only: 7.86%
- 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 <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>
>> .
>>
>>
--
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/CAN_fHtnGnrwo9wQXehgHkfoCYXa7icVqivTUC-ZuimKHkGbY1g%40mail.gmail.com.
