SAP does fully support your intentions to get more webpages making use of the *Back/Forward Cache (BFCache)*, because it is indeed a feature, which is improving user experience a lot. Still, we do see at least two risks associated with the current plan of storing also pages served with HTTP header *cache-control: no-store (CCNS)* – and the planned evictions:
1. According to the proposals here <https://docs.google.com/document/d/1qX1w6L6laTzpFTh78dvT7wwC1060Z3he2Azp4BAwsUE/edit> and here <https://github.com/fergald/explainer-bfcache-ccns/#enabling-bfcache-for-pages-that-set-cache-control-no-store-2-linked-proposals-to-get-there> you intent to evict webpages from the *BFCache* in case an HttpOnly cookie has changed. This is crucial for SAP’s web applications. We would like to ask you to ensure that this holds true for cross-origin iframes within the document as well. The webpage should be also evicted from the *BFCache* in case an HttpOnly cookie of a document inside a cross-origin iframe of the webpage has changed. 2. In general we do see the risk for developers not being aware of all these exemptions for the *CCNS* header. Yes, one could argue that theoretically the *BFCache* does not fall under RFC 9111, section 5.2.1.5 <https://datatracker.ietf.org/doc/html/rfc9111#name-no-store>. However in the end the *BFCache* is storing information including confidential data for later use and indeed prohibits subsequent HTTP requests. With this it acts like a cache and these newly planned exemptions for *CCNS* are some kind of counter-intuitive. Therefor we would like to ask you to get this change of behavior officially documented, if possible in an RFC standard. Richard & Thorsten On Thursday, November 16, 2023 at 5:37:45 AM UTC+1 Fergal Daly wrote: > Thanks everyone. Yes we will keep this thread up to date before releasing > this (we'll go to canary/dev very soon so that we start getting stability > and impact signals), > > F > > On Thu, 16 Nov 2023 at 05:30, Vladimir Levin <vmp...@chromium.org> wrote: > >> If possible, can you share this document on this thread when it is >> available? >> >> On Wed, Nov 15, 2023 at 12:52 PM Yoav Weiss <yoav...@chromium.org> wrote: >> >>> LGTM3 with the same condition. >>> >>> On Wed, Nov 15, 2023 at 6:44 PM Mike Taylor <mike...@chromium.org> >>> wrote: >>> >>>> +1, thank you. LGTM2 w/ same condition. >>>> On 11/15/23 12:39 PM, Daniel Bratell wrote: >>>> >>>> Thanks for getting the security people to weigh in on this because that >>>> was really the main question for me. And it will still be controllable by >>>> a >>>> finch flag. >>>> >>>> LGTM1 dependent on there being a published document outlining the >>>> options for web developers (i.e. the document you are already working on). >>>> >>>> /Daniel >>>> On 2023-11-10 09:45, Fergal Daly wrote: >>>> >>>> On Fri, 10 Nov 2023 at 17:29, Yoav Weiss <yoav...@chromium.org> wrote: >>>> >>>>> Thanks David! >>>>> It's great to see that this will be disabled in modes where we *know* >>>>> the machine is shared. >>>>> >>>>> Fergal - could you address concerns about web developer advice? What >>>>> should we tell web developers to do on their logout pages? >>>>> >>>> >>>> Yes, we are in discussion with dev-rel about this. They were already >>>> looking at producing advice for auth best practices. We will ensure that >>>> this is covered in that, >>>> >>>> F >>>> >>>> >>>> >>>>> >>>>> >>>>> On Fri, Nov 10, 2023 at 8:37 AM David Dworken <ddwo...@google.com> >>>>> wrote: >>>>> >>>>>> Chiming in to say that we discussed the security concerns around this >>>>>> proposal quite extensively internally and overall we believe that with >>>>>> the >>>>>> short timeout, the security risks are acceptable. The residual security >>>>>> risk is for servers that implement purely server-side logouts and is >>>>>> only >>>>>> exploitable for a very short period of time (3 minutes). In addition, >>>>>> other >>>>>> mitigations like this one >>>>>> <https://bugs.chromium.org/p/chromium/issues/detail?id=1468438> further >>>>>> reduce the risk such that we believe it is unlikely that this will lead >>>>>> to >>>>>> new security issues. >>>>>> >>>>>> On Friday, October 13, 2023 at 7:14:46 AM UTC-7 vmp...@chromium.org >>>>>> wrote: >>>>>> >>>>>> On Fri, Oct 13, 2023 at 12:00 AM 'Fergal Daly' via blink-dev < >>>>>> blin...@chromium.org> wrote: >>>>>> >>>>>> On Thu, 12 Oct 2023 at 23:05, Yoav Weiss <yoav...@chromium.org> >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Oct 12, 2023 at 3:56 PM Vladimir Levin <vmp...@chromium.org> >>>>>> wrote: >>>>>> >>>>>> Are there any spec changes planned for this feature? I'm not sure if >>>>>> the README linked under Specification is meant to make it into WHATWG, >>>>>> maybe to close out https://github.com/whatwg/html/issues/7189 >>>>>> >>>>>> The only spec I could find about CCNS is >>>>>> https://www.rfc-editor.org/rfc/rfc9111#section-5.2.1.5, so I'm not >>>>>> sure how to reconcile possibly contradicting language in the specs >>>>>> >>>>>> >>>>>> Great questions! Fergal - can you answer that? >>>>>> >>>>>> >>>>>> RFC9111 is about HTTP caches. BFCache is not a HTTP cache, so RFC >>>>>> 9111 does not apply. Of course the reality of implementations and >>>>>> expectations vs spec is a problem. Some more discussion here >>>>>> <https://github.com/fergald/explainer-bfcache-ccns/blob/main/README.md#current-interactions-between-bfcache-and-ccns> >>>>>> >>>>>> >>>>>> I'm not sure I agree with this, or the reasoning in the link. First >>>>>> of all, this intent thread is about ignoring CCNS in _some cases_. In >>>>>> other >>>>>> cases, CCNS is respected, so it seems like BFCache is de facto subject >>>>>> to >>>>>> RFC 9111. >>>>>> >>>>>> This is, I guess, a bit philosophical but the spec says: >>>>>> the cache MUST NOT intentionally store the information in >>>>>> non-volatile storage and MUST make a best-effort attempt to remove the >>>>>> information from volatile storage as promptly as possible after >>>>>> forwarding >>>>>> it. >>>>>> >>>>>> Note that the spec here does not make any exceptions for things like >>>>>> cookie state not changing or anything else. The document when frozen is >>>>>> indeed a volatile storage of the server response, processed and stored >>>>>> in >>>>>> some particular format (ie the DOM tree). I admit it's a bit weird to >>>>>> think >>>>>> about it this way, since the live document is technically also this >>>>>> cache. >>>>>> Whereas I agree that BFCache is not strictly an HTTP Cache, I don't >>>>>> quite >>>>>> follow why CCNS should not apply to the BFCache in some cases. >>>>>> >>>>>> To me, BFCache seems like "a better http cache" which already has >>>>>> rendered results, not a completely separate cache that is not subject to >>>>>> CCNS. >>>>>> >>>>>> But I'm late to the game, and I see that the topic of "BFCache is not >>>>>> HTTP Cache" has already been discussed a lot. I'm not convinced by >>>>>> existing >>>>>> arguments, but I also don't think I'll be able to convince anyone of my >>>>>> position. >>>>>> >>>>>> My problem with the consensus in >>>>>> https://github.com/whatwg/html/issues/5744 is the following. People >>>>>> seem to agree that we don't want a *new* api that specifically prevents >>>>>> pages from entering BFCache. I don't believe it's appropriate to draw a >>>>>> conclusion that there is consensus that BFCache should not be subject to >>>>>> any *existing* APIs that prevent pages from entering it. This might be >>>>>> true >>>>>> independently, but I don't think one follows from the other. To quote >>>>>> this >>>>>> comment >>>>>> <https://github.com/whatwg/html/issues/5744#issuecomment-811958634>: >>>>>> "... And what is the problem with the bank case? I'd expect bank may >>>>>> want to ensure its page doesn't enter bfcache, or any other cache, by >>>>>> using >>>>>> no-store (and other) header(s) or something ..." >>>>>> >>>>>> That comment sounds to me like "the status quo is good enough, >>>>>> because there are already ways of preventing any cache, including >>>>>> bfcache." >>>>>> If we were to claim consensus on doing this work, I'd personally want to >>>>>> see a more explicit "let's make it so pages still enter BFCache despite >>>>>> CCNS in these cases." The comment from cdumez you quoted is good, but >>>>>> maybe >>>>>> following-up there is worthwhile. >>>>>> >>>>>> >>>>>> I concede though that I'm by no means an expert here, so I don't want >>>>>> to block moving this forward any longer. I just want to say that it's >>>>>> typically easy to be fast if you show stale data, and shifting the blame >>>>>> to >>>>>> the site for using CCNS instead of refreshing needed content in script >>>>>> doesn't seem appropriate. I personally would not want to be the judge of >>>>>> whether CCNS use is appropriate or not since I don't know what >>>>>> "appropriate" is in this case. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> BFCache and cases where it can/can't be used are specced in the HTML >>>>>> standard. We have had very little engagement from other vendors on this >>>>>> particular idea but Safari tried to cache all CCNS pages in the past. I >>>>>> am >>>>>> hoping that if we demonstrate a way to cache some of them safely, they >>>>>> would be on board. Also any browser is free to be *more* conservative >>>>>> than >>>>>> the spec while still staying in-spec as BFCaching at all is always >>>>>> optional. >>>>>> >>>>>> Here >>>>>> <https://github.com/whatwg/html/issues/5744#issuecomment-661997090> >>>>>> is cdumez of Safari >>>>>> >>>>>> Safari / WebKit shipped with all pages going into the bfcache no >>>>>> matter what (including cache-control: no-store). The only push back >>>>>> we received was the fact that after you log out of a site, you could >>>>>> still >>>>>> go back and see a page you should no longer be able to see. We agreed >>>>>> that >>>>>> this feedback was valid and our short-term fix was to bypass the bfcache >>>>>> when the page uses cache-control: no-store. Sadly, many sites use >>>>>> this and their intention is likely not to prevent the bfcache. This is >>>>>> not >>>>>> something we like for the long term. >>>>>> >>>>>> F >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Also, Vlad previously asked about the recommended pattern for folks >>>>>> to handle credential revocation with BFCache and his concerns with the >>>>>> snippet suggested upthread. It'd be great to address that. >>>>>> >>>>>> >>>>>> Thanks! >>>>>> vmpstr >>>>>> >>>>>> On Thu, Oct 12, 2023 at 2:32 AM Yoav Weiss <yoav...@chromium.org> >>>>>> wrote: >>>>>> >>>>>> I just discussed this with Fergal offline: >>>>>> >>>>>> - The risky scenario is one where revocation of sensitive info >>>>>> (logout, access revoked) happens on the server-side only without a >>>>>> client-side update. >>>>>> - In such a scenario on a shared computer, someone could >>>>>> back-button their way into someone else's sensitive info. >>>>>> - It might be interesting to talk to security folks (and maybe >>>>>> Project Zero folks) to see if this is not happening already with >>>>>> content >>>>>> that's not CCNS decorated. >>>>>> - It would be good to run a survey of >>>>>> potentially-sensitive services and try to get a signal from them on >>>>>> how >>>>>> many of them are properly doing revocation on the client side. >>>>>> - I'd love ideas on how we can scale such a survey beyond >>>>>> manual inspection of a few known services. >>>>>> - It could be interesting to try and ship a version of this with >>>>>> a shorter timeout, to minimize the risk of users leaving the machine >>>>>> unattended. >>>>>> - If we go that route, it'd be good to think through how we'd >>>>>> be able to increase that timeout over time, after gaining more >>>>>> confidence >>>>>> that the risky scenario isn't happening in the wild. >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Oct 5, 2023 at 2:36 AM Jason Robbins <jrob...@google.com> >>>>>> wrote: >>>>>> >>>>>> At this morning's API Owners meeting, they asked me to add all review >>>>>> gate types to all of the "web developer facing code change" features >>>>>> that >>>>>> are currently under review, including this one. So, I have added >>>>>> Privacy, >>>>>> Security, Enterprise, Debuggability, and Testing gates to your feature >>>>>> entry. >>>>>> >>>>>> Please click the gate chips in the "Prepare to ship" stage on your >>>>>> feature detail page. For each one, answer survey questions and request >>>>>> that of the cross-functional review. You can request them all in >>>>>> parallel. In cases where you already have the go/launch >>>>>> <https://goto.google.com/launch> bit approved, you can note that in >>>>>> a comment on that gate for a potentially faster review. >>>>>> >>>>>> Thanks, >>>>>> jason! >>>>>> On Monday, October 2, 2023 at 9:09:18 AM UTC-7 Jason Robbins wrote: >>>>>> >>>>>> On Friday, September 29, 2023 at 1:01:54 PM UTC-7 Chris Harrelson >>>>>> wrote: >>>>>> >>>>>> Please also make sure to complete all of the other shipping gate >>>>>> reviews >>>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/bqvB1oap0Yc/m/YlO8DEHgAQAJ> >>>>>> . >>>>>> >>>>>> >>>>>> I think a bug in ChromeStatus may have caused some confusion on this >>>>>> feature entry. The feature entry has type "Web developer facing code >>>>>> change", so its bilnk-dev thread should have had subject line prefix >>>>>> "Web-facing change PSA" rather than "Intent to ship". And, according to >>>>>> the launching-features doc >>>>>> <https://www.chromium.org/blink/launching-features/#psa-prepare-to-ship>, >>>>>> >>>>>> it does not require any approvals, which is why there are no other gates >>>>>> offered in the ChromeStatus UI. A fix for that subject-line prefix bug >>>>>> should go live today. >>>>>> >>>>>> Of course, the point of a PSA is to allow concerns to be raised and I >>>>>> see that this is a very active thread. So, all that should be worked >>>>>> through. Its a mater of the the API Owners prerogative to request any >>>>>> other reviews that they think are appropriate, but it is not >>>>>> automatically >>>>>> required by the process for this feature type. Also, I see that the >>>>>> launch >>>>>> entry <https://launch.corp.google.com/launch/4251651> had some >>>>>> approvals. >>>>>> >>>>>> Thanks, >>>>>> jason! >>>>>> >>>>>> -- >>>>>> 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+...@chromium.org. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUszpq%3DS%3DOZ4k_GnopJMRcTnL_trq5iF8J-kAzeYEiqKA%40mail.gmail.com >>>>>> >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUszpq%3DS%3DOZ4k_GnopJMRcTnL_trq5iF8J-kAzeYEiqKA%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+...@chromium.org. >>>>>> >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAozHLkA5eFwcvRsTAZhy728KFaBjd5W5EZpP2%3DMmC42ngMUuQ%40mail.gmail.com >>>>>> >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAozHLkA5eFwcvRsTAZhy728KFaBjd5W5EZpP2%3DMmC42ngMUuQ%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+...@chromium.org. >>> To view this discussion on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXz6RHMEbN4uVKw9pcS7nNyZT-zoQAwf1iSoS6THqAcfw%40mail.gmail.com >>> >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXz6RHMEbN4uVKw9pcS7nNyZT-zoQAwf1iSoS6THqAcfw%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/a7147e19-c2c4-45e4-9b97-9c426e2fd465n%40chromium.org.
