On Wed, Dec 6, 2023 at 1:16 AM 'Fergal Daly' via blink-dev < blink-dev@chromium.org> wrote:
> > > 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) > I see the old page being shown for 5 seconds in this case, which I think is the viz surface that can presumably expose sensitive information: https://youtu.be/Bld0EWWpQcQ I don't know if the treatment is different if we have CCNS. I've cc'ed some people on the bug that would know for sure. Thanks! - 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAozHLmTZFOEYcEUoai7WtG3TWJVwLY0J5Hxmu4kb7codQRDYQ%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/CADsXd2PF4r5Q%2BmGqYd-iohsgmJ7EHBTh_3e9%2BhPRB3JQh-NcHw%40mail.gmail.com.
