Hi team,
Currently we want to exempt the request from LNA policy, and from what I
understand is that we need to add a flag `targetAddressSpace` when making
the request to our API server, for e.g: *smoke.our-api.com. *Then we need
to add this inside the fetch option:
fetch("http://*smoke.our-api.com/product* ", {
targetAddressSpace: "local",
});
So, my questions are:
1. Is that `*local*` value correct? Or should I use another value?
2. Currently, we're using axios for making request in our application, is
there any document for how to add that tag for the axios?
Sorry if I have asked dumb question since I'm not really good at networking.
Thank in advance
On Tuesday, November 4, 2025 at 9:50:38 PM UTC+7 Hubert Chao wrote:
> Reading the issue, it looks like they've figured out the issue, which
> involves iframes and permission policies.
>
> In case there are others still having issues, we've written an adoption
> guide
> <https://docs.google.com/document/d/1QQkqehw8umtAgz5z0um7THx-aoU251p705FbIQjDuGs/edit?usp=sharing>
> (which
> the MSAL authors referenced) that will hopefully help answer many, if not
> all questions.
>
> /hubert
>
> On Tuesday, November 4, 2025 at 8:57:58 AM UTC-5 Tim Abbott wrote:
>
>> Just flagging that the rollout of this feature in Chrome 142 has impacted
>> MSAL re-authentication for internal web apps. See
>> https://github.com/azuread/microsoft-authentication-library-for-js/issues/8100
>>
>>
>> On Tuesday, 30 September 2025 at 03:44:02 UTC+1 Chris Thompson wrote:
>>
>>> A quick update: We have decided to delay our launch by one milestone due
>>> to a bug that could break certain captive portals on Android (
>>> crbug.com/448107420). We are now targeting M142 for our full launch.
>>> This small delay should also help affected sites have a bit more time to
>>> adapt to the new permission prompt.
>>>
>>> On Wed, Sep 3, 2025 at 3:34 PM Vladimir Levin <[email protected]>
>>> wrote:
>>>
>> LGTM3
>>>>
>>>> Thanks,
>>>> Vlad
>>>>
>>>> On Wed, Sep 3, 2025, 12:58 p.m. Chris Harrelson <[email protected]>
>>>> wrote:
>>>>
>>> Thanks for all the detailed explanations. LGTM2.
>>>>>
>>>>> On Wed, Sep 3, 2025 at 8:48 AM Chris Thompson <[email protected]>
>>>>> wrote:
>>>>>
>>>> *To Vlad's questions:*
>>>>>>
>>>>>> > - I assume direct navigation to a local network is fine and remains
>>>>>> without permission? (like navigating to your router's settings page)
>>>>>>
>>>>>> Correct, main frame navigations are not currently in scope.
>>>>>>
>>>>>> > - By "secure context", you mean that the page which wants to access
>>>>>> local network has to be secure. Is that right?
>>>>>>
>>>>>> Yes, to be granted the permission the requesting page must be a
>>>>>> secure context.
>>>>>>
>>>>>> > - What's the behavior of local file (file://) accessing local
>>>>>> network?
>>>>>>
>>>>>> This is somewhat weakly specified currently (file:// URLs are weird
>>>>>> in general), but Chromium's behavior is to treat them the same as
>>>>>> http://localhost/ and thus not subject to LNA restrictions.
>>>>>>
>>>>>> *To Daniel's question:*
>>>>>>
>>>>>> > I don't quite understand how these people are affected. Will
>>>>>> something break for them, or open up for them? If something breaks, how
>>>>>> badly does it break? Or is it something that we want to break?
>>>>>>
>>>>>> Certain requests would fail due to the combination of the LNA
>>>>>> permission requiring secure contexts and mixed content blocking.
>>>>>>
>>>>>> The main case that breaks is a public site making a request to
>>>>>> http://a.example, which *resolves* to a local IP address (or the
>>>>>> loopback address). Today, that site could be on HTTP to avoid having
>>>>>> these
>>>>>> requests blocked as mixed content. With LNA, the site must be on HTTPS
>>>>>> to
>>>>>> request the permission, *but* the browser can't know that these
>>>>>> subresource requests are until after we've resolved the hostname (which
>>>>>> occurs *after* mixed content blocking).
>>>>>>
>>>>>> For fetch() calls, we have the `targetAddressSpace` option for
>>>>>> pre-specifying that requests like this are to the local network, and
>>>>>> thus
>>>>>> we can exempt them from mixed content blocking. This may require some
>>>>>> slight modifications to existing sites to add the flag to any affected
>>>>>> fetch() calls to avoid breakage.
>>>>>>
>>>>>> The reverse OT helps give a temporary escape hatch here, to give
>>>>>> sites more time to adapt (such as adding `targetAddressSpace` flags,
>>>>>> migrating to HTTPS, etc.). We plan to follow up with any sites that
>>>>>> enroll
>>>>>> in the OT to try to see if there are additional affordances we could add
>>>>>> to
>>>>>> the spec and our implementation to help address why they can't migrate
>>>>>> to
>>>>>> HTTPS yet.
>>>>>>
>>>>>> On Wed, Sep 3, 2025 at 8:35 AM Daniel Bratell <[email protected]>
>>>>>> wrote:
>>>>>>
>>>>> In addition to Vlad's questions, I have one question about this line
>>>>>>> in the Compat section:
>>>>>>>
>>>>>>> > Based on our UseCounter
>>>>>>> PrivateNetworkAccessInsecureResourceNotKnownPrivate, we currently
>>>>>>> estimate
>>>>>>> an upper bound of 0.004% of page loads may make local network requests
>>>>>>> which would currently run afoul of mixed content blocking despite the
>>>>>>> exceptions we have added.
>>>>>>>
>>>>>>> I don't quite understand how these people are affected. Will
>>>>>>> something break for them, or open up for them? If something breaks, how
>>>>>>> badly does it break? Or is it something that we want to break?
>>>>>>>
>>>>>>> /Daniel
>>>>>>>
>>>>>>>
>>>>>>> On 2025-09-03 17:29, Vladimir Levin wrote:
>>>>>>>
>>>>>> Hey, I just wanted to clarify a couple of use cases:
>>>>>>>
>>>>>>> - I assume direct navigation to a local network is fine and remains
>>>>>>> without permission? (like navigating to your router's settings page)
>>>>>>> - By "secure context", you mean that the page which wants to access
>>>>>>> local network has to be secure. Is that right?
>>>>>>> - What's the behavior of local file (file://) accessing local
>>>>>>> network?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Vlad
>>>>>>>
>>>>>>> On Wednesday, September 3, 2025 at 10:23:02 AM UTC-4 Alex Russell
>>>>>>> wrote:
>>>>>>>
>>>>>>> Sorry, failed to spot the long discussion in Considered Alternatives
>>>>>>>> in the Explainer. Thanks for putting it all down there.
>>>>>>>>
>>>>>>>> LGTM1
>>>>>>>>
>>>>>>>> On Wednesday, September 3, 2025 at 3:20:54 PM UTC+1 Alex Russell
>>>>>>>> wrote:
>>>>>>>>
>>>>>>> Is there a document that summarises why Private Network Access was
>>>>>>>>> abandoned? And was there any discussion of explicit API for this?
>>>>>>>>>
>>>>>>>>> Best,
>>>>>>>>>
>>>>>>>>> Alex
>>>>>>>>>
>>>>>>>>> On Wednesday, September 3, 2025 at 12:32:02 AM UTC+1 Chris
>>>>>>>>> Thompson wrote:
>>>>>>>>>
>>>>>>>> Contact emails
>>>>>>>>>>
>>>>>>>>>> [email protected]
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Explainer
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> https://github.com/WICG/local-network-access/blob/main/explainer.md
>>>>>>>>>>
>>>>>>>>>> Specification
>>>>>>>>>>
>>>>>>>>>> https://wicg.github.io/local-network-access
>>>>>>>>>>
>>>>>>>>>> Summary
>>>>>>>>>>
>>>>>>>>>> Chrome 141 restricts the ability for sites to make requests to
>>>>>>>>>> the user's local network, gated behind a permission prompt.
>>>>>>>>>>
>>>>>>>>>> A local network request is any request from a public website to a
>>>>>>>>>> local IP address or loopback, or from a local website (e.g.
>>>>>>>>>> intranet) to
>>>>>>>>>> loopback. Gating the ability for websites to perform these requests
>>>>>>>>>> behind
>>>>>>>>>> a permission mitigates the risk of cross-site request forgery
>>>>>>>>>> attacks
>>>>>>>>>> against local network devices such as routers, and reduces the
>>>>>>>>>> ability of
>>>>>>>>>> sites to use these requests to fingerprint the user's local network.
>>>>>>>>>>
>>>>>>>>>> This permission is restricted to secure contexts. If granted, the
>>>>>>>>>> permissions additionally relaxes mixed content blocking for local
>>>>>>>>>> network
>>>>>>>>>> requests (since many local devices are not able to obtain publicly
>>>>>>>>>> trusted
>>>>>>>>>> TLS certificates). Requests from insecure contexts will be silently
>>>>>>>>>> rejected. Sites may temporarily opt-out of the secure contexts
>>>>>>>>>> restriction
>>>>>>>>>> using the reverse origin trial “Local Network Access from
>>>>>>>>>> Non-Secure Contexts
>>>>>>>>>> <https://developer.chrome.com/origintrials/#/view_trial/3826370833404657665>”,
>>>>>>>>>>
>>>>>>>>>> included in this launch.
>>>>>>>>>>
>>>>>>>>>> This initial version of Local Network Access (LNA) applies to
>>>>>>>>>> subresource requests, fetch() requests, and navigating subframes. In
>>>>>>>>>> the
>>>>>>>>>> near future we plan to send a separate Intent-to-Ship for applying
>>>>>>>>>> LNA to
>>>>>>>>>> WebSockets, WebTransport, and WebRTC connections.
>>>>>>>>>>
>>>>>>>>>> This work supersedes a prior effort called "Private Network
>>>>>>>>>> Access" (e.g., https://chromestatus.com/feature/5737414355058688,
>>>>>>>>>> https://chromestatus.com/feature/5954091755241472) which used
>>>>>>>>>> preflight requests to allow local devices to opt-in to receiving
>>>>>>>>>> requests.
>>>>>>>>>>
>>>>>>>>>> Enterprises that need to disable or auto-grant the permission can
>>>>>>>>>> do so using the LocalNetworkAccessAllowedForUrls
>>>>>>>>>> <https://chromeenterprise.google/policies/#LocalNetworkAccessAllowedForUrls>
>>>>>>>>>>
>>>>>>>>>> and LocalNetworkAccessBlockedForUrls
>>>>>>>>>> <https://chromeenterprise.google/policies/#LocalNetworkAccessBlockedForUrls>
>>>>>>>>>>
>>>>>>>>>> policies. The value of '*' can be used to allow local network access
>>>>>>>>>> on all
>>>>>>>>>> URLs, matching the behavior prior to rolling out the restrictions.
>>>>>>>>>> At
>>>>>>>>>> launch, the policies can be set using custom configurations
>>>>>>>>>> <https://support.google.com/chrome/a/answer/14749672>.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Blink component
>>>>>>>>>>
>>>>>>>>>> Blink>SecurityFeature>LocalNetworkAccess
>>>>>>>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ESecurityFeature%3ELocalNetworkAccess%22>
>>>>>>>>>>
>>>>>>>>>> TAG review
>>>>>>>>>>
>>>>>>>>>> https://github.com/w3ctag/design-reviews/issues/1116
>>>>>>>>>>
>>>>>>>>>> TAG review status
>>>>>>>>>>
>>>>>>>>>> Issues addressed (satisfied with concerns)
>>>>>>>>>>
>>>>>>>>>> Origin Trial Name
>>>>>>>>>>
>>>>>>>>>> Local Network Access from Non-Secure Contexts
>>>>>>>>>> <https://developer.chrome.com/origintrials/#/view_trial/3826370833404657665>
>>>>>>>>>>
>>>>>>>>>> Chromium Trial Name
>>>>>>>>>>
>>>>>>>>>> LocalNetworkAccessNonSecureContextAllowed
>>>>>>>>>>
>>>>>>>>>> Origin Trial documentation link
>>>>>>>>>>
>>>>>>>>>> https://developer.chrome.com/blog/local-network-access
>>>>>>>>>>
>>>>>>>>>> Risks
>>>>>>>>>>
>>>>>>>>>> Interoperability and Compatibility
>>>>>>>>>>
>>>>>>>>>> Interoperability risks:
>>>>>>>>>>
>>>>>>>>>> LNA requires a Secure Context to make local network requests, but
>>>>>>>>>> exempts some of these local network requests from mixed content
>>>>>>>>>> checks (if
>>>>>>>>>> the user grants permission). If another browser does not implement
>>>>>>>>>> LNA,
>>>>>>>>>> these same local network requests might be blocked as mixed content,
>>>>>>>>>> or the
>>>>>>>>>> site might need to serve over HTTPS for Chrome and over HTTP for
>>>>>>>>>> browsers
>>>>>>>>>> that don't implement LNA (to avoid triggering mixed content).
>>>>>>>>>>
>>>>>>>>>> Compatibility risks:
>>>>>>>>>>
>>>>>>>>>> There are some local network requests types that we cannot know
>>>>>>>>>> ahead of time will be going to the local network (e.g., a
>>>>>>>>>> subresource
>>>>>>>>>> request to http://test.example which then resolves to
>>>>>>>>>> 192.168.0.1). These would be blocked as mixed content, as mixed
>>>>>>>>>> content
>>>>>>>>>> checks happen before hostname resolution (i.e., they occur before
>>>>>>>>>> "Obtain a
>>>>>>>>>> connection" in Fetch). Explicit local IP addresses, .local
>>>>>>>>>> domains, and fetch() requests with the new `targetAddressSpace`
>>>>>>>>>> fetch()
>>>>>>>>>> option are exempted from mixed content checks, but other connection
>>>>>>>>>> types
>>>>>>>>>> may be difficult for developers to work around mixed content
>>>>>>>>>> blocking
>>>>>>>>>> (e.g., WebSockets wicg/local-network-access#16
>>>>>>>>>> <https://github.com/wicg/local-network-access/issues/16>).
>>>>>>>>>>
>>>>>>>>>> Alongside shipping these restrictions we are running a reverse
>>>>>>>>>> origin trial to allow sites to (temporarily) opt-out of the secure
>>>>>>>>>> contexts
>>>>>>>>>> requirement -- this would be an escape hatch for mixed content. This
>>>>>>>>>> origin
>>>>>>>>>> trial can only be enabled through origin tokens delivered via HTTP
>>>>>>>>>> header
>>>>>>>>>> due the trial affecting the security policy of the document being
>>>>>>>>>> loaded.
>>>>>>>>>>
>>>>>>>>>> We have previously run a Dev Trial and a 50% Finch experiment on
>>>>>>>>>> Canary/Dev/Beta which helped alert potentially affected developers
>>>>>>>>>> and find
>>>>>>>>>> some bugs early before shipping. Based in part on questions from
>>>>>>>>>> affected
>>>>>>>>>> developers we have put together an “LNA Adoption Guide
>>>>>>>>>> <https://docs.google.com/document/d/1QQkqehw8umtAgz5z0um7THx-aoU251p705FbIQjDuGs/edit?usp=sharing>”
>>>>>>>>>>
>>>>>>>>>> to help affected sites adapt to these new restrictions.
>>>>>>>>>>
>>>>>>>>>> Based on our UseCounter
>>>>>>>>>> PrivateNetworkAccessInsecureResourceNotKnownPrivate
>>>>>>>>>> <https://chromestatus.com/metrics/feature/timeline/popularity/5319>,
>>>>>>>>>> we currently estimate an upper bound of 0.004% of page loads may
>>>>>>>>>> make local
>>>>>>>>>> network requests which would currently run afoul of mixed content
>>>>>>>>>> blocking
>>>>>>>>>> despite the exceptions we have added.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Gecko: Under consideration (
>>>>>>>>>> https://groups.google.com/a/mozilla.org/g/dev-platform/c/B8oN3ARp_j0/m/rWKXmnj4AAAJ)
>>>>>>>>>>
>>>>>>>>>> Firefox is prototyping based on our spec draft. Request for signals:
>>>>>>>>>> https://github.com/mozilla/standards-positions/issues/1260
>>>>>>>>>>
>>>>>>>>>> WebKit: No signal. Request for signals:
>>>>>>>>>> https://github.com/WebKit/standards-positions/issues/520
>>>>>>>>>>
>>>>>>>>>> Web developers: Mixed signals (
>>>>>>>>>> https://github.com/explainers-by-googlers/local-network-access/issues).
>>>>>>>>>>
>>>>>>>>>> Feedback from developers has been mixed, both due the new burden of
>>>>>>>>>> a
>>>>>>>>>> permission prompt (compared to PNA) and from some of the difficulty
>>>>>>>>>> of
>>>>>>>>>> navigating mixed content (the same as PNA). Many developers
>>>>>>>>>> understand the
>>>>>>>>>> reasoning behind adding the new permission though, and are
>>>>>>>>>> productively
>>>>>>>>>> engaging on how they can avoid issues.
>>>>>>>>>>
>>>>>>>>>> Other signals: Brave ships a "localhost access" permission (see
>>>>>>>>>> https://brave.com/privacy-updates/27-localhost-permission/)
>>>>>>>>>>
>>>>>>>>>> Ergonomics
>>>>>>>>>>
>>>>>>>>>> N/A
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Activation
>>>>>>>>>>
>>>>>>>>>> A new permission will be shown to users, which may be unexpected.
>>>>>>>>>> If users deny the permission, functionality may break (potentially
>>>>>>>>>> requiring additional support from site owners). Part of our goal for
>>>>>>>>>> having
>>>>>>>>>> a Dev Trial was to give site owners time to adjust their requests
>>>>>>>>>> (especially if they need to use the mixed content exemptions) and to
>>>>>>>>>> potentially adapt their UX flows so the permission requests are less
>>>>>>>>>> surprising to users. We have collected some advice for how sites can
>>>>>>>>>> adapt
>>>>>>>>>> to these new restrictions in our “LNA Adoption Guide
>>>>>>>>>> <https://docs.google.com/document/d/1QQkqehw8umtAgz5z0um7THx-aoU251p705FbIQjDuGs/edit?usp=sharing>
>>>>>>>>>> ”.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Security
>>>>>>>>>>
>>>>>>>>>> Exempting some requests from mixed content checks based on
>>>>>>>>>> declared targetAddressSpace could potentially be used to arbitrarily
>>>>>>>>>> bypass
>>>>>>>>>> mixed content. To avoid this, Chrome verifies that the actual
>>>>>>>>>> resolved
>>>>>>>>>> address space matches what was declared, and blocks the request if
>>>>>>>>>> it does
>>>>>>>>>> not.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> WebView application risks
>>>>>>>>>>
>>>>>>>>>> These restrictions do not apply to WebView (see below).
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Debuggability
>>>>>>>>>>
>>>>>>>>>> When a request would be blocked under LNA, we add a new DevTools
>>>>>>>>>> Issue with details.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Will this feature be supported on all six Blink platforms
>>>>>>>>>> (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?
>>>>>>>>>>
>>>>>>>>>> No
>>>>>>>>>>
>>>>>>>>>> Android WebView currently doesn't support letting apps grant any
>>>>>>>>>> new permission types, so the Local Network Access permission is
>>>>>>>>>> currently
>>>>>>>>>> unconditionally granted in WebView. In parallel to this effort,
>>>>>>>>>> Android is
>>>>>>>>>> adding a Local Network permission which would apply to the app that
>>>>>>>>>> embeds
>>>>>>>>>> the WebView
>>>>>>>>>> https://developer.android.com/privacy-and-security/local-network-permission
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Is this feature fully tested by web-platform-tests
>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>>>>>>>>>> ?
>>>>>>>>>>
>>>>>>>>>> No
>>>>>>>>>>
>>>>>>>>>> We have coverage of core aspects of the feature in WPTs and are
>>>>>>>>>> actively working on building out the test suite
>>>>>>>>>> https://wpt.fyi/results/fetch/local-network-access
>>>>>>>>>> <https://wpt.fyi/results/fetch/local-network-access>. We have
>>>>>>>>>> additional testing coverage in Chromium browser tests, particularly
>>>>>>>>>> for
>>>>>>>>>> areas that are difficult to write WPTs for.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> DevTrial instructions
>>>>>>>>>>
>>>>>>>>>> https://developer.chrome.com/blog/local-network-access
>>>>>>>>>>
>>>>>>>>>> Flag name on about://flags
>>>>>>>>>>
>>>>>>>>>> local-network-access-check
>>>>>>>>>>
>>>>>>>>>> Finch feature name
>>>>>>>>>>
>>>>>>>>>> LocalNetworkAccessChecks
>>>>>>>>>>
>>>>>>>>>> Rollout plan
>>>>>>>>>>
>>>>>>>>>> Will ship enabled for all users
>>>>>>>>>>
>>>>>>>>>> Requires code in //chrome?
>>>>>>>>>>
>>>>>>>>>> True
>>>>>>>>>>
>>>>>>>>>> Tracking bug
>>>>>>>>>>
>>>>>>>>>> https://crbug.com/394009026
>>>>>>>>>>
>>>>>>>>>> Launch bug
>>>>>>>>>>
>>>>>>>>>> https://launch.corp.google.com/launch/4395658
>>>>>>>>>>
>>>>>>>>>> Sample links
>>>>>>>>>>
>>>>>>>>>> https://lna-testing.notyetsecure.com
>>>>>>>>>>
>>>>>>>>>> Estimated milestones
>>>>>>>>>>
>>>>>>>>>> Shipping on desktop
>>>>>>>>>>
>>>>>>>>>> 141
>>>>>>>>>>
>>>>>>>>>> Origin trial desktop first
>>>>>>>>>>
>>>>>>>>>> 141
>>>>>>>>>>
>>>>>>>>>> Origin trial desktop last
>>>>>>>>>>
>>>>>>>>>> 146
>>>>>>>>>>
>>>>>>>>>> DevTrial on desktop
>>>>>>>>>>
>>>>>>>>>> 138
>>>>>>>>>>
>>>>>>>>>> Shipping on Android
>>>>>>>>>>
>>>>>>>>>> 141
>>>>>>>>>>
>>>>>>>>>> Origin trial Android first
>>>>>>>>>>
>>>>>>>>>> 141
>>>>>>>>>>
>>>>>>>>>> Origin trial Android last
>>>>>>>>>>
>>>>>>>>>> 146
>>>>>>>>>>
>>>>>>>>>> DevTrial on Android
>>>>>>>>>>
>>>>>>>>>> 139
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Anticipated spec changes
>>>>>>>>>>
>>>>>>>>>> Open questions about a feature may be a source of future web
>>>>>>>>>> compat or interop issues. Please list open issues (e.g. links to
>>>>>>>>>> known
>>>>>>>>>> github issues in the project for the feature specification) whose
>>>>>>>>>> resolution may introduce web compat/interop risk (e.g., changing to
>>>>>>>>>> naming
>>>>>>>>>> or structure of the API in a non-backward-compatible way).
>>>>>>>>>>
>>>>>>>>>> None
>>>>>>>>>>
>>>>>>>>>> Link to entry on the Chrome Platform Status
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> https://chromestatus.com/feature/5152728072060928?gate=5199213979500544
>>>>>>>>>>
>>>>>>>>>> Links to previous Intent discussions
>>>>>>>>>>
>>>>>>>>>> Intent to Prototype:
>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALMy46SB%2Bv9dnp-wrJ4WH0R4UJmWuutq1st92%3D_zOyhnLJ_vkw%40mail.gmail.com
>>>>>>>>>>
>>>>>>>>>> Intent to Experiment:
>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHEiSH03XUPgcAkVmE25PpvDXMsx%3D16Kgeid_KJ8vRgyvueNuA%40mail.gmail.com
>>>>>>>>>>
>>>>>>>>>> Ready for Developer Testing:
>>>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/D4nqAa3FUN8/m/WFVmJYh0BAAJ
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This intent message was generated by Chrome Platform Status
>>>>>>>>>> <https://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 [email protected].
>>>>>>>
>>>>>>>
>>>>>>> To view this discussion visit
>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8863a050-972e-4d00-9960-b4dc6436b013n%40chromium.org
>>>>>>>
>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8863a050-972e-4d00-9960-b4dc6436b013n%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 [email protected].
>>>>>
>>>>>
>>>>>> To view this discussion visit
>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALMy46SACi%2B3kGz_sQUfYxK9ucSjp0GMzKNyVgPip5mynf4nAg%40mail.gmail.com
>>>>>>
>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALMy46SACi%2B3kGz_sQUfYxK9ucSjp0GMzKNyVgPip5mynf4nAg%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 [email protected].
>>>>
>>>>
>>>>> To view this discussion visit
>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8SK69gpEaZ7GZcvb6nzAmd5sDKR3UzRHvtJ1MNexryxg%40mail.gmail.com
>>>>>
>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8SK69gpEaZ7GZcvb6nzAmd5sDKR3UzRHvtJ1MNexryxg%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 [email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/736fef4e-9a1d-4619-b8ff-499e5cc1ff1bn%40chromium.org.
