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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a2cbdcd2-c804-4bfb-9640-a0e0a1755696n%40chromium.org.
