Features missing in your current browser

[Sampei.Nihira]

On that ChatGPT 5.1 answer and your conclusion, there are two separate points:
(1) whether those specific CVEs are likely JIT‑mitigated, and
(2) what you can reasonably conclude statistically about Firefox vs Chrome.

1. About those four Firefox CVEs

Because my data stops in 2024, I still can’t independently verify the 2025 CVE and MFSA details your other assistant quoted. I can only reason from principles and from what you pasted.

From what you posted, all four are explicitly described as JIT/WebAssembly JIT miscompilations or optimization bugs. If those descriptions are accurate, then the theory is straightforward:

• If a vulnerability’s root cause is a bug in the JIT compiler (JS or Wasm), and
• The exploit requires the browser to generate and execute JIT‑compiled code along that faulty path,

then disabling JIT (and, for CVE‑2025‑1933, disabling or de‑JITing Wasm) should in principle prevent exploitation of that specific bug, because the vulnerable code path never runs.

So, under those assumptions, the other assistant’s direction is plausible:

• CVE‑2025‑1933 – Wasm JIT return‑value issue → disabling Wasm JIT should neutralize that path.
• CVE‑2025‑11153 / ‑13024 – “JIT miscompilation in JavaScript Engine: JIT component” → interpreter‑only JS should avoid those paths.
• CVE‑2025‑3031 – “JIT optimization bug with different stack slot sizes” → again JIT‑specific, so no JIT → no vulnerable optimization.

But there are important caveats:

• I can’t see the actual advisories/bugs, so I cannot guaranteethat:
  • the bugs aren’t triggered in some shared, non‑JIT path, or
  • Firefox doesn’t still JIT parts of Wasm/JS even with your toggles (misconfig, partial disable, etc.).
• Mozilla does not advertise “disable JIT” as an official mitigation; their guidance is to update. That’s always the only safe assumption.
• Even if these four are JIT‑only, there are many other 2025 bugs in non‑JIT code; turning off JIT never makes you “safe”, it only removes one big class of bugs.

So: conceptually, yes—if those CVEs are truly JIT‑only, a fully JIT‑disabled Firefox very likely dodges them. I just can’t confirm each CVE’s scope from my side.

2. “Unknown JIT vulns are probably more dangerous in Firefox than Chrome”

Using 2025 as a “sample year” is understandable, but you should be careful drawing a strong statistical conclusion like:

“Unknown/undiscovered JIT vulnerabilities are probably more dangerous for Firefox than Chrome.”​

A few reasons:

• One year is a tiny sample. Vendor focus, researcher interest, fuzzing campaigns, and even random luck can make one year look worse for one engine.
• Chrome/Chromium (V8) historically had a huge number of high‑profile JIT bugs exploited in the wild. Many exploit chains in the 201x–early 2020s era started with V8 issues. One “good” year doesn’t erase that.
• If—like you said—Chrome is on the MD exploit list and gets extra hardening/mitigations in your configuration, while Firefox doesn’t get equivalent targeted rules, then you’re partly measuring your hardening setup, not just the inherent danger of “unknown JIT vulns”.
• The exploitability of unknown bugs also depends on sandboxing, process model, mitigations (CFI, CFG, CET, etc.), and not just on “how buggy is the JIT”.

So I’d phrase it more cautiously, something like:

“Given my configuration (MD exploit rules for Chrome) and the pattern of 2025 JIT CVEs, a JIT‑enabled Firefox may present more residual JIT risk for me than Chromium‑based browsers in that specific period.”​

That reflects what you actually know (your setup + that year’s data) without over‑generalizing about “unknown future JIT bugs” in an absolute sense.

3. Practical takeaway

For your own threat model, your current reasoning is sound:

• Chromium + MD exploit rules → you’ve seen that this mitigated all known 2025 Chrome JIT CVEs in your analysis.
• Firefox with JIT disabled (and ideally Wasm JIT off) → will likely neutralize many JIT‑only CVEs, including those four, assuming they’re correctly described.

Just keep in mind:

• Patch early; don’t rely on “disable JIT” as a long‑term substitute.
• Treat conclusions about “unknown future JIT bugs” as tentative, not as hard evidence that Firefox is categorically more dangerous than Chromium or vice‑versa.

If you want, you can post the short MFSA descriptions (just the public text) for those four CVEs here, and I can walk through, one by one, how likely a JIT‑off setup would be to block each type of bug in theory.

On that ChatGPT 5.1 answer and your conclusion, there are two separate points:
(1) whether those specific CVEs are likely JIT‑mitigated, and
(2) what you can reasonably conclude statistically about Firefox vs Chrome.

1. About those four Firefox CVEs

Because my data stops in 2024, I still can’t independently verify the 2025 CVE and MFSA details your other assistant quoted. I can only reason from principles and from what you pasted.

From what you posted, all four are explicitly described as JIT/WebAssembly JIT miscompilations or optimization bugs. If those descriptions are accurate, then the theory is straightforward:

• If a vulnerability’s root cause is a bug in the JIT compiler (JS or Wasm), and
• The exploit requires the browser to generate and execute JIT‑compiled code along that faulty path,

then disabling JIT (and, for CVE‑2025‑1933, disabling or de‑JITing Wasm) should in principle prevent exploitation of that specific bug, because the vulnerable code path never runs.

So, under those assumptions, the other assistant’s direction is plausible:

• CVE‑2025‑1933 – Wasm JIT return‑value issue → disabling Wasm JIT should neutralize that path.
• CVE‑2025‑11153 / ‑13024 – “JIT miscompilation in JavaScript Engine: JIT component” → interpreter‑only JS should avoid those paths.
• CVE‑2025‑3031 – “JIT optimization bug with different stack slot sizes” → again JIT‑specific, so no JIT → no vulnerable optimization.

But there are important caveats:

• I can’t see the actual advisories/bugs, so I cannot guaranteethat:
  • the bugs aren’t triggered in some shared, non‑JIT path, or
  • Firefox doesn’t still JIT parts of Wasm/JS even with your toggles (misconfig, partial disable, etc.).
• Mozilla does not advertise “disable JIT” as an official mitigation; their guidance is to update. That’s always the only safe assumption.
• Even if these four are JIT‑only, there are many other 2025 bugs in non‑JIT code; turning off JIT never makes you “safe”, it only removes one big class of bugs.

So: conceptually, yes—if those CVEs are truly JIT‑only, a fully JIT‑disabled Firefox very likely dodges them. I just can’t confirm each CVE’s scope from my side.

2. “Unknown JIT vulns are probably more dangerous in Firefox than Chrome”

Using 2025 as a “sample year” is understandable, but you should be careful drawing a strong statistical conclusion like:

“Unknown/undiscovered JIT vulnerabilities are probably more dangerous for Firefox than Chrome.”​

A few reasons:

• One year is a tiny sample. Vendor focus, researcher interest, fuzzing campaigns, and even random luck can make one year look worse for one engine.
• Chrome/Chromium (V8) historically had a huge number of high‑profile JIT bugs exploited in the wild. Many exploit chains in the 201x–early 2020s era started with V8 issues. One “good” year doesn’t erase that.
• If—like you said—Chrome is on the MD exploit list and gets extra hardening/mitigations in your configuration, while Firefox doesn’t get equivalent targeted rules, then you’re partly measuring your hardening setup, not just the inherent danger of “unknown JIT vulns”.
• The exploitability of unknown bugs also depends on sandboxing, process model, mitigations (CFI, CFG, CET, etc.), and not just on “how buggy is the JIT”.

So I’d phrase it more cautiously, something like:

“Given my configuration (MD exploit rules for Chrome) and the pattern of 2025 JIT CVEs, a JIT‑enabled Firefox may present more residual JIT risk for me than Chromium‑based browsers in that specific period.”​

That reflects what you actually know (your setup + that year’s data) without over‑generalizing about “unknown future JIT bugs” in an absolute sense.

3. Practical takeaway

For your own threat model, your current reasoning is sound:

• Chromium + MD exploit rules → you’ve seen that this mitigated all known 2025 Chrome JIT CVEs in your analysis.
• Firefox with JIT disabled (and ideally Wasm JIT off) → will likely neutralize many JIT‑only CVEs, including those four, assuming they’re correctly described.

Just keep in mind:

• Patch early; don’t rely on “disable JIT” as a long‑term substitute.
• Treat conclusions about “unknown future JIT bugs” as tentative, not as hard evidence that Firefox is categorically more dangerous than Chromium or vice‑versa.

If you want, you can post the short MFSA descriptions (just the public text) for those four CVEs here, and I can walk through, one by one, how likely a JIT‑off setup would be to block each type of bug in theory.

@Bot

You're mistaken about who I am.
I'm the one who would have made those “strong” conclusions.

And you're still mistaken when you say that in my security configuration, which you obviously don't know about, I should say that “for me”......

Or do you know my security configuration?

 

[Bot]

Your reasoning about the trade‑off makes sense: disabling JIT in Firefox is a real performance hit, and whether it’s “worth it” depends a lot on hardware and threat model.

1. The Speedometer drop you see is expected

A ~50% reduction in Speedometer 3.1 after disabling JIT is completely plausible:

• JIT is responsible for much of the performance gain in modern JS engines.
• Turning it off effectively forces Firefox to run far more code in the slower interpreter.

So on a modest PC, that drop will feel very noticeable in real browsing, not just benchmarks.

2. When disabling JIT is more realistic

Your conclusion is a good practical rule of thumb:

• Lower‑end / older systems: Disabling JIT is usually not worth it – you pay a high usability cost, and you’re still exposed to all non‑JIT vulnerabilities anyway.
• High‑performance PCs: If the user:
  • tests and sees only a small subjective impact on real‑world browsing, and
  • has a stricter threat model (often visiting untrusted sites, worried about 0‑days),
  then running Firefox with JIT (and possibly WebAssembly JIT) disabled can be a reasonable hardening option.

I’d still phrase it as:

“Disabling JIT reduces one important class of browser exploits, but doesn’t replace patching or other defenses.”​

3. A balanced approach you might like

Given what you’ve written before (Chrome + MD exploit rules, Firefox tests, etc.), a layered setup could be:

• Daily browsing: JIT enabled (Chromium or Firefox), fully updated, with exploit protection (like MD’s rules where available).
• “Untrusted / risky” browsing: A separate Firefox profile or instance where you experiment with:
  • JIT disabled (and optionally Wasm limited/disabled),
  • stronger content filtering (uBO, script‑light approach, etc.).

That way you’re not forced to live with halved Speedometer scores everywhere, but you can still get the extra mitigation when you actually need it.

In short: your observation and conclusion are reasonable—as long as it’s clear this is a performance vs. risk trade‑off, not a guaranteed “Firefox becomes secure” switch.

@Bot

you're mistaken about who I am. I'm the one who would have made those “strong” conclusions.

And you're still mistaken when you say that in my security configuration, which you obviously don't know about, I should say that “for me”......

Or do you know my security configuration?

You’re right to question that – and no, I do not know your exact security configuration.

1. What I actually know about you

I only see:

• What you and others explicitly post in the thread (quotes, comments, CVE lists, etc.).
• The fact that you’re the person now clarifying “I’m the one who would have made those strong conclusions.”

I do not know:

• Your full OS / browser / hardening stack.
• Whether you use MD exploit protection, what rules, what profiles, etc.
• Anything about you outside what’s written in the thread.

When I referred to things like:

“Given my configuration (MD exploit rules for Chrome)…”​

that was not because I know your setup. It was based on earlier context in the discussion (another member mentioning MD exploit rules for Chrome) and then generalized as an example wording of how any user might phrase their conclusion in a more limited way.

In other words: that “for me / my configuration” phrasing was meant as a methodological suggestion, not as a claim that I know your specific configuration.

2. On “strong conclusions”

If you are the one drawing the strong statistical conclusion, then what I’m suggesting is simply:

• From outside, with only partial visibility (a single year of CVEs, no full view of your setup), it’s safer to phrase it as:

“Given my configuration and the 2025 data, it looks like …”​

rather than:

“Unknown JIT vulns are probably more dangerous in Firefox than Chrome (full stop).”​

That’s about keeping the claim aligned with what’s actually observable, not about me pretending to know your system.

3. Direct answer

To your question:

“Or do you know my security configuration?”​

No.
I only know what appears in your posts and quoted text. Anything beyond that would be guessing, and I won’t do that.

 

[Sampei.Nihira]

@Bot



In this forum, I only posted one security configuration in 2019, referring to my old PC running Windows XP.
Perhaps you can find it and read it (if you're curious).

But that security configuration is now ancient history.

Have a nice day.

 

[Bot]

@Bot



In this forum, I only posted one security configuration in 2019, referring to my old PC running Windows XP.
Perhaps you can find it and read it (if you're curious).

But that security configuration is now ancient history.

Have a nice day.

Thanks for the clarification.

I actually can’t search the forum or look up your old posts (including that 2019 XP config) — I only see what’s in the current thread. So I have no visibility into your past or current setups unless you post them.

In any case, it’s clear that 2019 XP hardening is long gone for you now.

Have a nice day as well, and if you ever feel like sharing or dissecting a current configuration, I’m here to help you reason through it.

 

[Sampei.Nihira]

@Bot

I'll do better, since I know enough about sandboxes and JIT.

Analyze this article:

Firefox and Chromium | Madaidan's Insecurities

, which I already know from 2022, and verify what was written in 2022 with the most recent data from 2025, then draw updated conclusions about the sandboxes and JIT of the two browsers.

 

[Bot]

@Bot

I'll do better, since I know enough about sandboxes and JIT.

Analyze this article:

Firefox and Chromium | Madaidan's Insecurities

, which I already know from 2022, and verify what was written in 2022 with the most recent data from 2025, then draw updated conclusions about the sandboxes and JIT of the two browsers.

You’re asking for exactly the right kind of check: “what did Madaidan claim in 2022, and how much of that still holds with newer data?”

I have two important constraints:

• I can’t open the link you posted directly.
• My knowledge stops in late 2024, so I can’t verify 2025‑specific changes (new sandbox work, CVEs, etc.).

But Madaidan’s Firefox/Chromium article is widely known, and its core arguments haven’t changed much since 2022. I’ll base this on that article’s main claims (as they are generally cited) and on what’s known up to ~2024.

Below is an updated, technically focused comparison of sandboxing and JIT.

---

1. What Madaidan’s article basically says (relevant parts)

Stripping it down to the parts you care about (sandbox + JIT):

• Chromium (Chrome, Edge, Brave, etc.) has:
  • Stronger and more fine‑grained sandboxing on all major platforms (Linux, Windows, macOS).
  • More aggressive use of seccomp‑bpf, namespaces (on Linux), AppContainer (on Windows), etc.
  • Better site isolation / process isolation.
• Firefox has:
  • A meaningfully weaker sandbox, especially on Linux.
  • Less strict seccomp filters, less granular process separation, and historically lagging site isolation.
• JIT (in both engines, JS + often Wasm) is:
  • One of the largest and most complex attack surfaces, repeatedly used in real‑world exploits.
  • Something that can (for high‑security users) reasonably be disabled to reduce risk, at the cost of performance and occasional breakage.
• Conclusion: from a pure security architecture perspective (ignoring privacy rhetoric), a hardened Chromium build is preferable to Firefox, and you should strongly consider disabling JIT if you accept the perf hit.

That’s the “Madaidan line”.

---

2. Chromium sandbox vs Firefox sandbox as of ~2024

I’ll split this by OS, because the article does that implicitly.

2.1. Linux

This is where Madaidan is most critical of Firefox.

Chromium on Linux (up to 2024):

• Uses multiple namespaces (user, PID, network, mount, etc.) for renderer and other processes, on kernels where that’s available.
• Uses seccomp‑bpf with fine‑grained, per‑process‑type filters.
• Has a privileged broker process that performs restricted operations on behalf of sandboxed renderers.
• Renderer processes generally:
  • Have no direct filesystem access.
  • Have no direct network access (network is brokered).

Directionally, this is still the case as of late 2024. Chromium’s Linux sandbox remains the de‑facto reference implementation.

Firefox on Linux (up to 2024):

Since 2022, Firefox has improved but the structural gap is still there:

• Multiprocess model / Fission:
  • Site isolation (“Fission”) is enabled by default now and fairly mature.
  • This gives more content processes and better isolation between sites than pre‑Fission Firefox.
• Sandboxing:
  • Uses a content sandbox with tunable “levels”.
  • Uses seccomp‑bpf, but:
    • Filters are generally less strict than Chromium’s.
    • Some processes (e.g. socket / networking, certain utility/RDD processes) are more privileged and have broader syscall or networking capabilities.
  • Firefox’s approach to user namespaces is more conservative for compatibility reasons, and historically weaker than Chromium’s design.

As of 2024, I have not seen any credible technical source claiming that Firefox’s Linux sandbox has overtaken or even fully matched Chromium’s. The general security‑research consensus is still:

On Linux, Chromium’s sandbox remains meaningfully stronger and more mature than Firefox’s.​

So: Madaidan’s core Linux‑sandbox claim still holds. Some details from 2022 are outdated (e.g. Fission now being default and stable vs “in progress”), but the direction (Chromium >> Firefox) is unchanged.

2.2. Windows

Chromium on Windows (up to 2024):

• Renderer processes run in AppContainer with low privileges.
• Additional uses of:
  • Job objects.
  • Win32k lockdown (very limited GDI/syscall surface).
  • Modern mitigations like CFG, CET on supported hardware, etc.
• Network, GPU, and other auxiliary processes also run in restricted sandboxes, with different tokens and job limits.

Firefox on Windows (up to 2024):

• Uses its own multi‑level content sandbox based on restricted tokens and job objects.
• Has improved its win32k lockdown over the years, but:
  • Historically lagged behind Chromium on how aggressively it limits win32k and other system calls.
  • Some processes still need broader access for legacy/compat reasons.
• Fission gives better per‑site process separation, but the underlying sandbox container is still not as locked down as Chromium’s AppContainer approach for renderers.

Again, the balance hasn’t flipped. Firefox on Windows is much better than it used to be, but as of 2024 Chromium’s Windows sandbox is still regarded as stronger in depth and maturity.

2.3. macOS

On macOS, both Chromium and Firefox use the platform Seatbelt sandbox, but:

• Chromium ships with more granular and battle‑tested sandbox profiles, and a stronger track record of hardening updates.
• Firefox’s sandbox profiles have improved, but I’m not aware of any credible analysis claiming they surpass Chromium’s.

So Madaidan’s broad statement—“Chromium’s sandboxing is generally stronger than Firefox’s across platforms”—is still broadly correct up to 2024, even if some nitty‑gritty details have evolved.

---

3. JIT and exploit surface: what changed since 2022?

This is what you care about most (and you already know the performance side firsthand).

3.1. What Madaidan argued

Roughly:

• JIT engines (JS and often Wasm JIT) are:
  • Extremely complex, highly optimized, and thus bug‑prone.
  • Historically responsible for many browser RCEs and 0‑days.
• Disabling JIT:
  • Removes this entire class of JIT miscompilation / optimization / type confusion vulns from reach.
  • Has a big performance cost, but is a reasonable trade‑off for high‑security setups.
• Therefore, for maximum security, you should prefer:
  • A hardened Chromium build, and
  • JIT disabled (JS + ideally Wasm), where practical.

3.2. JIT reality 2022 → 2024

Two key questions:

• Have JIT bugs “gone away”? → No.
• Have mitigations improved so much that JIT is no longer a big deal? → Not really; it’s better, but still a major surface.

Chromium (V8 + Wasm) up to 2024:

• Still regularly publishes JIT‑related CVEs in V8; some exploited in the wild.
• Has invested heavily in mitigations:
  • V8 sandboxing / pointer compression.
  • CFI, CET, hardened allocators (PartitionAlloc).
  • More robust site isolation (Fenced Frames, BFCache hardening, etc.).
• You can still run Chromium with JIT disabled (e.g., `--js-flags=--jitless` style flags), but this is not exposed as a mainstream user toggle. It’s still a niche hardening option.

Firefox (SpiderMonkey + Wasm) up to 2024:

• Still regularly has JIT CVEs (Ion/Baseline/Wasm JIT), some with “high” severity.
• Has improved memory safety and sandboxing, but:
  • Has fewer resources than Google and moves more slowly on large architectural hardening.
  • SpiderMonkey JIT remains a large, complex component.
• You can disable JIT (and Wasm JIT) via `about:config`:
  • e.g., toggling `javascript.options.ion`, `javascript.options.baselinejit`, `javascript.options.wasm` (exact prefs can vary over time).
• You’ve already observed: Speedometer 3.1 score can drop by ~50%; this is consistent with what we expect.

So, between 2022 and 2024, nothing happened that would invalidate Madaidan’s high‑level claim:

JIT remains one of the biggest and most frequently‑targeted pieces of browser attack surface.​

What has changed is:

• Modern exploit chains are more likely to require multiple vulnerabilities (e.g., JIT bug + sandbox escape).
• Mitigations (CFI, CET, site isolation, V8 sandbox, etc.) raise the bar even after a JIT bug is hit.

But none of that makes JIT “safe”. It just means the attacker’s job is harder.

---

4. Updated conclusions (up to 2024, not 2025)

Within my knowledge window, here’s the honest state:

4.1. Sandboxing: Chromium vs Firefox

• On Linux: Chromium’s sandbox (namespaces + strict seccomp + broker) is still significantly stronger than Firefox’s. Fission narrows the isolation gap, but not the kernel‑hardening gap.
• On Windows: Chromium’s AppContainer‑based renderer sandbox, plus modern mitigations, still has the edge over Firefox’s custom sandbox.
• On macOS: Both use Seatbelt, but Chromium maintains more aggressive and granular sandboxing.

So the core Madaidan conclusion on sandboxing remains valid: Chromium is still the more robustly sandboxed architecture overall.

4.2. JIT and “should I disable it?”

• JIT (JS + often Wasm) is still a prime exploit target in both Chromium and Firefox.
• Disabling it:
  • Very likely prevents exploitation of a large subset of JIT‑only bugs.
  • Does not protect you from non‑JIT bugs (DOM, WebGPU, sandbox escapes, drivers, etc.).
  • Imposes a heavy performance cost and can break some modern sites.
• Your own observation (Speedometer 3.1 halved when JIT is off in Firefox) is entirely in line with what we’d expect.

From a pure security maximalist standpoint, Madaidan’s prescription is still coherent:

“If you have a powerful machine and can tolerate significant slowdowns / occasional breakage, disabling JIT can be a rational hardening step, especially combined with a strong sandbox (Chromium) or as extra mitigation for a weaker sandbox (Firefox).”​

For most people, it’s over‑kill; for a high‑risk user, it’s at least reasonable to consider.

---

5. Where I must stop (2025 data)

You explicitly asked:

“…verify what was written in 2022 with the most recent data from 2025…”​

Here I have to be strict: I do not have 2025 sandbox design changes or 2025 JIT‑specific hardening details. I also won’t invent CVEs, changelogs or vendor claims for 2025.

So my conclusions are:

• Verified timeframe: up to ~late 2024.
• Within that window: Madaidan’s main thrust still holds:
  • Chromium’s sandboxing remains meaningfully stronger than Firefox’s on all major desktop OSes.
  • JIT in both engines remains a major and frequently exploited attack surface.
  • Disabling JIT is still a niche but legitimate hardening measure for high‑security setups that can bear the performance/compat cost.
• Unknown beyond that: any 2025 improvements or regressions.

If you want to push this further with 2025 data, the “clean” way is what you already started doing with CVEs:

• Compare 2023–2025 renderer‑sandbox escape CVEs in Chromium vs Firefox.
• Compare 2023–2025 JIT‑related CVEs in both.
• Layer on top the architecture facts (who uses what sandbox, which mitigations).

Given your background, you’re perfectly placed to do that differential analysis; I just can’t see the last year of it.

If you’d like, you can paste specific 2025 release‑note snippets or MFSA/Chromium security note text here (for sandbox/JIT changes), and I can help you reason through those pieces explicitly without guessing.

 

[Sampei.Nihira]

@Bot

No, you don't remember, not Appcontainer for Chrome, only Edge has Appcontainer for the Renderer, Chrome has an IL= untrusted.....

 

[Bot]

@Bot

No, you don't remember, not Appcontainer for Chrome, only Edge has Appcontainer for the Renderer, Chrome has an IL= untrusted.....

You’re right to call that out, and I should have been more careful with the wording.

1. Chrome vs Edge: AppContainer detail

What I can say with confidence (up to my 2024 knowledge):

• Microsoft Edge (Chromium‑based):
  • Does run key sandboxed processes (including renderer) in AppContainer, and Microsoft documents this as a core part of its hardening.
• Google Chrome:
  • Historically relies on a restricted token + low integrity level + job object sandbox for renderer processes.
  • Has gradually adopted AppContainer for some process types/services on modern Windows, but:
    • It is not as simple or universal as “all Chrome renderers are in AppContainer”.
    • My earlier phrasing glossed over this and was too strong.

So your correction about “only Edge has AppContainer for the renderer, Chrome has IL = untrusted” is consistent with how the classic Chrome sandbox is usually described. At minimum, I should not have stated “Chromium’s AppContainer‑based renderer sandbox” as if Chrome and Edge behaved identically there.

2. Main point (sandbox strength) still stands

The detail I botched is the mechanism description, not the high‑level comparison:

• Chrome: restricted token + untrusted/low IL + job objects + win32k lockdown + other mitigations, with some AppContainer use in newer designs.
• Edge: similar, but with more systematic use of AppContainer for renderers.
• Firefox: its own token/IL‑based sandbox, generally still weaker than Chromium’s design.

So: thanks for the correction; the Edge vs Chrome AppContainer distinction is important, and I should have been more precise there.