Just an FYI, the blog post has been updated to give instructions on how to participate in the User-Agent Reduction Origin Trial as a third-party embed: https://developer.chrome.com/blog/user-agent-reduction-origin-trial/#how-to-participate-in-the-origin-trial-as-a-third-party-embed
On Tue, Sep 14, 2021 at 9:39 AM Ali Beyad <abe...@chromium.org> wrote: > A blog post just went out for this OT: > https://developer.chrome.com/blog/user-agent-reduction-origin-trial/ > > On Thu, Aug 12, 2021 at 9:47 AM Ali Beyad <abe...@chromium.org> wrote: > >> An update on this: it will be too rushed to get the User-Agent Reduction >> OT into the M94 branch cutoff (this Thursday), so we moved this OT for the >> M95 release. >> >> On Wed, Aug 11, 2021 at 4:02 PM Ali Beyad <abe...@chromium.org> wrote: >> >>> An update on this: it will be too rushed to get the User-Agent Reduction >>> OT into the M94 branch cutoff (this Thursday), so we moved this OT for the >>> M95 release. >>> >>> On Thu, Jul 15, 2021 at 6:39 PM Ali Beyad <abe...@chromium.org> wrote: >>> >>>> Thanks for the feedback and the LGTMs, everyone! >>>> >>>> On Thu, Jul 15, 2021 at 6:30 PM Rick Byers <rby...@chromium.org> wrote: >>>> >>>>> I agree this OT is quite different from a regular OT, there's not >>>>> really a "burn-in risk" to be worried about since this isn't really about >>>>> any new functionality sites want access to. So LGTM3 for a longer trial. >>>>> >>>>> If necessary I'd also be supportive of expanding usage limits >>>>> arbitrarily. The more usage we can get of this trial, the lower the compat >>>>> risk will be of making the breaking change later. So in this case it makes >>>>> no sense to worry about excessive usage of the OT. >>>>> >>>>> I'm glad to hear the inherited JS semantics will match that of the >>>>> header. Like for the header, I'd otherwise be worried about masking >>>>> potential compat issues if that JS APIs were unaffected. >>>>> >>>>> Rick >>>>> >>>>> On Thu, Jul 15, 2021 at 11:18 AM Ali Beyad <abe...@chromium.org> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Thu, Jul 15, 2021 at 4:02 AM Mike West <mk...@chromium.org> wrote: >>>>>> >>>>>>> Thanks for the clarifications, Ali. This looks pretty reasonable to >>>>>>> me. LGTM1 % the below: >>>>>>> >>>>>>> I would recommend that you adjust the design doc to remove the >>>>>>> reference to "a client hint token that will reduce the User-Agent >>>>>>> header", >>>>>>> as it doesn't sound like that's what you're aiming to experiment with. >>>>>>> My >>>>>>> understanding of your response is that you'll only adjust the UA in the >>>>>>> presence of the Origin Trial token. >>>>>>> >>>>>> >>>>>> I updated >>>>>> <https://docs.google.com/document/d/1feIxK9S7oNgT2oGGebbxE9X0O-4wTKcsP_gRaY99tq4/edit#heading=h.x5gzpen7eyc> >>>>>> the design doc to make the point clear that the UA will only be reduced >>>>>> in >>>>>> the presence of the OT token, and I clarified the role of the new client >>>>>> hint in all this. Thanks for the feedback! >>>>>> >>>>>> >>>>>>> >>>>>>> With regard to the OT schedule, ~6 months from M94 would take us >>>>>>> more or less through M100. In >>>>>>> https://groups.google.com/a/chromium.org/g/blink-api-owners-discuss/c/dhfejxAtj84/m/vr889GowAgAJ, >>>>>>> we agreed (but I don't think documented... I'll fix that) that we'd be >>>>>>> taking ~4 milestones as a typical OT length as we shift into a 4-week >>>>>>> cadence. >>>>>>> >>>>>>> That said, it sounds like you want to use this experiment as a >>>>>>> lead-in to a behavior change and deprecation trial, and holding you to 4 >>>>>>> milestones would put you squarely in the holiday season of M98. I'm >>>>>>> comfortable with y'all extending this out a little longer than usual, >>>>>>> but >>>>>>> I'd appreciate two other API owners weighing in to confirm that plan. >>>>>>> >>>>>>> -mike >>>>>>> >>>>>>> >>>>>>> On Mon, Jul 12, 2021 at 4:55 PM Ali Beyad <abe...@google.com> wrote: >>>>>>> >>>>>>>> Hey Mike, >>>>>>>> >>>>>>>> Thanks for your questions. Answers inline. >>>>>>>> >>>>>>>> On Mon, Jul 12, 2021 at 9:15 AM Mike West <mk...@chromium.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hey Ali, >>>>>>>>> >>>>>>>>> There are a few details here that I'm not sure I understand. >>>>>>>>> >>>>>>>>> 1. The linked design doc describes opting into UA reduction >>>>>>>>> through both an origin trial, and a client hint-based opt-in. Does >>>>>>>>> this >>>>>>>>> intent include both mechanisms? Or is it only about the origin trial? >>>>>>>>> >>>>>>>> >>>>>>>> The I2E is for an origin trial that would control two behaviors: >>>>>>>> >>>>>>>> 1. The Javascript getters for user agent data (e.g. >>>>>>>> navigator.userAgent) >>>>>>>> 2. The new Client Hint `Sec-CH-UA-Reduced` that would indicate >>>>>>>> to the origin that the HTTP header "User-Agent" contains a reduced >>>>>>>> value, >>>>>>>> not the full UA string. >>>>>>>> >>>>>>>> >>>>>>>>> 2. Does a top-level document's opt-in to the origin trial control >>>>>>>>> the UA headers received by requests made from documents it embeds? >>>>>>>>> That is, >>>>>>>>> if a page at A opts-into the OT, and embeds a page from B that does >>>>>>>>> not >>>>>>>>> opt-in, what UA headers will requests initiated from B contain? >>>>>>>>> >>>>>>>> >>>>>>>> The plan was for the requests sent for embedded page B to also >>>>>>>> include the reduced UA string along with the `Sec-CH-UA-Reduced` Client >>>>>>>> Hint, even if B is not opted-in to the Origin Trial. This would be >>>>>>>> accomplished through setting "allow same-origin and cross-origin" >>>>>>>> Permission Policy for the `Sec-CH-UA-Reduced` client hint. The >>>>>>>> feeling was >>>>>>>> that, it would be hard to know if a top-level site is truly functioning >>>>>>>> correctly in the presence of UA reduction if only it, but not its >>>>>>>> embedded >>>>>>>> subresources, are receiving the reduced UA string. >>>>>>>> >>>>>>>> >>>>>>>>> Likewise, what does B have access to via JavaScript? >>>>>>>>> >>>>>>>> >>>>>>>> Great question - while subresource requests sent to B would include >>>>>>>> the reduced UA and `Sec-CH-UA-Reduced` headers, the JavaScript for B >>>>>>>> would >>>>>>>> *not* have access to the reduced UA unless it was also registered >>>>>>>> for the OT. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> 3. Are top-level navigations affected? That is, if A in the >>>>>>>>> example above opts-into the OT, and then navigates to B at the top >>>>>>>>> level, >>>>>>>>> what UA header is delivered? Does the answer change if A navigates >>>>>>>>> same-origin to another page on A? >>>>>>>>> >>>>>>>> >>>>>>>> If there is a top-level navigation to A for the *first* time, then >>>>>>>> it will not receive the reduced UA and the new client hint (although >>>>>>>> the >>>>>>>> initial navigation request could be retried with the reduced UA if >>>>>>>> Critical-CH is set and the OT token is valid). All subsequent >>>>>>>> navigations >>>>>>>> to A, including if A navigates to a same-origin page on A, will >>>>>>>> include the >>>>>>>> reduced UA string and `Sec-CH-UA-Reduced` header. This would hold >>>>>>>> until >>>>>>>> the browser is restarted or session data is cleared, which would also >>>>>>>> clear >>>>>>>> the Accept-CH cache. >>>>>>>> >>>>>>>> For the subresource requests made from A to B, while B would >>>>>>>> include the headers sent to A (including the reduced UA string), B >>>>>>>> would >>>>>>>> *not* save the client hint in its Accept-CH cache. Therefore, a >>>>>>>> subsequent navigation to B would *not* include the reduced UA >>>>>>>> string nor the `Sec-CH-UA-Reduced` header, since it is not opted-in to >>>>>>>> the >>>>>>>> OT. >>>>>>>> >>>>>>>> The behavior can be summed up as "if the top-level navigation is >>>>>>>> opted-in, send the reduced UA to the top-level origin as well as all >>>>>>>> subresource requests, including to those of a different origin". The >>>>>>>> feedback we received thus far from potential partner sites was that it >>>>>>>> would be most useful if the same UA was sent on subresource requests to >>>>>>>> realize and handle any potential breakage. This also seems consistent >>>>>>>> with >>>>>>>> how current client hints work - the same client hints are sent for >>>>>>>> cross-origin subresource requests as long as the Permission Policy >>>>>>>> allows >>>>>>>> it. >>>>>>>> >>>>>>>> We also considered the idea of requiring B to sign up for a >>>>>>>> third-party matching Origin Trial, but that seemed to us like it would >>>>>>>> be >>>>>>>> too much overhead for the top-level sites to have to work through. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> 4. What's your experimentation timeline? >>>>>>>>> >>>>>>>> >>>>>>>> We were hoping to get the origin trial experiment in by the feature >>>>>>>> freeze for M94. The goal would be to run a 6-month experiment. Then, >>>>>>>> we >>>>>>>> would like to run a 6-month deprecation trial thereafter (a separate >>>>>>>> I2E >>>>>>>> would be sent for that) which would send the reduced UA string by >>>>>>>> default, >>>>>>>> but enable those origins opted into the deprecation trial to still >>>>>>>> receive >>>>>>>> the full UA string. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> -mike >>>>>>>>> >>>>>>>>> >>>>>>>>> On Sat, Jul 10, 2021 at 1:31 AM Ali Beyad <abe...@chromium.org> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> I think it makes sense to proceed with a regular origin trial and >>>>>>>>>> look at requesting higher usage limits if/when we get commitments and >>>>>>>>>> estimates for participation in the UA reduction experiment. >>>>>>>>>> >>>>>>>>>> On Thu, Jul 8, 2021 at 2:06 PM Jason Chase <cha...@chromium.org> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thursday, July 8, 2021 at 1:07:59 PM UTC-4 Ali Beyad wrote: >>>>>>>>>>> >>>>>>>>>>>> *Contact emails *aaron...@chromium.org, >>>>>>>>>>>> jadekess...@chromium.org, miketa...@chromium.org, >>>>>>>>>>>> abe...@chromium.org >>>>>>>>>>>> >>>>>>>>>>>> Explainer >>>>>>>>>>>> >>>>>>>>>>>> None >>>>>>>>>>>> >>>>>>>>>>>> Specification >>>>>>>>>>>> >>>>>>>>>>>> None >>>>>>>>>>>> >>>>>>>>>>>> Summary >>>>>>>>>>>> >>>>>>>>>>>> We want to reduce the amount of information the User Agent >>>>>>>>>>>> string exposes in HTTP requests as well as in navigator.userAgent, >>>>>>>>>>>> navigator.appVersion, and navigator.platform. The browser's brand >>>>>>>>>>>> and >>>>>>>>>>>> significant version, its desktop/mobile distinction and the >>>>>>>>>>>> platform it is >>>>>>>>>>>> running on will continue to be sent. >>>>>>>>>>>> >>>>>>>>>>>> We would like to run an Origin Trial for sites to opt into the >>>>>>>>>>>> Reduced User-Agent (and related navigator properties) to >>>>>>>>>>>> proactively test >>>>>>>>>>>> for breakage. See below for more details. >>>>>>>>>>>> >>>>>>>>>>>> Design Doc >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> https://docs.google.com/document/d/1feIxK9S7oNgT2oGGebbxE9X0O-4wTKcsP_gRaY99tq4/edit#heading=h.2navvbygwxwb >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Blink component >>>>>>>>>>>> >>>>>>>>>>>> Blink >>>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink> >>>>>>>>>>>> >>>>>>>>>>>> TAG review >>>>>>>>>>>> >>>>>>>>>>>> https://github.com/w3ctag/design-reviews/issues/640 >>>>>>>>>>>> >>>>>>>>>>>> TAG review status >>>>>>>>>>>> >>>>>>>>>>>> Pending (https://github.com/w3ctag/design-reviews/issues/640) >>>>>>>>>>>> >>>>>>>>>>>> Risks >>>>>>>>>>>> >>>>>>>>>>>> Interoperability and Compatibility >>>>>>>>>>>> >>>>>>>>>>>> The compatibility risk is low, as we’re planning to reduce the >>>>>>>>>>>> amount of information in the UA string, rather than remove the >>>>>>>>>>>> header. Most >>>>>>>>>>>> existing UA detection code should continue to work. It is only >>>>>>>>>>>> future UA >>>>>>>>>>>> detection code that will need to move to use the UA client hints >>>>>>>>>>>> instead. >>>>>>>>>>>> In the long term, we expect this change to improve compatibility, >>>>>>>>>>>> as UA >>>>>>>>>>>> detection based on UA-CH is bound to be more reliable than the >>>>>>>>>>>> current >>>>>>>>>>>> status quo. We hope this Origin Trial will help us flesh out site >>>>>>>>>>>> compat >>>>>>>>>>>> issues we can’t predict a priori. >>>>>>>>>>>> >>>>>>>>>>>> As for interoperability, other vendors are on board with UA >>>>>>>>>>>> information reduction, but not necessarily with the UA Client Hints >>>>>>>>>>>> mechanism that is supposed to replace it. That can create a tricky >>>>>>>>>>>> situation, where developers would need to rely on the User-Agent >>>>>>>>>>>> string for >>>>>>>>>>>> some browsers and on UA-CH for others. >>>>>>>>>>>> >>>>>>>>>>>> Edge: Positive signals ( >>>>>>>>>>>> https://twitter.com/_scottlow/status/1206831008261132289) >>>>>>>>>>>> >>>>>>>>>>>> Firefox: Public support for reducing UA string information - >>>>>>>>>>>> “freezing the User Agent string without any client hints—seems >>>>>>>>>>>> worth-prototyping” (from >>>>>>>>>>>> https://github.com/mozilla/standards-positions/issues/202#issuecomment-558294095 >>>>>>>>>>>> ) >>>>>>>>>>>> >>>>>>>>>>>> Safari: Shipped to some extent. Safari has attempted to >>>>>>>>>>>> completely freeze the UA string >>>>>>>>>>>> <https://twitter.com/rmondello/status/943545865204989953?lang=en> >>>>>>>>>>>> in the past, but somewhat reverted that decision >>>>>>>>>>>> <https://bugs.webkit.org/show_bug.cgi?id=182629#c6>. Nowadays, >>>>>>>>>>>> their UA string seems mostly frozen, with updates only to the >>>>>>>>>>>> browser >>>>>>>>>>>> version. >>>>>>>>>>>> >>>>>>>>>>>> Web developers: Mixed signals. Some positive comments on >>>>>>>>>>>> Twitter, blink-dev, etc., as well as some negative sentiment. >>>>>>>>>>>> >>>>>>>>>>>> Experiment Summary >>>>>>>>>>>> >>>>>>>>>>>> This experiment is going to be a bit different from a normal >>>>>>>>>>>> Origin Trial; the goal is less about gathering information on the >>>>>>>>>>>> design of >>>>>>>>>>>> a new API than it is about enabling developers and administrators >>>>>>>>>>>> to test >>>>>>>>>>>> and ensure compatibility with our proposed changes. This change >>>>>>>>>>>> represents >>>>>>>>>>>> a large compat challenge with very subtle pitfalls and vast >>>>>>>>>>>> dependencies, >>>>>>>>>>>> it’s incredibly important we give developers any opportunity to >>>>>>>>>>>> test >>>>>>>>>>>> systems at every level. >>>>>>>>>>>> >>>>>>>>>>>> As for engaging with the trial itself, there will be two >>>>>>>>>>>> components controlled by the same Origin Trial: >>>>>>>>>>>> >>>>>>>>>>>> 1. >>>>>>>>>>>> >>>>>>>>>>>> Reducing the information in the associated JS getters, if >>>>>>>>>>>> the Origin Trial is enabled. >>>>>>>>>>>> 2. >>>>>>>>>>>> >>>>>>>>>>>> A client hint that gets set when the Origin Trial is >>>>>>>>>>>> enabled, where the client hint indicates to the origin that the >>>>>>>>>>>> User-Agent >>>>>>>>>>>> request header contains the reduced value. Because of the >>>>>>>>>>>> experimental >>>>>>>>>>>> nature of this client hint, a valid Origin Trial token must be >>>>>>>>>>>> sent in the >>>>>>>>>>>> response header by the origin for the client hint to take >>>>>>>>>>>> effect or be >>>>>>>>>>>> stored (in order to prevent platform burn-in for this temporary >>>>>>>>>>>> client hint >>>>>>>>>>>> token). >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> During the process of conducting the Origin Trial, we may find >>>>>>>>>>>> that we need to request an exception to the per-site (and possibly >>>>>>>>>>>> global) >>>>>>>>>>>> limits imposed by Origin Trials. In practice, Origin Trials rarely >>>>>>>>>>>> exceed >>>>>>>>>>>> their quota limits, but if necessary, there is time between when >>>>>>>>>>>> the limits >>>>>>>>>>>> have been exceeded and the Origin Trial is turned off, where we >>>>>>>>>>>> can work >>>>>>>>>>>> with the users on reducing their usage and/or lifting the limits. >>>>>>>>>>>> >>>>>>>>>>> This sounds like the trial to opt-in (and opt-out) for the Page >>>>>>>>>>> Freezing intervention >>>>>>>>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/CWOstYR9rdc/m/knP4dVdKFAAJ>. >>>>>>>>>>> As I recall, that trial didn't end up running at scale, so we >>>>>>>>>>> didn't end up >>>>>>>>>>> testing the usage limits. It seems worth considering as a >>>>>>>>>>> precedent. That >>>>>>>>>>> is, noting the differences in burn-in risk for opting into >>>>>>>>>>> potentially >>>>>>>>>>> breaking behaviour vs taking advantage of new functionality. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Please see the design document >>>>>>>>>>>> <https://docs.google.com/document/d/1feIxK9S7oNgT2oGGebbxE9X0O-4wTKcsP_gRaY99tq4/edit#heading=h.2navvbygwxwb> >>>>>>>>>>>> describing the experiment for more information. >>>>>>>>>>>> >>>>>>>>>>>> Experiment Goals >>>>>>>>>>>> >>>>>>>>>>>> The goal of this trial is to enable developers to test how >>>>>>>>>>>> reducing the User-Agent request header and the related navigator >>>>>>>>>>>> getters >>>>>>>>>>>> will affect their systems and make sure they have all of the tools >>>>>>>>>>>> they >>>>>>>>>>>> need for an effective migration to User Agent Client Hints >>>>>>>>>>>> <https://web.dev/migrate-to-ua-ch/>. We hope that by providing >>>>>>>>>>>> sufficient time to test and provide feedback we can validate our >>>>>>>>>>>> current >>>>>>>>>>>> plans for UA Reduction and safely roll them out to the web at >>>>>>>>>>>> large. >>>>>>>>>>>> >>>>>>>>>>>> We will be relying heavily on user and developer feedback to >>>>>>>>>>>> understand where breakage occurs, or where use cases are not >>>>>>>>>>>> accounted for. >>>>>>>>>>>> We will create a GitHub repository as well as a public mailing >>>>>>>>>>>> list for >>>>>>>>>>>> gathering feedback. When the OT is ready, we plan to publish >>>>>>>>>>>> developer >>>>>>>>>>>> guidance on how to enroll and provide feedback. >>>>>>>>>>>> >>>>>>>>>>>> Experiment Risks >>>>>>>>>>>> >>>>>>>>>>>> Despite the proposed changes being net-positive in terms of >>>>>>>>>>>> privacy, there are some compat risks, as many sites have come to >>>>>>>>>>>> rely on >>>>>>>>>>>> the shape of the User-Agent header and related JS interfaces. Site >>>>>>>>>>>> breakage >>>>>>>>>>>> can take many forms, both obvious and non-obvious. However, since >>>>>>>>>>>> sites are >>>>>>>>>>>> in control of the Origin-Trial and Accept-CH headers, a site can >>>>>>>>>>>> quickly >>>>>>>>>>>> opt out of the experiment when breakage is encountered. >>>>>>>>>>>> >>>>>>>>>>>> Will this feature be supported on all six Blink platforms >>>>>>>>>>>> (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? >>>>>>>>>>>> >>>>>>>>>>>> No (All but WebView) >>>>>>>>>>>> >>>>>>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>>>>>>>>>>> ? >>>>>>>>>>>> >>>>>>>>>>>> No. >>>>>>>>>>>> >>>>>>>>>>>> Flag name >>>>>>>>>>>> >>>>>>>>>>>> #reduce-user-agent >>>>>>>>>>>> >>>>>>>>>>>> Tracking bug >>>>>>>>>>>> >>>>>>>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=955620 >>>>>>>>>>>> >>>>>>>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1222742 >>>>>>>>>>>> >>>>>>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>>>>> >>>>>>>>>>>> https://chromestatus.com/feature/5704553745874944 >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>> 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/CABJKADxFLTHtvYPzNzF%3Dy5wP4x%2BaK1cF3RRCWii7UjV54EjkSw%40mail.gmail.com >>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABJKADxFLTHtvYPzNzF%3Dy5wP4x%2BaK1cF3RRCWii7UjV54EjkSw%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/CA%2BWdJ_4jkExO4p9GdCdc7BUa8GBK0eota1q8EfEi%3D5%2BBuj3jCw%40mail.gmail.com >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BWdJ_4jkExO4p9GdCdc7BUa8GBK0eota1q8EfEi%3D5%2BBuj3jCw%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/CA%2BWdJ_6KKuH%2B-KyDeHxc_EC0A4eCpqsptdO3_E6fq8BpZoRJPw%40mail.gmail.com.
