Hi Thomas, I'm part of the team working on Early Hints.
On Wed, Mar 16, 2022 at 6:58 AM BIANCONI Thomas <thomas.bianc...@loreal.com> wrote: > I am sad to read this... > A new step before the deprecation of server push. > > I would love to see comparaison in term of performance between server push > and early hint. > On a pure theoric point of view early hint starts during the html parsing > whereas the server push start with the response header. So server push by > design is better. > If I understand correctly, I believe that there is some misunderstanding about Early Hints. Clearly, it's on us to make this easier to understand. Sorry... We'll put extra efforts in providing clear & detailed developer documentation when Early Hints ships. In the meantime, here is a high level summary of what Early Hints is, and how it works: 1. Early Hints is a status code (103) which is used in HTTP responses while the server is preparing the final response. This intermediate response can include other HTTP headers, in particular LINK REL headers such as preload or preconnect. 2. In some cases, it can take time for the server to prepare the main response: accessing the DB, having an edge cache go talk to the origin server, etc. So, the idea is to speed up overall page load times by giving the browser hints about what it might do while waiting for the actual response. Typically, the hints are about critical sub-resources or origins which would be used by the final response. 3. The browser processes these hints, and decides to preconnect or preload any missing origins/resources while waiting for the final 200 OK response (usually containing the main resource). Since the browser got some work done ahead of time, the overall page load time is improved. In other words, the key point here is that Early Hints doesn't start during the HTML parsing: it starts with the non-final response headers, way before HTML parsing kicks in since that is blocked on the final response. See this section of the RFC <https://datatracker.ietf.org/doc/html/rfc8297#:~:text=The%20following%20example%20illustrates%20a%20typical%20message%20exchange%20that%0A%20%20%20involves%20a%20103%20(Early%20Hints)%20response.> for an example of how this looks at the HTTP level. > Regarding the complexity to put it in place early hints is easy when you > serve different page but for Single Page Application the build process > don't generate differentiate serving based on the route since the routing > of the application is generally managed in the frontend. > So for Single Page Application to managed server push not global to all > route it will more complexe to include it in the build process. > The MPA angle is indeed easier, deployment wise. We'll look into the SPA case in more details including discussion with various framework authors. I hope this was useful. > > Just wanted to share my feeling about this whole topic. > > > > Thanks > > > > Regards > > > > *Thomas BIANCONI* > > Head of Data Technologies > > & Data Privacy Champion > > Global CDMO Team > > 41 Rue Martre - 92110 Clichy > > *Mob* : +33 (0) 6 15 35 33 57 <+33%206%2015%2035%2033%2057> > > *Ph* : +33 (0) 1 47 56 45 95 <+33%201%2047%2056%2045%2095> > > *E-mail* : thomas.bianc...@loreal.com > > ------------------------------ > *De :* Chris Harrelson <chris...@chromium.org> > *Envoyé :* mercredi 2 mars 2022 18:51 > *À :* Daisuke Enomoto <denom...@chromium.org> > *Cc :* blink-dev <blink-dev@chromium.org>; las...@chromium.org < > las...@chromium.org>; pme...@chromium.org <pmee...@chromium.org>; > Francesco Montanari <francesco.montan...@outlook.com>; Maxim Makarov < > maxpain...@gmail.com>; b...@chromium.org <b...@chromium.org>; > dsch...@chromium.org <dschin...@chromium.org>; ians...@chromium.org < > iansw...@chromium.org>; rektide <rekt...@gmail.com>; Ben Lesh < > b...@benlesh.com>; Andrew Wilder <and...@andrewwilder.com>; Vito De Giosa < > vito.degi...@gmail.com> > *Objet :* Re: [blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server > push > > Notice: External mail > The API owners met today and discussed this intent at some length. > > We are very happy that Early Hints is showing very positive promise in > terms of experimental data, and feel the positive experimental data is > enough to justify starting the process to remove HTTP/2 push. > > To that end, we approve starting official deprecation of the feature now, > with a (publicly communicated) goal to remove support from Chromium in the > next 6-9 months. We recommend publishing a blog post describing what's > happening and the recommended migration paths. > > However, we would like to see an Early Hints intent-to-ship before > approving actual removal of HTTP/2 Push; please do not consider this an > email an approval to actually remove it until we send LGTMs for such. Our > understanding is that Early Hints is well on the way to a finished spec and > readiness to ship, and the remaining pieces of the specification are to > nail down integration with other related APIs such as Fetch. We think this > sounds feasible to complete and reach a shipped-in-stable-channel status > within the proposed deprecation period, which would allow sites to > potentially have a seamless transition. > > We recognize that this is a long time period, and especially long given > the time since the start of the request to deprecate. The reason is that > we'd really like to avoid the "old thing is deprecated, new thing is not > yet available" situation if possible. Thank you everyone for your patience > and efforts. > > Regards, > Chris > > > On Wed, Mar 2, 2022 at 1:47 AM Daisuke Enomoto <denom...@chromium.org> > wrote: > > Hello, > > We conducted an experiment for Early Hints (chromestatus > <https://urldefense.com/v3/__https://chromestatus.com/feature/5207422375297024__;!!IY5JXqZAIQ!tuPS5CAhthikdjYO2ritj17L4LiN-pYSY7buCcpWke1SVokLk44YNKR45xzrzNtkXfmC$>) > with partners in Q3 - Q4, 2021. The experiment data suggests that the > performance impact is highly positive. Based on these insights, we are > confident that Early Hints will be a viable alternative to H/2 Push for > performance use cases. In addition, by design Early Hints will not run into > the overpushing concerns that bogged down H/2 Push. We are working with > some of our partners to share a bit more details. > > Next steps (for Early Hints) > > We are actively working on finalizing the shipping plan / timeline. In > particular, Early Hints requires updating multiple specs. Once our plan > becomes clearer, the details will be shared on a new Intent to Ship thread. > > Non performance use cases > For other perceived use cases beyond performance improvements, we > recommend sharing more details over at WICG Discourse > <https://urldefense.com/v3/__https://discourse.wicg.io/__;!!IY5JXqZAIQ!tuPS5CAhthikdjYO2ritj17L4LiN-pYSY7buCcpWke1SVokLk44YNKR45xzrzG_bdCve$> > with a focus on the problem you are trying to solve rather than how H/2 > Push could be used. In addition, if you currently rely on H/2 Push in ways > that Early Hints can’t address, please share details > <https://urldefense.com/v3/__https://discourse.wicg.io/__;!!IY5JXqZAIQ!tuPS5CAhthikdjYO2ritj17L4LiN-pYSY7buCcpWke1SVokLk44YNKR45xzrzG_bdCve$> > about how critical this is to your product/service, on top of your use case. > > Thanks > Daisuke > > On Sun, Feb 20, 2022 at 6:40 PM Morgaine <rekt...@gmail.com> wrote: > > I'm not sure if you are being deliberately cruel & malicious, or just > accidentally cruel. Web developers have been begging for Fetch to please > for the love of everything holy please report HTTP PUSH responses for 3/4 > of a decade now, so we might implement Webpush Protocol or other similar > reactive techniques via using Push. There have been a couple explorations > of this, but after a series of proposals, nothing has materialized, nothing > has developed. Rather than ever making PUSH useful, rather than acknowledge > that PUSH could implement a reactive, Webpush Protocl like system, you seem > intent on using negligence to destroy the baby before it has a chance. This > has been requested & begged for, there's been a couple spins, but you seem > ready to destroy possibility in this deprecation, before even having made > the most minimum bid to make the technology useful. Please, heed > https://github.com/whatwg/fetch/issues/51 > <https://urldefense.com/v3/__https://github.com/whatwg/fetch/issues/51__;!!IY5JXqZAIQ!tuPS5CAhthikdjYO2ritj17L4LiN-pYSY7buCcpWke1SVokLk44YNKR45xzrzGDYL5uJ$> > & try to do some little bit of good in the world, before you go running off > macabely destroying possibility. > > Chrome had a number of attempts where some good responsible smart > actually-know-something developers saw that PUSH could be useful, and > proposed trying to make Fetch spec be useful, proposed making PUSH useful. > That the current crop of developers doesn't understand & see this > possibility, either denies or is ignorant to the sad long history of > begging, pretty please, to let us observe & react to PUSH requests, is a > tragedy. We are headed for using HTTP3-over-WebTransport, because ya'll are > sending in the wrecking ball, rather than following up & doing the bear > minimum, most essential, most basic spec-authoring work on Fetch, that was > begged for, pleaded for, for 3/4 of a decade now. This is such a sad sad > route, and it's going to be such a gross boondogle working around the > apathy browser developers gave for PUSH, their unlove, their incapability > to provide even some simple basic capabilities to use PUSH. > https://github.com/whatwg/fetch/issues/51 > <https://urldefense.com/v3/__https://github.com/whatwg/fetch/issues/51__;!!IY5JXqZAIQ!tuPS5CAhthikdjYO2ritj17L4LiN-pYSY7buCcpWke1SVokLk44YNKR45xzrzGDYL5uJ$> > needed some love. It still does. Turn the ship around. Do the minimum > viable feature, before you decide to axe it. You might even be able to not > put the PUSH into cache, if that makes you happy, so long as you provide an > alternative means to receive the PUSH responses to a Fetch. Doing nothing, > permitting nothing: that's such a misdeed. Please, again, don't do this. > And don't tell us something that is deeply related, that is at the heart of > this disaster, that has gone unaddressed & unimprove for so long, is > unrelated. > On Wednesday, June 30, 2021 at 9:42:26 AM UTC-4 las...@chromium.org wrote: > > No, the Push API ( > https://developer.mozilla.org/en-US/docs/Web/API/Push_API > <https://urldefense.com/v3/__https://developer.mozilla.org/en-US/docs/Web/API/Push_API__;!!IY5JXqZAIQ!tuPS5CAhthikdjYO2ritj17L4LiN-pYSY7buCcpWke1SVokLk44YNKR45xzrzHd5HvEU$>) > is entirely unrelated other than the name. > > -Brad > > On Wed, Jun 30, 2021, 9:00 AM Vito De Giosa <vito.d...@gmail.com> wrote: > > Does it mean that also that the webpush protocol, Push Api won't work > anymore? > > > > On Monday, 28 June 2021 at 17:15:54 UTC+2 pme...@chromium.org wrote: > > It feels like there are a lot of different things going on here and it > might be useful to unpack it a bit. > > Web Vitals thresholds - they aren't a hard line where you pass or you > don't. The last updates from the team explained that each metric is looked > at independently and there is a progressive boost in the "needs > improvement" zone based on how close a given URL is to the "good" > threshold. That doesn't really help if you're being held to the "number of > URLs that need improvement" in the search console but there is not much > practical difference between a 2.6 and a 2.5 LCP (not like the cliff that > it initially sounded like it would be). > > Layout Shifts from late-loading fonts - Using PUSH to try to fix this race > condition feels like the wrong tool for the job. Even with font-display: > block it is possible that a text element won't be sized correctly until the > font loads, causing something after it in the DOM to be moved. Preload can > help get the font loaded sooner so it will be there at layout time more > often but it will still be racy. PUSH is also still racy but makes it even > more likely that the font will be there early but at the cost of delaying > literally everything else (including the HTML in a lot of cases). It feels > like we need a better primitive to tell the browser to block layout until > the text sizes are known (if that is something a site wants to do) so that > things can still load asynchronously but the rendering can be controlled. > It's a lot like CSS blocking layout/render - otherwise unstyled content is > flashed for FOUC. font-display: block prevents the render of text in the > wrong font but nothing lets you block incorrect layout (that I know of). > Fixing that properly rather than wedging fonts ahead of everything else is > a better fix. > > Push sounds like a great solution, particularly when it can be done > intelligently to not push resources already in cache and if it can exactly > only fill the wait time while a CDN edge goes back to an origin for the > HTML but getting those conditions right in practice is extremely rare. In > virtually every case I have seen, the pushed resources end up delaying the > HTML itself, the CSS and other render-blocking resources. Delaying the HTML > is particularly bad because it delays the browser's discovery of all of the > other resources on the page. Preload works with the normal document > parsing and resource discovery, letting preloaded resources intermix with > other important resources and giving the dev, browsers and origins more > control over prioritization. > > On Friday, June 25, 2021 at 7:32:05 PM UTC-4 Brad Lassey wrote: > > On Fri, Jun 25, 2021, 6:58 PM Andrew Wilder <and...@andrewwilder.com> > wrote: > > Interesting, thanks Brad. > > I'd imagine that the performance benefit is actually greater for sites > that don't use a CDN at all, since one RT is likely to take much longer > > Due to initial window sizes, one RT worth of data is measured in bytes, > not time and does not vary based on round trip times. > > ... so if you're only looking at CDNs, that might explain part of the > difference? > > > We looked at all sites that were using Push, but in addition cut the data > by CDN to look for correlations. > > > With the extremely tight requirements of Core Web Vitals, one round-trip's > time potentially *could* make a significant difference in some cases. > I was recently working on a site where I just couldn't get the Largest > Contentful Paint metric to pass the 75th percentile of 2.5s in CRuX. I was > stuck, soooo close, at 2.6s. (And it was testing great in Lab Data...just > not in the field data, frustratingly) > > I'd suggest you look at how big your initial resources are and what's left > over after the initial window. Again, the reference to a round trip is to > the amount of data, not time. > > > A roundtrip can take well over 100ms, so that alone could be enough to > shave off 0.1s under the right conditions, or maybe more, to get the site > to pass CWV. But I also stopped short of actually bothering to implement > and test this when I saw this thread (I wasn't even sure if Chrome was > still working for Server Push or not -- though I see that was answered a > few messages back.) > > I don't think I would have argued this point before core web vitals, since > one round-trip does seem nearly negligible -- but because now we have > *absolute* metrics we need to hit, which are pretty tough in some cases, > I think keeping this one additional tool in the toolbelt may be > worthwhile... > > Thanks again, > Andrew > > > > On Fri, Jun 25, 2021 at 3:28 PM Brad Lassey <las...@chromium.org> wrote: > > On Fri, Jun 25, 2021, 4:53 PM Andrew Wilder <and...@andrewwilder.com> > wrote: > > Brad, thanks for the clarification. We're definitely utilizing preload -- > that's pretty much "table stakes" for passing Core Web Vitals at this > point. We're also utilizing many other tools, including Critical Path CSS > and delaying JavaScript until after user interaction. Those are far more > complicated to implement properly than Server Push (especially with > Cloudflare's excellent implementation, as Francesco pointed out). > > The new Page Experience requirements from Google have changed the game > when it comes to site speed. Previously, speed was known to be a ranking > factor, but the details were secret, and it was more of a "relative" factor > compared to the competition. "Just be faster than your competition" was > sufficient before. > > But with Core Web Vitals, the requirements are now absolute criteria, and > it's pass/fail regardless of other sites in your vertical. There's no gray > area here -- and for many sites, passing all three CWV criteria, while > keeping the features that site owners need, is quite challenging. > > Furthermore, you mentioned "this depreciation represents a low risk of web > breakage." But keeping Server Push is not detrimental - it has *zero > risk* of web breakage. So why remove support for it? > > So it seems we have one department of Google (Search) pushing for a faster > web, and another Department (Chrome) considering taking away a tool that, > with proper implementation, should actually help achieve that goal. > > Having said that, the truly important question that we're kind of dancing > around is:* Is Server Push actually beneficial? * > > If the answer to that is "yes," then I think it's better for Chrome to > keep supporting it -- and, instead of killing it, to make efforts to > increase adoption. > > But if you're able to demonstrate that, when properly implemented, it has > no *actual *speed/CWV benefits compared to using <preload> links in the > <head>, I'll be grateful because it means I don't have to spend time > finding that out on my own. :) > > Our data shows that it is not providing a speed benefit in practice and in > fact is an overall slight performance regression for Chrome users. > > As far as differentiating "proper" use versus naive use, I cut the data by > which CDN hosted each domain and didn't see any one CDN with a net > performance benefit, which I interpret as not indicating that there is > necessarily a proper vs improper way to use the feature. This intuitively > makes sense as the theoretical potential benefit over preload is > vanishingly small (1 RT worth of data minus your initial resource) and > depending on the situation very possibly nil, versus the relatively high > penalty of pushing the wrong thing. > > > Thanks again, > Andrew > > > On Fri, Jun 25, 2021 at 1:25 PM Francesco Montanari < > francesco...@outlook.com> wrote: > > It's not necessarily complex to implement for the developer. > For example, Cloudflare gives it by default, you just need to add the HTTP > preload header ( > https://www.cloudflare.com/it-it/website-optimization/http2/serverpush/ > <https://urldefense.com/v3/__https://www.cloudflare.com/it-it/website-optimization/http2/serverpush/__;!!IY5JXqZAIQ!tuPS5CAhthikdjYO2ritj17L4LiN-pYSY7buCcpWke1SVokLk44YNKR45xzrzN4sNSwd$> > ) > and they have a smart implementation of it, they push assets only at the > first visit, they don't push them again when they know the browser should > have it already in its cache. > > They also were the first to offer SSL for free to everyone in 2014, and > today nobody would pay for a SSL cert. So good things take time to > spread... > > It's just a matter of time, when the WordPress themes start adding the > preload HTTP header for their resources (it's a one-liner in PHP), all the > wordpress sites which are on cloudflare will automatically have HTTP push > with zero configuration, and the usage stats will rise as well. > > > > > On Friday, 25 June 2021 at 22:58:41 UTC+3 las...@chromium.org wrote: > > Hi Andrew, > I just want to clarify one point, we are proposing to depreciate and > remove HTTP Push because it has not proven to provide performance benefits > over other, less complex and technically burdensome techniques such as > preload (which I would encourage you to look at if you haven't already). > The discussion of the amount of usage of Push is largely making the case > that this depreciation represents a low risk of web breakage. > > Thanks, > Brad > > On Fri, Jun 25, 2021, 1:08 PM Andrew Wilder <and...@andrewwilder.com> > wrote: > > Sorry, I meant to say that Origin Summary CLS is just over 0.10, and/or > LCP is 2.6s or 2.7s. Just wanted to clear that up so you don't think I > don't know what I'm talking about! 😉 > > On Friday, June 25, 2021 at 10:02:13 AM UTC-7 Andrew Wilder wrote: > > I run an agency that supports and maintains over 500 WordPress sites -- > and we do a lot of site speed optimization work. Most of them are food > blogs, and because of their complexity, it's very difficult to get them to > pass the three Core Web Vitals requirements (especially LCP and CLS). > > I've been experimenting with Server Push as a way to get assets loaded > faster -- especially web fonts, which are often a source of shifts, as they > switch from the default fallback font to the web font. Often we run into > situations where the Origin Summary CLS is 2.6 or 2.7 seconds. Being able > to get fonts loaded earlier may help prevent shifts as they load; or to > shave off even 0.1 second for the LCP element (especially if it's an image) > may be enough to get the site to pass CWV completely. > > On some sites we exhausted other ways to speed things up to pass CWV, and > it was starting to look like Server Push might be able to get us across the > finish line. But I paused on getting further into development on this, > because I found this thread! Unfortunately, you're now creating a > self-fulfilling prophecy of killing off Server Push. By announcing that > you're considering removing it -- primarily because not enough people use > it -- you're discouraging further people to start using it! Oh, the irony. > > Considering Google's push on site speed and Core Web Vitals, it seems > quite contradictory for you to disable Server Push. Instead, it would be > far better to invest more resources into helping people utilize it -- and > making it more effective to help improve speed and user experience. > > On Friday, June 25, 2021 at 8:45:09 AM UTC-7 Maxim Makarov wrote: > > Please don't remove HTTP/2 Server Push support > > On Monday, June 21, 2021 at 5:32:25 PM UTC+3 b...@chromium.org wrote: > > Hi Francesco, > > Responding to the first part of your email only: no, HTTP/2 push is > currently not disabled by default or removed from Chrome. However, there > is a 1% holdback experiment running on Stable channel to allow monitoring > of *hypothetical* performance benefits. If push does not work for you, > your browser session might have been randomly assigned to the experiment. > In that case, restarting Chrome will fix it (with 99% probability). > > Cheers, > > Bence > > On Sat, Jun 19, 2021 at 3:58 PM Francesco Montanari < > francesco...@outlook.com> wrote: > > Is it already removed? I've implemented it but it doesn't seem to work in > Chrome. > > Anyway, please don't kill it. > Now that Google Search is deploying the "web vitals" update, which makes > the loading speed a key factor for ranking, more and more developers are > working to improve the sites speed, and pushing key assets would be very > helpful. > > On Monday, 7 June 2021 at 23:25:02 UTC+3 rektide wrote: > > On Wed, Dec 30, 2020 at 2:11 PM Brad Lassey <las...@chromium.org> wrote: > > On Wed, Dec 23, 2020 at 10:25 PM Morgaine <rek...@gmail.com> wrote: > > As I stated in the very first reply to this thread, it is a horrific > tragedy that the situation is like this. It's been HALF A DECADE OF > IGNORING DEVELOPERS on https://github.com/whatwg/fetch/issues/65 > <https://urldefense.com/v3/__https://github.com/whatwg/fetch/issues/65__;!!IY5JXqZAIQ!tuPS5CAhthikdjYO2ritj17L4LiN-pYSY7buCcpWke1SVokLk44YNKR45xzrzEiQWO2T$> > and https://github.com/whatwg/fetch/issues/607 > <https://urldefense.com/v3/__https://github.com/whatwg/fetch/issues/607__;!!IY5JXqZAIQ!tuPS5CAhthikdjYO2ritj17L4LiN-pYSY7buCcpWke1SVokLk44YNKR45xzrzFbdSMTO$> > , who have begged for fetch to support push, have BEGGED, & gotten no > where. To say that the fetch spec does not mention push is to spit in our > faces. This is farce & tragedy. Perhaps it's only ignorance you speak from, > but I can not be more hurt to hear you say this. I have repeated time & > time again in countless threads the desires for fetch to PLEASE FOR THE > LOVE OF GOD support fetch. It's insulting that there has been zero progress. > > > > I am sorry that my words had this effect on you. I believe the use cases > that you've articulated are being addressed with WebTransport ( > https://github.com/w3c/webtransport/ > <https://urldefense.com/v3/__https://github.com/w3c/webtransport/__;!!IY5JXqZAIQ!tuPS5CAhthikdjYO2ritj17L4LiN-pYSY7buCcpWke1SVokLk44YNKR45xzrzAN4tjvn$>). > If you don't believe so, can you file issues there to make sure they are > properly considered? > > > It seems farcical to me that we are going to need to run HTTP3 over > WebTransport to get a usable implementation of Push. > > The browser should be good at HTTP. We should have these capabilities. > Deciding to make everyone invent and bring their own userland WebTransport > stack to be able to tell that an HTTP resource was pushed is a huge waste > of bandwidth to send that userland stack, & a colossal mass of complexity > to do the tunneling, & generates a far far more complex networking > situation than if the browser would implement the one optional part of > HTTP. Where-as before an a service might have run on HTTP3, pushed a > resource, & seen it arrive, the service must host an WebTransport tunnel > that carries HTTP3 inside of it. Now we have to worry about X-Forwarded-For > like concerns. > > WebPush Protocol already takes advantage of these capabilities, for > example, to create a simple to implement, elegant notification service, > used by all browsers: but without the Fetch standards I linked, it is > unusable for such obvious cause. Without Push, we grow complex systems like > grpc-web, which are partial, incomplete, radically complex alternatives to > what the browser ought just be able to do, what only the most minor, long > requested additions to Push would have allowed. > > And now here we are, building Early Hints to try to reclaim only the most > minor, smallest of advantages Push gave us. Focused only on this one tiny > bit of the puzzle. And told that we must DIY alternatives if we want them, > using WebTransport, and told that this web browser will not support the one > optional component of the HTTP standard. > > Words have not had an effect on me. This decision continues to have a > profound & disturbing effect on me, and it should be reversed. Hopefully > before we need to start implementing HTTP3 over WebTransport, but I rather > suspect not. > > -- > 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/06cb378d-e243-4200-9af5-5eb2868388bcn%40chromium.org > <https://urldefense.com/v3/__https://groups.google.com/a/chromium.org/d/msgid/blink-dev/06cb378d-e243-4200-9af5-5eb2868388bcn*40chromium.org?utm_medium=email&utm_source=footer__;JQ!!IY5JXqZAIQ!tuPS5CAhthikdjYO2ritj17L4LiN-pYSY7buCcpWke1SVokLk44YNKR45xzrzLVyveu0$> > . > > -- > 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/CAA5e699N7CPOqRMT%2BpZ60evzZSUvn6jH00pVc%2BXObtK9GSk0Fw%40mail.gmail.com > <https://urldefense.com/v3/__https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA5e699N7CPOqRMT*2BpZ60evzZSUvn6jH00pVc*2BXObtK9GSk0Fw*40mail.gmail.com?utm_medium=email&utm_source=footer__;JSUl!!IY5JXqZAIQ!tuPS5CAhthikdjYO2ritj17L4LiN-pYSY7buCcpWke1SVokLk44YNKR45xzrzAh3D4lp$> > . > > -- > You received this message because you are subscribed to a topic in the > Google Groups "blink-dev" group. > To unsubscribe from this topic, visit > https://groups.google.com/a/chromium.org/d/topic/blink-dev/K3rYLvmQUBY/unsubscribe > <https://urldefense.com/v3/__https://groups.google.com/a/chromium.org/d/topic/blink-dev/K3rYLvmQUBY/unsubscribe__;!!IY5JXqZAIQ!tuPS5CAhthikdjYO2ritj17L4LiN-pYSY7buCcpWke1SVokLk44YNKR45xzrzMGsZ9qr$> > . > To unsubscribe from this group and all its topics, 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/CAOMQ%2Bw-rNUrRaBKE5YKZ8DFRvoO3L2e6ojgzKJyLp5MS4BQXqw%40mail.gmail.com > <https://urldefense.com/v3/__https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ*2Bw-rNUrRaBKE5YKZ8DFRvoO3L2e6ojgzKJyLp5MS4BQXqw*40mail.gmail.com?utm_medium=email&utm_source=footer__;JSU!!IY5JXqZAIQ!tuPS5CAhthikdjYO2ritj17L4LiN-pYSY7buCcpWke1SVokLk44YNKR45xzrzCZd8FK4$> > . > > This message and any attachments are confidential and intended solely for > the addressees. > If you receive this message in error, please delete it and immediately > notify the sender. If the reader of this message is not the intended > recipient, you are hereby notified that any unauthorized use, copying or > dissemination is prohibited. E-mails are susceptible to alteration. Neither > LOREAL nor any of its subsidiaries or affiliates shall be liable for the > message if altered, changed or falsified. > > C1 - Internal use > > -- > 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/PA4PR05MB90898054ACE52E707A43508D81109%40PA4PR05MB9089.eurprd05.prod.outlook.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/PA4PR05MB90898054ACE52E707A43508D81109%40PA4PR05MB9089.eurprd05.prod.outlook.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/CADWWn7WEBYWRR3EAu0-XHZ9DAce8ifhxtm11b7xPyLS_ghSrsA%40mail.gmail.com.
