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

--
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/d0aac097-9f2c-29dc-6f9b-03a757528151%40chromium.org.

Reply via email to