Download Contact Sales
Download Contact Sales
User Guide · Security

Chrome 147+ Local Network Access & WebSockets

Chrome 147 (and other Chromium-based browsers) extended Local Network Access restrictions to WebSocket connections. This affects MCS browser-based tests that talk to the BCS. This page explains what changed, who is affected, and what to do about it.

Overview

Starting in Chrome 147 (current stable, April 2026), browsers based on Chromium enforce Local Network Access (LNA) restrictions on WebSocket connections in addition to the existing fetch and XHR restrictions introduced in Chrome 142 (October 2025).

When a page loaded from a public origin (for example https://mcs.example.com) opens a WebSocket to a loopback address (localhost, 127.0.0.1, ::1) or a private IP, the browser now requires explicit user permission via a prompt before the connection is allowed.

This change affects Chrome, Edge, Brave, Opera and other Chromium-based browsers. Firefox and Safari do not currently enforce these restrictions.

In short: if any of your MCS test pages connect from a public-origin URL to the BCS running on the user's machine via WebSocket, end users will see a permission prompt the first time, and the test will only work if they accept it.

Who is affected

You are affected if all of the following are true for any test you publish:

  • The test page is served from a public origin (any HTTPS or HTTP host that is not itself localhost, 127.0.0.1 or a private IP).
  • The test page opens a WebSocket (ws:// or wss://) to a hostname that resolves to a loopback or private address — typically the BCS running on the end user's machine, or a locally hosted satellite.
  • End users access the test in Chrome 147+ or another Chromium-based browser at an equivalent version.

You are not affected if the test page is served from http://localhost, http://127.0.0.1, or from the same private network as the destination — same-address-space requests are exempt.

Important: using a public DNS name such as bcs.visualware.com that resolves to 127.0.0.1 does not bypass the check. LNA classifies based on the resolved IP, not the hostname.

HTTPS is required

The LNA permission prompt is only shown from a secure context. If your MCS test page is served over plain HTTP from a public origin, the WebSocket call to a local address will fail silently — the browser will neither prompt the user nor allow recovery.

Any MCS deployment that publishes browser-based tests externally must serve those test pages over HTTPS for them to have any chance of working in Chrome 147+. See Enable HTTPS for instructions.

What end users will see

The first time an MCS test attempts to open a WebSocket to the BCS, Chrome will display a permission prompt similar to:

"example.com wants to connect to devices on your local network."

Users must click Allow for the test to proceed. The decision is remembered per-origin. If the user clicks Block, all subsequent local-network requests from that origin will fail until they manually re-enable the permission via the lock icon in the address bar (Site settings → Local Network, or on Chrome 145+, Apps on device).

Options for administrators

1. Serve test pages over HTTPS

This is the minimum requirement. Without HTTPS the prompt is never shown and the test will fail without explanation.

2. Inform users to expect the prompt

Add a notice to your test landing pages explaining that the browser will ask permission to access the BCS, and that users should click Allow. A short instruction screen prior to the test can dramatically reduce support tickets.

3. Enterprise policy (managed devices)

Where your end users are on managed Chrome or Edge installations, browser administrators can pre-grant LNA permission for your MCS origin so users do not see a prompt at all:

  • Chrome: deploy the LocalNetworkAccessAllowedForUrls policy listing your MCS origin (e.g. https://mcs.example.com).
  • Microsoft Edge: deploy the equivalent LocalNetworkAccessAllowedForUrls policy.

This is the recommended approach for enterprise deployments where you control the browser fleet.

4. Detect and guide users in the test page

If you build custom MCS test UIs, you can use the Permissions API to detect whether LNA permission has already been denied and present clearer recovery instructions to the user before the WebSocket fails.

5. Avoid public-origin → loopback where possible

For deployments where users access MCS from inside the same private network as the BCS, ensure the test page is served from a same-address-space URL (a private IP or hostname resolving to one). Same-address-space connections are not subject to LNA.

Browsers and scenarios not affected

  • Firefox and Safari do not currently enforce LNA. Tests will work without a prompt.
  • Test pages served from http://localhost, http://127.0.0.1, or any private-IP origin are unaffected when contacting the same address space.
  • WebSocket connections to public, internet-routable hosts are unaffected.
  • MCS tests that do not contact the BCS (pure browser-only HTML5 tests against the MCS server) are unaffected.

Troubleshooting checklist

  1. Confirm the browser is Chromium-based (Chrome, Edge, Brave, Opera) at version 147 or later.
  2. Confirm the test page is served over HTTPS from a public origin. If it is HTTP, switch to HTTPS first.
  3. In the address bar, click the lock icon → Site settings. Check the Local Network (or Apps on device) entry — ensure it is set to Allow for your origin.
  4. If managed, confirm the LocalNetworkAccessAllowedForUrls policy includes your MCS origin.
  5. Verify the BCS is actually running and listening on the expected port.

References