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/CAAozHLmmb9hk8uHQAHV13otzF8dg8JkyGkQaeCLKod9EV%3DRmVw%40mail.gmail.com.
