Sorry seems I accidently switched the S sides in the first question, I meant from public HTTP to private HTTPS so it shouldn't be mixed content, and in such case there's no preflight request. As I mentioned I installed chrome 98 to test it, when accessing a resource from public HTTPS to private HTTPS there's a preflight request but no such request on an access from public HTTP to private HTTPS.
On Tuesday, April 19, 2022 at 7:27:42 PM UTC+3 Titouan Rigoudy wrote: > Hi there, > > 1. Such requests are blocked by mixed content. This launch does not change > that. > 2. You will want to respond 200 OK to PNA preflight requests to your > private HTTPS server with the right headers. See the blog post [1] for > details. > > Cheers, > Titouan > > [1] > https://developer.chrome.com/blog/private-network-access-preflight/#server-side-requests > > On Sun, Apr 17, 2022 at 4:56 PM John Doe <clas...@gmail.com> wrote: > >> 1. In Chrome 98, there were no preflight requests when accessing from >> public HTTPS to private HTTP, will the same be true in the final version? >> 2. In the case when I have a private HTTPS server that I want everyone to >> have access to (also via public HTTP), what options do I have ? >> >> On Wednesday, April 6, 2022 at 8:23:58 PM UTC+3 Titouan Rigoudy wrote: >> >>> Hi all, >>> >>> Thanks for the timely question, I was about to send an update here. >>> >>> We have fixed nearly all of the blockers identified in the above doc. >>> The only outstanding issue is the aforementioned crash, which required a >>> bit more design work than the rest. That work has been completed and CLs to >>> fix the problem are now in review; they should land shortly and make it in >>> Chrome 102. >>> >>> We would like to ship again in Chrome 102 in warning-only mode, just as >>> we last tried in Chrome 98. Preflights will be sent but their results will >>> not be enforced. Failed preflights will show warnings in DevTools, but >>> requests will otherwise continue unimpeded. >>> >>> Things will stay that way for at least 3 milestones. We will gather >>> compatibility data by monitoring failed preflights, then circle back here >>> to garner approvals to turn on enforcement. That launch will be accompanied >>> by a deprecation trial for web developers to sign up for a time extension >>> if they failed to notice the warnings in time. >>> >>> Cheers, >>> Titouan >>> >>> On Wed, Apr 6, 2022 at 3:29 AM Logan Wei <shapi...@gmail.com> wrote: >>> >>>> Hello, is there now an updated timeline to roll out this change? Will >>>> the trial restart in Chrome 102 or a later version? >>>> >>>> On Wednesday, March 2, 2022 at 6:36:21 PM UTC+8 Titouan Rigoudy wrote: >>>> >>>>> Hi all, >>>>> >>>>> Here's the promised doc: >>>>> https://docs.google.com/document/d/1fdwetZXUz_Q03ZpGwXizq5AE1yn_lMhamUJMwvsHvTU/edit >>>>> >>>>> (public, comment access for committers only) >>>>> >>>>> Cheers, >>>>> Titouan >>>>> >>>>> On Thu, Feb 17, 2022 at 3:29 PM Mike Taylor <mike...@chromium.org> >>>>> wrote: >>>>> >>>>>> Thanks for the update Titouan. Looking forward to reading your doc. >>>>>> >>>>>> On 2/17/22 9:25 AM, Titouan Rigoudy wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> Just to let you know that due to a couple issues, chief among which a >>>>>> renderer crash (crbug.com/1279376), we are rolling this feature back >>>>>> from Chrome 98. >>>>>> >>>>>> A few issues have been identified and will block our next attempt at >>>>>> shipping this. In the meantime, we gathered some useful information >>>>>> about >>>>>> impact and notified developers of the upcoming change. I'll write a doc >>>>>> summarizing the timeline and lessons learned, then share as appropriate >>>>>> here. >>>>>> >>>>>> Cheers, >>>>>> Titouan >>>>>> >>>>>> On Mon, Dec 6, 2021 at 5:26 PM Chris Harrelson <chri...@chromium.org> >>>>>> wrote: >>>>>> >>>>>>> LGTM3 for step 1. >>>>>>> >>>>>>> On Mon, Dec 6, 2021 at 6:11 AM Mike Taylor <mike...@chromium.org> >>>>>>> wrote: >>>>>>> >>>>>>>> LGTM2 for step 1. >>>>>>>> >>>>>>>> On 12/6/21 5:31 AM, Titouan Rigoudy wrote: >>>>>>>> >>>>>>>> *assuming I get 2 more LGTMs, that is. >>>>>>>> >>>>>>>> On Mon, Dec 6, 2021 at 11:31 AM Titouan Rigoudy <tit...@google.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Thanks! I'll come back for further discussion with UKM data in >>>>>>>>> hand. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Titouan >>>>>>>>> >>>>>>>>> On Mon, Dec 6, 2021 at 10:58 AM Yoav Weiss <yoav...@chromium.org> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> I agree UKM analysis should not block step 1, as it holds little >>>>>>>>>> risk. (There's still some risks that servers will choke in the face >>>>>>>>>> of >>>>>>>>>> preflights, but that seems minor compared to the enforcement risk) >>>>>>>>>> >>>>>>>>>> Therefore,* LGTM1 for step 1* (preflights with no enforcement), >>>>>>>>>> but not further (yet). Please come back to this thread with any data >>>>>>>>>> you >>>>>>>>>> may have as a result of adding UKMs. >>>>>>>>>> >>>>>>>>>> On Fri, Dec 3, 2021 at 6:44 PM 'Titouan Rigoudy' via blink-dev < >>>>>>>>>> blin...@chromium.org> wrote: >>>>>>>>>> >>>>>>>>>>> Yoav, do you think UKM analysis should block sending preflights >>>>>>>>>>> without enforcing their success? I believe sending these will allow >>>>>>>>>>> us to >>>>>>>>>>> get more precise information on the affected websites through the >>>>>>>>>>> usecounter recorded in crrev.com/c/3310846. I can then analyze >>>>>>>>>>> UKM data and use the results to inform the decision whether and >>>>>>>>>>> when to >>>>>>>>>>> switch enforcement on? >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> Titouan >>>>>>>>>>> >>>>>>>>>>> On Thu, Dec 2, 2021 at 5:19 PM Titouan Rigoudy < >>>>>>>>>>> tit...@google.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> I agree! >>>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> Titouan >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Dec 2, 2021 at 5:17 PM Mike West <mk...@chromium.org> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> _I_ don't think we should do that, but I'd defer to Titouan's >>>>>>>>>>>>> preference. :) >>>>>>>>>>>>> >>>>>>>>>>>>> -mike >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Dec 2, 2021 at 5:14 PM Mike Taylor < >>>>>>>>>>>>> mike...@chromium.org> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks - I also don't think there's a lot of value in this >>>>>>>>>>>>>> particular header being the odd-one-out, just wanted to confirm >>>>>>>>>>>>>> we're not >>>>>>>>>>>>>> going to ship "true" first and try to change that to ?1 later >>>>>>>>>>>>>> (which is >>>>>>>>>>>>>> always challenging). >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 12/2/21 11:11 AM, Mike West wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'm not sure it makes sense to introduce a structured header >>>>>>>>>>>>>> here, given that it's layering on top of CORS headers that I >>>>>>>>>>>>>> don't think >>>>>>>>>>>>>> there's substantial interest in changing. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -mike >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Thu, Dec 2, 2021 at 4:55 PM 'Titouan Rigoudy' via >>>>>>>>>>>>>> blink-dev <blin...@chromium.org> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Mike, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> There is no support for structured headers so far, for >>>>>>>>>>>>>>> consistency reasons, and there has been no movement to >>>>>>>>>>>>>>> deprecate the "true" >>>>>>>>>>>>>>> value for Access-Control-Allow-Credentials. The value of such a >>>>>>>>>>>>>>> deprecation >>>>>>>>>>>>>>> seems minimal. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I could pretty easily add support for the structured "?1" >>>>>>>>>>>>>>> value on top of the "true" token for the new >>>>>>>>>>>>>>> Access-Control-Allow-Private-Network header, and specify that, >>>>>>>>>>>>>>> but I'm not >>>>>>>>>>>>>>> sure it would be terribly useful. Do you think otherwise? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>> Titouan >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Thu, Dec 2, 2021 at 4:45 PM Mike Taylor < >>>>>>>>>>>>>>> mike...@chromium.org> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi Titouan, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'm curious what the plan is for structured headers. >>>>>>>>>>>>>>>> https://github.com/WICG/private-network-access/issues/45 >>>>>>>>>>>>>>>> is marked as blocked - has there been other progress or >>>>>>>>>>>>>>>> thinking behind the >>>>>>>>>>>>>>>> scenes? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> thanks, >>>>>>>>>>>>>>>> Mike >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 11/29/21 10:36 AM, 'Titouan Rigoudy' via blink-dev wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Contact emails tit...@chromium.org, va...@chromium.org, >>>>>>>>>>>>>>>> cl...@chromium.org >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Explainer >>>>>>>>>>>>>>>> https://github.com/WICG/private-network-access/blob/main/explainer.md >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Specification >>>>>>>>>>>>>>>> https://wicg.github.io/private-network-access/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Design docs >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> https://docs.google.com/document/d/1FYPIeP90MQ_pQ6UAo0mCB3g2Z_AynfPWHbDnHIST6VI/edit >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Summary >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Sends a CORS preflight request ahead of any private network >>>>>>>>>>>>>>>> requests for subresources, asking for explicit permission from >>>>>>>>>>>>>>>> the target >>>>>>>>>>>>>>>> server. A private network request is any request from a public >>>>>>>>>>>>>>>> website to a >>>>>>>>>>>>>>>> private IP address or localhost, or from a private website >>>>>>>>>>>>>>>> (e.g. intranet) >>>>>>>>>>>>>>>> to localhost. Sending a preflight request mitigates the risk >>>>>>>>>>>>>>>> of cross-site >>>>>>>>>>>>>>>> request forgery attacks against private network devices such >>>>>>>>>>>>>>>> as routers, >>>>>>>>>>>>>>>> which are often not prepared to defend against this threat. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Blink component >>>>>>>>>>>>>>>> Blink>SecurityFeature>CORS>PrivateNetworkAccess >>>>>>>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ESecurityFeature%3ECORS%3EPrivateNetworkAccess> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> TAG review >>>>>>>>>>>>>>>> https://github.com/w3ctag/design-reviews/issues/572 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> TAG review status Pending >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Risks >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Interoperability and Compatibility >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The main interoperability risk, as always, is if other >>>>>>>>>>>>>>>> browser engines do not implement this. Compat risk is >>>>>>>>>>>>>>>> straightforward: web >>>>>>>>>>>>>>>> servers that do not handle the new preflight requests will >>>>>>>>>>>>>>>> eventually >>>>>>>>>>>>>>>> break, once the feature ships. The plan to address this is as >>>>>>>>>>>>>>>> follows: 1. >>>>>>>>>>>>>>>> Send preflight request, ignore result, always send actual >>>>>>>>>>>>>>>> request. Failed >>>>>>>>>>>>>>>> preflight requests will result in a warning being shown in >>>>>>>>>>>>>>>> devtools. 2. >>>>>>>>>>>>>>>> Wait for 3 milestones. 3. Gate actual request on preflight >>>>>>>>>>>>>>>> request success, >>>>>>>>>>>>>>>> with deprecation trial for developers to buy some more time. >>>>>>>>>>>>>>>> 4. End >>>>>>>>>>>>>>>> deprecation trial 4 milestones later. UseCounters: >>>>>>>>>>>>>>>> https://chromestatus.com/metrics/feature/timeline/popularity/3753 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> https://chromestatus.com/metrics/feature/timeline/popularity/3755 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> https://chromestatus.com/metrics/feature/timeline/popularity/3757 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The above measure pages that make at least one private network >>>>>>>>>>>>>>>> request for >>>>>>>>>>>>>>>> which we would now send a preflight request. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Gecko: Worth prototyping ( >>>>>>>>>>>>>>>> https://github.com/mozilla/standards-positions/issues/143) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> WebKit: No signal ( >>>>>>>>>>>>>>>> https://lists.webkit.org/pipermail/webkit-dev/2021-November/032040.html) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Pending response. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Web developers: No signals Anecdotal evidence so far >>>>>>>>>>>>>>>> suggests that most web developers are OK with this new >>>>>>>>>>>>>>>> requirement, though >>>>>>>>>>>>>>>> some do not control the target endpoints and would be >>>>>>>>>>>>>>>> negatively impacted. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Other signals: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Ergonomics >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> None. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Activation >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Gating access to the private network overnight on preflight >>>>>>>>>>>>>>>> requests would likely result in widespread breakage. This is >>>>>>>>>>>>>>>> why the plan >>>>>>>>>>>>>>>> is to first send requests but not act on their result, giving >>>>>>>>>>>>>>>> server >>>>>>>>>>>>>>>> developers time to implement code handling these requests. >>>>>>>>>>>>>>>> Deprecation >>>>>>>>>>>>>>>> warnings will be surfaced in DevTools to alert web/client >>>>>>>>>>>>>>>> developers when >>>>>>>>>>>>>>>> the potential for breakage later on is detected. Enforcement >>>>>>>>>>>>>>>> will be turned >>>>>>>>>>>>>>>> on later (aiming for 3 milestones), along with a deprecation >>>>>>>>>>>>>>>> trial for >>>>>>>>>>>>>>>> impacted web developers to buy themselves some more time. >>>>>>>>>>>>>>>> Experience >>>>>>>>>>>>>>>> suggests a large fraction of developers will not notice the >>>>>>>>>>>>>>>> advance >>>>>>>>>>>>>>>> deprecation warnings until things break. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Security >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This change aims to be security-positive, preventing CSRF >>>>>>>>>>>>>>>> attacks against soft and juicy targets such as router admin >>>>>>>>>>>>>>>> interfaces. DNS >>>>>>>>>>>>>>>> rebinding threats were of particular concern during the design >>>>>>>>>>>>>>>> of this >>>>>>>>>>>>>>>> feature: >>>>>>>>>>>>>>>> https://docs.google.com/document/d/1FYPIeP90MQ_pQ6UAo0mCB3g2Z_AynfPWHbDnHIST6VI/edit#heading=h.189j5gnadts9 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Debuggability >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Relevant information (client and resource IP address space) >>>>>>>>>>>>>>>> is already piped into the DevTools network panel. Deprecation >>>>>>>>>>>>>>>> warnings and >>>>>>>>>>>>>>>> errors will be surfaced in the DevTools issues panel >>>>>>>>>>>>>>>> explaining the problem >>>>>>>>>>>>>>>> when it arises. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>>>>>>>>>>>>>>> ? Yes >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> DevTrial instructions >>>>>>>>>>>>>>>> https://github.com/WICG/private-network-access/blob/main/HOWTO.md >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Flag name PrivateNetworkAccessRespectPreflightResults >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Requires code in //chrome? False >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Tracking bug https://crbug.com/591068 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Launch bug https://crbug.com/1274149 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Estimated milestones >>>>>>>>>>>>>>>> DevTrial on desktop 98 >>>>>>>>>>>>>>>> DevTrial on android 98 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>>>>>>>>> https://chromestatus.com/feature/5737414355058688 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Links to previous Intent discussions Intent to prototype: >>>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/PrB0xnNxaHs/m/jeoxvNjXCAAJ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This intent message was generated by Chrome Platform Status >>>>>>>>>>>>>>>> <https://www.chromestatus.com/>. >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> 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/CAPATO9fdAK%2BnrTfUzug8ub_DhV_LE0b7XrgZ7j5%2Bj_BHtW-FXg%40mail.gmail.com >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPATO9fdAK%2BnrTfUzug8ub_DhV_LE0b7XrgZ7j5%2Bj_BHtW-FXg%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/CAPATO9f3dAnHromxwvp8jWRxVLYVKZ0PAG5snX2KDFAYz4kc7Q%40mail.gmail.com >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPATO9f3dAnHromxwvp8jWRxVLYVKZ0PAG5snX2KDFAYz4kc7Q%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/CAPATO9ePgpof%2BBDWS9X7sfHHAqgc6Arem3b78ZGC%3D%2Bp4jB6_AQ%40mail.gmail.com >>>>>>>>>>> >>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPATO9ePgpof%2BBDWS9X7sfHHAqgc6Arem3b78ZGC%3D%2Bp4jB6_AQ%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/6e557fb7-5b1d-20bc-aae5-65526ca8efb7%40chromium.org >>>>>>>> >>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6e557fb7-5b1d-20bc-aae5-65526ca8efb7%40chromium.org?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/f196ea62-fb69-4a89-a9d7-fb76b7322addn%40chromium.org.
