On Wed, 6 Dec 2023 at 13:55, Fergal Daly <fer...@google.com> wrote: > On Wed, 6 Dec 2023 at 12:29, Vladimir Levin <vmp...@chromium.org> wrote: > >> 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. >> > > I don't know if that's correct. I didn't think we kept any of the pixels > while in BFCache. If you are correct, that sounds like a bug. I've filed > https://crbug.com/1508728. Do you know who would know the answer to this? >
This is weird. Here's a test page https://fergald.github.io/random/bfcache/pixels/ When it's restored from BFCache it has a pageshow handlers that - pauses for 5s - flips the colour from red->blue or blue->red. What's weird is that going fwd/back on desktop: - the old BG-Colour is shown for 5s (but the page seems to be blank apart from that) - then the content appears and the colour changes on mobile: - the current page is shown for 5s - then the content appears and the colour changes I'm not sure which behaviour I would describe as correct. I guess it's best to keep showing the old content rather than flashing an empty page if pageshow is taking a long time. Either way, in both cases we do not see the old content but I think we should clean this up and also put in something to guard against a change where the old content is shown, F > > The same issue comes up in discussions of a back-preview (e.g. on mobile > when gesturing the go back, we could show a snapshot of the page) and the > intention there is to never do this with CCNS pages, > > F > > > >> >> 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/CAAozHLmTZFOEYcEUoai7WtG3TWJVwLY0J5Hxmu4kb7codQRDYQ%40mail.gmail.com.
