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 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/CAN_fHtm09bRqVsK9JrQiXwNDh5Fuw1GAV05ToAEbs3yZvfyLKA%40mail.gmail.com.
