Skip to main content

Handling Chrome's Local Network Access Prompt

When working with locally-hosted environments (such as the tidecloak-dev Docker image), Chromium-based browsers may display a permission prompt during Tide authentication. This behavior was introduced in Chromium version 142 (October 2025) and affects Chrome, Edge, Vivaldi, and other Chromium-based browsers.

Quick Answer

Click Allow — this is a safe, one-time permission request that enables Tide authentication with your local development server. You won't see it again on that browser.

What You'll See​

During sign-in, a dialog will appear stating something like "ork1.tideprotocol.com wants to look for and connect to any device on your local network". You'll have the option to Allow or Block this request.

Chromium LNA warning

This is completely secure. Tide communicates exclusively with your local TideCloak server. It does not scan for, discover, or connect to any other devices on your network.

Understanding This Prompt​

Tide's authentication flow involves a Secure Web Enclave hosted on Tide nodes. When you sign in to a locally-hosted server (for example, http://localhost:8080 or http://127.0.0.1:8080), this enclave must communicate back to your local environment to complete the authentication handshake securely.

Chromium's Local Network Access feature now requires explicit user permission for this type of cross-origin local communication. The browser treats this as a security boundary that needs your approval.

Read more about the official announcement in Google Blog about the New permission prompt for Local Network Access.

Key point​

  • Development-environment only: This prompt only appears in local development scenarios. Production deployments handle this through standard CORS configuration and will not present this prompt
  • One-time prompt: Granting permission once per browser is sufficient for all future sessions
  • Not all browsers affected: Firefox and Safari handle local network requests differently and may not show this prompt

What Happens If You Click Block​

If you accidentally deny the permission, Tide authentication will fail because the Secure Web Enclave cannot complete its communication with your local server.

To restore access:

  1. While on your Tide sign-in page, click the padlock or tune icon in the address bar
  2. Locate the Local network access setting
  3. Change the permission from Block to Allow
  4. Refresh the page and try signing in again

Enterprise and Managed Environments​

Organizations can configure browsers to pre-approve this permission, eliminating the prompt for end users entirely.

Platform-Specific Guidance​

iOS Devices: Chrome on iOS does not currently enforce Local Network Access prompts. No configuration is needed.

Android, macOS, and Windows: Managed devices require policy configuration to pre-grant permissions. See Google's documentation on LNA enterprise policy for details.

Policy Configuration​

Two Chrome policies control this behavior:

Option 1 - Google Workspace Configuration​

For organizations using Google Workspace, browser policies can be deployed through the Admin console:

  1. Navigate to Chrome Browser → Custom Configurations in the Admin console
  2. Select the appropriate organizational unit
  3. Add the following JSON configuration (modify domains as needed):
{
  "LocalNetworkAccessAllowedForUrls": [
    "https://ork[*.].tideprotocol.com",
    "https://[*.]yourdomain.com"
  ]
}
  1. Save your changes
  2. Verify deployment by visiting chrome://policy on a managed browser and clicking Reload policies

For additional guidance, see Chrome policies in Workspace.

Option 2 - MDM Deployment​

Mobile Device Management solutions can push these policies to managed devices across platforms.

Windows (via Intune):

Create a custom device configuration profile:

  1. In Intune, go to Devices → Configuration → Create profile
  2. Select:
    • Platform: Windows 10 and later
    • Profile type: Template
    • Template name: Custom
  3. Add OMA-URI entries with:
    • URI: ./Device/Vendor/MSFT/Registry/HKLM/SOFTWARE/Policies/Google/Chrome/LocalNetworkAccessAllowedForUrls
    • Value: Your allowed URL
    • Create separate numbered entries for multiple URLs
  4. Assign to target groups and test

macOS:

Deploy a configuration profile (.mobileconfig) containing Chrome preferences:

.plist snippet:
<key>LocalNetworkAccessAllowedForUrls</key>
<array>
  <string>https://ork[*.]tideprotocol.com</string>
  <string>https://[*.]yourdomain.com</string>
</array>
<key>LocalNetworkAccessRestrictionsEnabled</key>
<true/>

Android (via Managed App Configuration):

Configure the Chrome app through your MDM's managed app configuration:

  1. In the MDM console, navigate to the app configuration settings for Google Chrome.
  2. Add a new configuration using the following keys and values. The format will be a JSON block similar to the one used for Google Workspace.
{
  "LocalNetworkAccessAllowedForUrls": [
    "https://ork[*.]tideprotocol.com",
    "https://[*.]yourdomain.com"
  ],
  "LocalNetworkAccessRestrictionsEnabled": true
}

Learn more about the Local Network Access setting.

Verifying Policy Deployment​

  1. Open Chrome on a managed device
  2. Navigate to chrome://policy and confirm LocalNetworkAccessAllowedForUrls includes your ORK URLs
  3. Optionally enable the flag at chrome://flags → "Local Network Access Checks" for testing
  4. Attempt a Tide sign-in to confirm the prompt no longer appears

Frequently Asked Questions​

Q: Does allowing this permission create security or privacy risks?

A: No. Tide's local network communication is strictly limited to the server handling your sign-in request (your TideCloak instance). No other devices or services on your network are accessed or scanned.

Q: How often will this prompt appear?

A: Once per browser. After granting permission, subsequent sign-ins proceed without interruption.

Q: Does this affect mobile browsers?

A: Android users on managed devices can have the permission pre-configured. Unmanaged Android devices will see the prompt once. iOS users are unaffected as Chrome on iOS doesn't enforce this restriction.

Q: Why doesn't this happen on production sites?

A: Production TideCloak deployments use publicly-routable addresses with proper CORS configuration, which doesn't trigger the Local Network Access check. The prompt specifically targets scenarios where external origins attempt to reach local/private IP addresses.