Thank you for the update! This is a good write up. One comment / question below
>From the doc: > Note that the pageshow event will trigger before the page is rendered for the first time upon being restored from a back/forward navigation, which guarantees that your login state check will let you reset the page to a non sensitive state. Correct me if I'm wrong, but I think the viz surface displaying the persisted contents may be embedded and shown before the page produces a new frame. So although technically it is correct that this event will fire before the page produces a rendering and a new frame, a version of the content may be shown prior to that. I'm not sure if I'm being overly pedantic here, or whether my understanding of this flow is incorrect. Thanks again for the write up Vlad On Tue, Dec 5, 2023, 19:37 'Fergal Daly' via blink-dev < blink-dev@chromium.org> wrote: > We now have a published doc > <https://web.dev/articles/sign-out-best-practices> that covers best > practices for BFCache/CCNS (and much more) during logout. Please let us > know if you have any feedback on it. > > We will proceed with cautiously rolling out this change. Thanks everyone, > > F > > On Thu, 16 Nov 2023 at 13:37, Fergal Daly <fer...@google.com> 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 <yoavwe...@chromium.org> >>> wrote: >>> >>>> LGTM3 with the same condition. >>>> >>>> On Wed, Nov 15, 2023 at 6:44 PM Mike Taylor <miketa...@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 <yoavwe...@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 <ddwor...@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+unsubscr...@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/CAAozHLmtJkE1f6GRF3f5NGvYSp%3DZvgU9H2oGxRza9jpeYbr_pQ%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAozHLmtJkE1f6GRF3f5NGvYSp%3DZvgU9H2oGxRza9jpeYbr_pQ%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/CADsXd2NiHoYAkDCGjrxV0jAmCcMyw5W_-r%3DprrC3Daz_i%2BPW_w%40mail.gmail.com.
