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