In 2025-2026, the WICG drafted and implemented a new browser restriction called "Local Network Access" which impacts the way plugins like QZ Tray work with the browser.

Although the WICG provided an open forum for plugin authors -- such as QZ Industries, LLC -- little effort has been made by the WICG group to offer graceful suppression, manual triggering or detection in a usable form.

Starting on April 7th, 2026, nearly every Chrome browser will roll out with a pop-up that blocks QZ Tray from connecting.

The implementation of Local Network Access (LNA) in Chrome 147 and higher changes how web applications interact with locally installed applications like QZ Tray.

Previously, a website could silently open a WebSocket connection to localhost, however, starting with Chrome 147 (April 2026), modern security policies now treat these connections as a security risk and will prompt the user.

Blocked connections will need to explicitely grant permission for connections to succeed:

• ⚠️ WARNING: Ignoring this pop-up three time is equivalent to clicking "block"!

1. Chrome (and Chromium-based browsers) have been the most aggressive in rolling out LNA restrictions. Start with Chrome 147, Chrome no longer allows "public" websites to silently connect to "private" addresses (like QZ Tray on localhost).
   • Chrome explainer: https://developer.chrome.com/blog/local-network-access
2. Firefox has a similar permission prompt, but with a checkbox to "remember this decision".
   • Firefox explainer: https://support.mozilla.org/en-US/kb/control-personal-device-local-network-permissions-firefox
3. Safari has not made any official announcement however Apple already imposes Local Network restrictions at the OS-level.

Due to lack of flexibility by the WICG, mitigation is challenging.

• Exceptions can ONLY be made at the domain level
• NO viable mechanism to "whitelist" QZ Tray at install time

For ordinary end-devices, please consider adding an explainer message.

// example only
qz.websocket.connect()
.catch(err => {
    if(err.message.indexOf("Unable to establish connection") !== -1) {
        alert(err.message + "\nEnsure your browser has 'Apps on this device' toggled on.");
    }
});

• 💡 NOTE: There are no LNA-specific changes to qz-tray@2.2.6. Any future API changes as they pertain to LNA can be tracked here: #1382.

Although it's technically possible to detect the state of this permission prompt, it's proven a challenging task and the browsers haven't been very sympathetic.

For corporate environments, administrators can bypass these prompts using the LocalNetworkAccessAllowedForUrls (or similar) administrative policy to whitelist your specific domain.

1. Enterprise policy for Chrome: https://chromeenterprise.google/intl/en_ca/policies/local-network-access-allowed-for-urls/
2. Enterprise policy for Firefox: https://mozilla.github.io/policy-templates/#localnetworkaccess (WIP, see here)
3. Safari: Unannounced/unknown. Please reachout to your MDM provider.

Starting with QZ Tray 2.2.6, Company Branded versions can influence these through 'policy' provisions, however due to domain-only values, this feature is limited only to Company Branded builds.

• 💡 NOTE: This feature is available starting with QZ Tray 2.2.6 (April 2026) and all future QZ Tray 2.3.0+ versions. Portal availability will lag slightly behind. Please email support@qz.io for more information.

QZ Industries will continue to monitor the WICG for any mechanism to "whitelist" these connections. Due to initial pushback from the Chromium team, the prospect of any changes in spec is uncertain.

If you have any questions about this please reach out to support@qz.io.

Although this change falls under the WICG umbrella, it's been predominantly spearheaded by one organization: The Google Chrome team. Although I have found interactions with this team to be professional, I feel very strongly that they've NOT been responsible. I've provided use-case for WebSockets after being asked to as an attempt to explain (and for the WICG to understand) the impact this LNA change makes... but the WICG team has provided hardly any useful mitigation at large. Dozens of bug reports, hundreds of messages. By that I mean: Nearly every sane requests to make this rollout developer-friendly has gone dismissed, unanswered, or unresolved and that hurts the very ecosystems that've helped the browser flourish as the gateway to productivity.

Perhaps put best by Chris Edgington WICG/local-network-access/issues/96(comment):

"A remote server in another country that responds to a CORS preflight is trusted without a prompt. A device 10 feet away on the user's own network that responds to CORS preflight + serves a publicly-trusted cert requires a prompt."

QZ Industries, LLC has a philosophy that no matter how big or small a company is, no what a customer's background or reason to use our product -- They deserve to be heard. Here at QZ we're a small, two person company -- yet we read and respond to every single email and we always consider the perspective of our customers and end-users, paid or free. I feel strongly that the WIGC is knowingly dismissing the perspective of their "customers" here and I'm truly sorry that we couldn't do more to ease this transition for ours.

Thanks for trusting in us and our product and for the understanding during this transition.

-Tres Finocchiaro / Owner / Lead Developer