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/CAAozHLkAKbm522YmNO%3DmGQ6BF%2BmXRDu89MCZPsFKpopfoFpFbw%40mail.gmail.com.
