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/71e91468-54a3-413f-ad4c-be0f18f68e63n%40chromium.org.
