Question Sandboxed Chromium Browser Freeze when Prompted for WebAuthn on Windows 11

[renewably]

Hi all — I've run into a reproducible issue with the Cruel Sister config on Windows 11 25H2 and wanted to share findings in case anyone has hit this or knows a workaround.

**The problem**
Any Chromium browser (tested: Brave, Edge) running under Comodo containment hangs with a black screen whenever a site triggers WebAuthn (passkey/FIDO2 authentication). The hang occurs before any credential UI appears. Killing the browser process recovers it.

**Environment**
- Windows 11 25H2
- Comodo Firewall with CS config (HIPS disabled) 12.3.4.8162
- Browsers: Brave and Edge (both exhibit identical behaviour). Fiefox works fine.
- Same CS config on a Windows 10 machine works fine — WebAuthn functions normally

**What I've tried**
- Run Virtual shortcut (Fully Virtualized) → hangs
- Manual Auto-Containment rule for brave.exe, File rating: Any → Partially Limited → still hangs
- No containment → works perfectly

**Diagnostic findings**
Process Monitor captured the call stack at the point of hang:
```
RegLoadAppKeyW
AppContainerDeriveSidFromMoniker
WebAuthNGetPlatformCredentialList
WebAuthNIsUserVerifyingPlatformAuthenticatorAvailable
```
The hang occurs inside webauthn.dll during platform credential enumeration — before any credential is actually returned or any UI is shown. The same stack appears in both Brave and Edge, ruling out a browser-specific bug.

**Root cause (best current theory)**
Windows 11 25H2 routes WebAuthn through AppContainer-isolated registry hives (loaded via RegLoadAppKeyW) and a COM/RPC channel to the WebAuthn service in svchost.exe. Comodo's containment appears to intercept or block that cross-process COM call at all restriction levels. Since HIPS is disabled in the CS config, I'm not aware of a way to create a granular IPC allow rule. Windows 10 doesn't use this AppContainer path as aggressively, which explains why it works there.

**Question**
Has anyone found a way to allow the WebAuthn IPC through containment without enabling HIPS? I'm aware the two-shortcut workaround (contained for general browsing, uncontained for WebAuthn sites) is the fallback — just wondering if there's a cleaner fix before I go that route or file a Comodo bug report.

 

[Bot]

Hi all — I've run into a reproducible issue with the Cruel Sister config on Windows 11 25H2 and wanted to share findings in case anyone has hit this or knows a workaround.

**The problem**
Any Chromium browser (tested: Brave, Edge) running under Comodo containment hangs with a black screen whenever a site triggers WebAuthn (passkey/FIDO2 authentication). The hang occurs before any credential UI appears. Killing the browser process recovers it.

**Environment**
- Windows 11 25H2
- Comodo Firewall with CS config (HIPS disabled) 12.3.4.8162
- Browsers: Brave and Edge (both exhibit identical behaviour). Fiefox works fine.
- Same CS config on a Windows 10 machine works fine — WebAuthn functions normally

**What I've tried**
- Run Virtual shortcut (Fully Virtualized) → hangs
- Manual Auto-Containment rule for brave.exe, File rating: Any → Partially Limited → still hangs
- No containment → works perfectly

**Diagnostic findings**
Process Monitor captured the call stack at the point of hang:
```
RegLoadAppKeyW
AppContainerDeriveSidFromMoniker
WebAuthNGetPlatformCredentialList
WebAuthNIsUserVerifyingPlatformAuthenticatorAvailable
```
The hang occurs inside webauthn.dll during platform credential enumeration — before any credential is actually returned or any UI is shown. The same stack appears in both Brave and Edge, ruling out a browser-specific bug.

**Root cause (best current theory)**
Windows 11 25H2 routes WebAuthn through AppContainer-isolated registry hives (loaded via RegLoadAppKeyW) and a COM/RPC channel to the WebAuthn service in svchost.exe. Comodo's containment appears to intercept or block that cross-process COM call at all restriction levels. Since HIPS is disabled in the CS config, I'm not aware of a way to create a granular IPC allow rule. Windows 10 doesn't use this AppContainer path as aggressively, which explains why it works there.

**Question**
Has anyone found a way to allow the WebAuthn IPC through containment without enabling HIPS? I'm aware the two-shortcut workaround (contained for general browsing, uncontained for WebAuthn sites) is the fallback — just wondering if there's a cleaner fix before I go that route or file a Comodo bug report.

Your theory is plausible, and the ProcMon stack you captured is exactly the kind of place where “works uncontained / hangs contained” tends to happen: WebAuthn on Windows is not purely in-process; it relies on brokered calls to system components/services, and heavy isolation layers can break that path in ways that look like a deadlock/hang rather than a clean failure.

Why this can happen under Comodo containment

When a contained Chromium process hits WebAuthn (especially “platform” credentials / Windows Hello / passkeys), the browser typically has to cross an IPC boundary to Windows components that are not inside the container. If containment blocks or partially virtualizes any of the following, you can end up stuck inside webauthn.dll waiting on a reply that never arrives:

• COM/RPC activation or marshaling to a broker/service (often hosted in svchost.exe)
• Access to AppContainer-related tokens/SIDs and the corresponding per-app registry hives (your RegLoadAppKeyW / AppContainerDeriveSidFromMoniker hints strongly at this area)
• Access to Windows Hello / identity / credential storage plumbing that is implemented outside the browser process

Firefox working doesn’t necessarily contradict this; its integration path and timing can differ enough that it avoids the specific blocked call pattern you’re seeing.

What you can realistically do without enabling HIPS

With Comodo, truly granular “allow this specific COM/RPC/IPC channel but keep the browser contained” is usually the hard part. With HIPS disabled, you generally lose the only mechanism that can make fine-grained inter-process allowances practical. So a “clean” fix may simply not exist on the policy side.

That said, a few low-risk things are still worth trying before concluding it’s impossible:

1) Test containment levels that change virtualization behavior (not just restriction)</B>

You already tried Fully Virtualized and Partially Limited. If you haven’t yet, also test:

• Limited
• Restricted
• Untrusted

The reason is that some levels change which resources are virtualized vs merely restricted, and WebAuthn can fail under either model depending on what Comodo is intercepting. This is quick to verify and sometimes one level “just works” even when a nearby level doesn’t.

2) Check Comodo logs with maximum verbosity while reproducing</B>

Even if there’s no prompt, Comodo may still log blocked/intercepted actions tied to the hang window.

• Enable/raise logging for containment events (and any “blocked” or “protected object” logging you have available)
• Reproduce the hang, then immediately review events around the timestamp for references to svchost.exe, COM, RPC, or protected registry/LSA/credential objects

If the logs show a consistent blocked target, that becomes actionable for a vendor report (and sometimes for a targeted exclusion, if Comodo offers one in your build).

3) Practical workaround: separate shortcuts / profiles (most reliable)</B>

If the goal is “keep hardened browsing most of the time, but don’t break passkeys,” the two-shortcut approach you mentioned is currently the most dependable and lowest-risk:

• Contained Chromium for general browsing
• Uncontained Chromium (or Firefox) reserved for sites where you need WebAuthn

If you want it slightly cleaner operationally, using a separate browser profile dedicated to WebAuthn (favorites/password manager/passkeys) reduces cross-contamination between “contained daily browsing” and “authentication sessions.”

Best next step: file a Comodo bug report with the right artifacts

Given you can reproduce it across Edge and Brave on Win11 25H2 but not Win10, this is exactly the kind of regression Comodo would need to address in their containment layer (likely an IPC/broker compatibility issue).

Include:

• Windows 11 build number (not just “25H2”), and whether VBS/Core Isolation/Memory Integrity is on
• Comodo version + confirmation that HIPS is disabled
• Exact containment level(s) tested and the result per level
• ProcMon PML filtered to the browser process + timestamp of hang, plus your captured call stack
• Any Comodo log entries at the same timestamp

That gives them enough to reproduce and fix, if it’s fixable without reintroducing HIPS.

Conclusion: without HIPS, there may not be a safe, granular “allow WebAuthn IPC” knob to turn in the CS config, so the cleanest path today is the split-browser (or split-profile) workaround plus a vendor bug report with your ProcMon evidence.