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_fHt%3DebL_3JErHrhwgqj30j_AjG-OVdj3bA7Vk6hKu%3DihnhA%40mail.gmail.com.
