Production Office Add-ins Cannot Connect to Desktop Applications in Chrome 142+ - Missing local-network-access Permissions Policy

[mc-alt]

Production Office Add-ins Cannot Connect to Desktop Applications in Chrome 142+ - Missing local-network-access Permissions Policy

Provide required information needed to triage your issue

Your Environment

• Platform: Office on the web
• Host: Word, Excel, PowerPoint (all affected)
• Office version number: Latest (Office Online)
• Operating System: Windows 10, macOS 14+
• Browser: Chrome 142.0.0.0 and later (with Local Network Access enforcement)

Expected behavior

Based on Chrome's Local Network Access (LNA) specification, when a production HTTPS add-in attempts to connect to a desktop application on localhost:

1. Add-in uses fetch() with targetAddressSpace: 'loopback' to connect to localhost
2. Chrome prompts user to grant Local Network Access permission
3. User reviews the prompt and grants permission
4. Add-in successfully connects to desktop application
5. Bidirectional communication works between Office Online and desktop app

Current behavior

When a production HTTPS add-in attempts to connect to localhost:

1. Add-in makes request with correct targetAddressSpace: 'loopback' ✅
2. Chrome immediately blocks the request without showing permission prompt ❌
3. Console error: TypeError: Failed to fetch
4. CORS policy error: Permission was denied for this request to access the 'unknown' address space
5. No way for user to grant permission

Root cause: Office Online embeds add-ins in iframes without setting the local-network-access Permissions Policy. Without this policy, Chrome's security model prevents the permission prompt from appearing.

Feature detection confirms:

document.featurePolicy.allowsFeature('local-network-access')  // returns false

Steps to reproduce

1. Install/update Chrome to version 142 or later
2. Navigate to Word Online, Excel Online, or PowerPoint Online
3. Load a production add-in that connects to a desktop application on localhost
   • Example: AppNameRedacted Office Add-in connecting to AppNameRedacted Desktop on http://localhost:4764
4. Observe that all fetch() requests to localhost fail with CORS error
5. Note: No permission prompt appears for Local Network Access
6. Verify: Open console and run document.featurePolicy.allowsFeature('local-network-access') → returns false

Link to live example(s)

1. Test in Office Online: Load any add-in from AppSource that requires localhost connectivity in Chrome 142+
2. Any production add-in with hybrid web+desktop architecture will exhibit this behavior

Provide additional details

Why This Is a Separate Issue

This issue is distinct from #6174 which addresses development/sideloading scenarios. This issue affects:

• Production add-ins hosted on HTTPS domains (not development servers)
• Legitimate use cases where add-ins bridge Office Online with desktop software
• End users (not developers) who cannot modify browser settings

Technical Details

What our add-in does correctly:

• ✅ Hosted on HTTPS with valid SSL certificate (e.g. https://appredacted.com)
• ✅ Uses correct targetAddressSpace: 'loopback' in fetch options
• ✅ Desktop app returns proper CORS headers including Access-Control-Allow-Private-Network: true
• ✅ Implements proper LNA detection and error handling
• ✅ Works perfectly in Desktop Office (Windows/Mac apps)

What Office Online needs to do:

Add the Permissions Policy to add-in iframes:

<iframe 
  src="https://appredacted.com/addin/taskpane.html" 
  allow="local-network-access"
  ...>
</iframe>

Or via HTTP header:

Permissions-Policy: local-network-access=(self "https://appredacted.com")

Feature detection results from our add-in:

{
  isIframe: true,
  hasPermissionsPolicy: false,        // ❌ Office Online does not set this
  canRequestPermission: false,         // ❌ Cannot prompt without policy
  chromeVersion: 142,
  isLNAEnforced: true
}

Context

Our add-in (AppNameRedacted) provides advanced document processing by:

1. User works with documents in Office Online
2. Add-in communicates with desktop software for specialized processing features
3. Results displayed back in Office Online

This hybrid architecture is common for add-ins that require:

• Local file system access
• Hardware integration (scanners, printers, security devices)
• Enterprise on-premises security requirements
• Advanced processing capabilities
• Integration with existing desktop workflows

Impact:

• ❌ Broken: Office Online + Chrome 142+ (blocks all production users on latest Chrome)
• ✅ Working: Desktop Office (Windows/Mac apps) - full functionality
• ⚠️ Temporary: Edge/Firefox - work until they adopt LNA

No viable workarounds exist:

• Cannot ask production users to disable Chrome security flags
• Cannot force users to use Desktop Office (defeats Office Online's purpose)
• HTTPS on localhost requires complex certificate management
• Moving all logic to cloud is often impossible (local files, hardware, security requirements)

Useful logs

• Console errors
• Screenshots
• Test file (not applicable - affects all documents)

Console Errors (Click to expand)

Unrecognized feature: 'private-network-access'.

[LNA] Context initialized: {
  isIframe: true,
  hasPermissionsPolicy: false,
  canRequestPermission: false,
  chromeVersion: 142,
  isLNAEnforced: true
}

[LNA] Guidance: {
  canConnect: false,
  title: 'Unable to Connect to Desktop',
  message: 'This add-in requires connection to your local desktop application...',
  actionable: false
}

[PNA DEBUG] Running in iframe
[PNA DEBUG] Private Network Access feature policy allowed: false
[PNA DEBUG] Feature policy available: true
[PNA DEBUG] Fetch options: {
  method: 'GET',
  mode: 'cors',
  credentials: 'omit',
  targetAddressSpace: 'loopback'
}
[PNA DEBUG] Target URL: http://localhost:4764/v2/health

taskpane.html:1 Access to fetch at 'http://localhost:4764/v2/health' from origin 
'https://appredacted.com' has been blocked by CORS policy: Permission was denied 
for this request to access the `unknown` address space.

[AppNameRedacted API] Health check failed for http://localhost:4764: TypeError: Failed to fetch
    at Oe.checkHealth (taskpane.js:250:5411)
    at Oe.discoverBestInstance (taskpane.js:250:4254)
    at Oe._performDiscovery (taskpane.js:250:6211)

Comparison: Desktop Office vs Office Online (Click to expand)

Environment	Status	Reason
Desktop Office (Windows/Mac)	✅ Working	Add-ins run outside iframe restrictions
Office Online + Chrome 142+	❌ Blocked	Missing local-network-access policy
Office Online + Edge	⚠️ Working (temporary)	LNA not enforced yet
Office Online + Firefox	⚠️ Working (temporary)	LNA not implemented yet

Request

Please add local-network-access to the Permissions Policy for Office add-in iframes in Office Online.

This will:

• ✅ Allow Chrome to show the LNA permission prompt
• ✅ Let users make informed consent decisions
• ✅ Maintain Chrome's security model
• ✅ Enable legitimate hybrid web+desktop add-in architectures

References

• Chrome's Local Network Access adoption guide
• WICG Private Network Access spec
• Chrome Platform Status: Private Network Access
• Permissions Policy specification

---

Thank you for taking the time to review this issue. 🙏

[github-actions]

This issue was automatically labeled as a regression based on dual-LLM analysis of the issue content and comments.

Reason: The issue described is a regression because it involves functionality that previously worked and is now broken due to a change in Chrome's handling of local network access permissions. The add-ins were able to connect to desktop applications on localhost before Chrome version 142, but the introduction of the 'local-network-access' permissions policy requirement in Chrome 142+ has caused this functionality to break. The issue is not due to a change in the add-ins themselves or Office Online, but rather a change in the browser's security model, which now requires explicit permissions that were not previously necessary. This indicates a regression in the context of the current environment and browser version.

[github-actions]

Here are some similar issues that might help you. Please check if they can solve your problem.

• Local add-in server resources blocked by CORS / Local Network Access in latest Chrome #6174

---

Possible solution (Extracted from existing issue, might be incorrect; please verify carefully)

Hi, thank you for reporting this. I filed a ticket (#696686877) to the team to investigate. We will update here if there is any progress.

Reference:

• Local add-in server resources blocked by CORS / Local Network Access in latest Chrome #6174 (comment)

Powered by issue-sentinel

[AmandaHan123]

Hi @mc-alt , thank you for reporting this. Could you please see if this is duplicate with #6174?

[sagarkhatri0605]

Hi @AmandaHan123 ,
Hope you’re doing well. We’re also encountering the same issue — has there been any update or progress on this?

Thanks!

[mc-alt]

Hi @mc-alt , thank you for reporting this. Could you please see if this is duplicate with #6174?

It could be the same underlying issue. The other ticket seemed to be about dev flow/side loading when I reviewed it. But perhaps the same missing iframe attribute could be responsible for both presentations

[AmandaHan123]

Hi @sagarkhatri0605 and @mc-alt , the fix pull request is pending for merge. I will update you here with the estimate deployment time after it get merged.