We've also published this post with details and our rollout plans: https://developer.chrome.com/docs/web-platform/bfcache-ccns#how_chrome_is_changing_this_behavior
On Wed, 25 Sept 2024 at 06:25, 'Mingyu Lei' via blink-dev < blink-dev@chromium.org> wrote: > Hi Erwin, > > We have now decided to roll out the experiment to 10% by Oct 4. > > On Thu, Aug 1, 2024 at 9:31 AM Erwin Hofman <blue2bl...@gmail.com> wrote: > >> Just being curious here: Any updates regarding roll out percentage? >> >> Op woensdag 29 mei 2024 om 04:45:44 UTC+2 schreef Mingyu Lei: >> >>> Hi everyone, >>> >>> We want to share a quick update that the CCNS experiment has been rolled >>> out to 5% in stable. >>> >>> Thanks, >>> Mingyu >>> >>> On Wed, Feb 14, 2024 at 4:53 PM Mingyu Lei <le...@google.com> wrote: >>> >>>> Hi everyone, >>>> >>>> We have landed the change that will clear the fallback surface if a >>>> CCNS page is stored in BFCache, so the pixels from the CCNS page won't >>>> appear after navigating back. This change should resolve Vlad's concern >>>> mentioned in the most recent email. >>>> >>>> The experiment that would restore BFCached CCNS page is now started on >>>> dev channel, and we will gradually roll out to beta and stable. Thanks a >>>> lot for your reviews and suggestions. >>>> >>>> Mingyu >>>> >>>> On Thu, Dec 7, 2023 at 10:31 AM Fergal Daly <fer...@google.com> wrote: >>>> >>>>> >>>>> >>>>> On Thu, 7 Dec 2023 at 01:07, Vladimir Levin <vmp...@chromium.org> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Wed, Dec 6, 2023 at 1:16 AM 'Fergal Daly' via blink-dev < >>>>>> blin...@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. >>>>>> >>>>> >>>>> CCNS is not BFCached, so there is likely to be no special treatment of >>>>> CCNS. Let's figure this out on the bug. Thanks, >>>>> >>>>> F >>>>> >>>>> >>>>>> >>>>>> 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 < >>>>>>>>> blin...@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 < >>>>>>>>>>>> yoav...@chromium.org> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> LGTM3 with the same condition. >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Nov 15, 2023 at 6:44 PM Mike Taylor < >>>>>>>>>>>>> mike...@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 < >>>>>>>>>>>>>> yoav...@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 < >>>>>>>>>>>>>>> ddwo...@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+...@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+...@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+...@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 a topic in the > Google Groups "blink-dev" group. > To unsubscribe from this topic, visit > https://groups.google.com/a/chromium.org/d/topic/blink-dev/GuRqI7zXWMY/unsubscribe > . > To unsubscribe from this group and all its topics, 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/CAN_fHtm09bRqVsK9JrQiXwNDh5Fuw1GAV05ToAEbs3yZvfyLKA%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAN_fHtm09bRqVsK9JrQiXwNDh5Fuw1GAV05ToAEbs3yZvfyLKA%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/CAH6JyLRN6KZM9%3DU7-Aqs5_Ws9xKq8QPR3WXs9JPAxs2NYTyHVA%40mail.gmail.com.
