Chrome: Add enterprise policy for LocalNetworkAccessAllowedForUrls

[tresf]

Since Chrome 139 to suppress a pop-up to Chrom(ium) users:
https://chromeenterprise.google/policies/#LocalNetworkAccessAllowedForUrls

• Currently, this only applies to HTTP/HTTPS requests, WS/WSS requests haven't been added to the specification
• NOTE: This supersedes Add Access-Control-Request-Private-Network #1236

This makes most sense for localhost, since any other DNS names would imply that the browser's running elsewhere.

See also: WICG/local-network-access#16

To test:

1. Visit chrome://settings/performance
2. Select "Enable (Blocking)"
   
3. Restart the browser
4. Visit https://demo.qz.io
5. Paste the following code into terminal:

   fetch('http://localhost:8182/json')
    .then(response => response.json())
    .then(data => console.log(data))
    .catch(error => console.error('Error:', error));

Policy Examples

Windows Registry

Software\Policies\Google\Chrome\LocalNetworkAccessAllowedForUrls\1 = http://www.example.com:8080
Software\Policies\Google\Chrome\LocalNetworkAccessAllowedForUrls\2 = [*.]example.edu
Software\Policies\Google\Chrome\LocalNetworkAccessAllowedForUrls\3 = *

macOS Plist

<array>
<string>http://www.example.com:8080</string>
<string>[*.]example.edu</string>
<string>*</string>
</array>

Linux JSON

[
 "http://www.example.com:8080",
 "[*.]example.edu",
 "*"
]

[tresf]

I just realized this won't work, since every website on the internet would need to be added here.

[tresf]

I've blasted our users with the following email:

The WICG (Web Incubator Community Group) has decided to impose additional restrictions on communications between web browsers and local applications (such as QZ Tray) to counter malicious activity.

This change, called "Local Network Access" (LNA), WILL impact all clients running QZ Tray once it is rolled out.

While the WICG has acknowledged our need to whitelist this connection attempt, the rollout is proceeding much faster than we anticipated. This aggressive timeline prevents projects like QZ Tray from implementing better messaging, improved whitelisting, and reliable detection mechanisms, ultimately harming honest software companies (like us) who are trying to comply with these new rules.

Key Impacts & Concerns:

• Pop-up Warnings: All users will soon see a confusing pop-up warning (e.g., "example.com wants to Look for and connect to any device on your local network") upon initial connection, which may prompt them to click BLOCK despite QZ Tray only connecting to itself on wss://localhost:8181.
• Fast Rollout: The WICG's implementation timeline is too aggressive, happening faster than QZ Tray can implement necessary solutions like better client-side messaging and graceful error handling.
• Lack of Control: The WICG has provided no mechanism for fine-grained control at the application level, meaning QZ Tray cannot set up whitelisting preferences in advance for users; though Chrome offers some flag/enterprise policy options they're either too broad to be secure, or too specific to be suitable for us.
• No Detection: There is no official timeline for the promised client-side detection of this pop-up, leaving QZ Tray unable to gracefully handle the change before the browser rollout occurs.

What can be done:

• Power-users, developers and System Administrators can share their concerns directly with the WICG on the LNA issue tracker (github).
• Enterprise Chrome environments can get ahead of this rollout by temporarily disabling the LNA pop-ups or via enterprise whitelisting.
• Firefox users can read-up about their implementation here however enterprise policies seem to be waiting on Chrome first.
• Become familiar with this new pop-up by testing beta versions of your web browser.

As always, please feel free to email support@qz.io with thoughts, questions or concerns (or just reply to this email).

Tres Finocchiaro
Owner, QZ Industries, LLC
tres@qz.io

[Funkatronics]

Thanks for posting that email copy @tresf. I share all of your concerns here - the timeline is really aggressive. Not to mention being right at the end of Q4.

We just posted a formal request to push this timeline back a couple months here.

[tresf]

Thanks for posting that email copy @tresf. I share all of your concerns here - the timeline is really aggressive. Not to mention being right at the end of Q4.

We just posted a formal request to push this timeline back a couple months here.

Thanks for the moral support. Since we run on localhost... in my head I'm considering some really gross workarounds -- such as abusing URI handler to inject a registry entry with the current website -- but this is just more Rube Goldberg hackery (and not-to-mention, we can't reliably suppress the URI popup!).

Perhaps what's most frustrating about this is the lack of the browsers to even try out the apps we've listed... Like, WICG -- just ***ing install an app and try it and thonk "what can we do to improve this". localmess --> widespreadmess™️

[tresf]

(all that said, I've long believed that Chrome would eventually outright kill fetch/ws to local, so I'm happy that SOMETHING exists to allow comms live to see another day)

[tresf]

@Funkatronics curious as to the details of this... Do you mind sharing?

We are actively developing a new version of MWA to comply with the LNA changes

[Funkatronics]

Sure thing. We are extending our protocol to use a remote WebSocket reflector server instead of a local WebSocket connection directly to the wallet (which is now blocked by this change). so instead of connecting to ws://localhost the web app and wallet both connect to wss://reflector.domain.com and that server reflects encrypted payloads between both parties. So this completely removes our dependence on localhost, at the cost of now needing to stand up and maintain backend resources and more technical complexity.

Its super frustrating, and will actually have a massive impact on our ecosystem if we cant time everything right (we cant). Especially the "its all seems fine from our A:B test so we are going to ship it"

[tresf]

at the cost of now needing to stand up and maintain backend resources and more technical complexity.

Oh wow. I suppose you CAN do this because there's some expectation of connectivity? I think Roblox uses a reflector service too because it too expects a valid internet connection.

We may eventually be forced down this rabbit hole, but we'd like to avoid it, our customers really like the fact that our product never NEEDS to talk to the outside world.

"its all seems fine from our A:B test so we are going to ship it"

😢 😆 😢 😭

[tresf]

For the record, this feature -- once implemented -- will only be available to custom builds of QZ Tray (e.g. company branded/whitelabel builds) by exploiting the Chrome Enterprise policies. I'm not sure what this will look like, as it will be part of our advanced provisioning feature and those features will need a way to control cross-browser policies (and worse, policies that Firefox hasn't even established yet!)

We'll start working on this this month. Thanks to @Funkatronics for convincing Chrome to push this out until after the holidays, that gives us some time to develop, document and then add to our portal as well as time to see how Firefox handles this, however this won't help the vast majority of users that receive this pop-up. We still have no sane whitelisting mechanism for the bulk of users and from what I can tell, we won't be getting one anytime soon.

Edit: Chrome admits these policies are likely to change in the future, so expect this to issue to referenced in the future once that happens.