The browser my agent and I both run

2026-10-06

Brave is the only browser I use, and my agent has a separate Brave install of its own, so it does not use the browser I use myself. Both run with the V8 optimizer off by default and Brave's own ad blocker on. I also use Forgetful Browsing, and I sign in with a passkey or a YubiKey wherever a site accepts one. This post says what each setting covers, what the sources behind it measured and where the setup rubs.

Why turn off the JavaScript optimizer?

A browser runs JavaScript from every page it opens. Brave runs it in V8, the engine from Chromium, which compiles frequently run code to machine code while the page runs. Microsoft's Edge vulnerability research team wrote, in its post on the Super Duper Secure Mode experiment, that CVE data after 2019 showed roughly 45% of the CVEs issued for V8 were related to the JIT engine. By their estimate, turning the JIT off would remove roughly half of the V8 bugs that must be fixed. The Chromium project reports a related figure for the whole browser: around 70% of the high-severity security bugs it analysed since 2015 are memory safety problems.

How far do I turn it off?

Brave has a per-site setting for the V8 optimizer, and I keep it off by default. On top of it I have turned on Brave's JITless mode flag, brave://flags/#brave-v8-jitless-mode. A Privacy Guides forum thread describes the flag as a JITless mode toggle that also enables DrumBrake, the WebAssembly interpreter for Chromium. According to the same thread, with the flag on, the optimizer setting skips the Liftoff-only mode and goes straight to DrumBrake.

Without the flag, Chromium's setting turns off only V8's high-tier compilers. Early versions of it turned off all JIT in the page, WebAssembly included, until a fix in February 2024.

Turning the JIT off does not turn JavaScript off, but it costs speed. Microsoft measured the cost in the Super Duper Secure Mode experiment for Edge. On the tests that showed a page-load regression, the slowdown averaged around 17%, and startup times only improved.

Where does it rub?

I allow the optimizer only on sites I know. My password manager is one of them, for one reason: signing in to it with a passkey needs the exception, and everything else in it works without. Because the setting is per site, the rest of the web still runs without the optimizer.

What does Forgetful Browsing do?

Brave clears a site's first-party storage a few seconds after the last tab of that site closes, so on the next visit the site has no first-party storage from before. It is set per site behind the Shields icon, under Advanced controls, as Forget me when I close this site. Brave's Shields settings can also make it the default for every site. The cost is that a sign-in does not survive closing the site, so each new visit means signing in again.

Why does the ad blocker's language matter?

Brave's ad blocker runs on adblock-rust, an open source engine written in Rust, which parses the URLs of the requests a page makes and checks them against its filter lists. A hostile page controls that input. Safe Rust rules out most of the memory safety bug classes behind Chromium's 70%. I did not check how much unsafe code adblock-rust or its dependencies contain. The reasoning is mine. What Brave's own blog post and README say about the engine is about its speed and memory use.

The blocker can also cut the amount of JavaScript the browser runs, because a third-party script that is never fetched never reaches V8. I have not measured how much.

Why passkeys and a YubiKey?

Google's threat intelligence group counted the zero-days exploited in 2025, and browsers accounted for less than 10% of them. That is a marked fall from the browser-heavy years of 2021 and 2022, and Google says this suggests that browser hardening measures are working. A hardened browser still does nothing against a password typed into a fake page.

That is the gap passkeys and security keys close. A CISA fact sheet from October 2022 says the only widely available phishing-resistant authentication is FIDO/WebAuthn, and calls phishing-resistant MFA the gold standard. The WebAuthn standard scopes each credential to the relying party ID, normally the site's domain, so a lookalike domain cannot use it. In a 2019 study Google found that zero users who used only security keys fell victim to targeted phishing during the investigation. If I could recommend only one change from this post, it would be this one.

The two differ in where the private key lives. A synced passkey sits in a password manager or a platform account and follows me to my other devices, while a credential on a YubiKey is bound to the hardware and signing in needs a touch on the key. That touch matters for agent work too. My agent can browse, but it cannot touch the key, and my deny rules and gate keep it away from the apps behind my sign-in keys. The gate is a filter on the commands a session runs, not a boundary in the operating system.

What does this not show?

It does not show that this setup stops a determined attacker. The 45% is Microsoft's count of V8 CVEs after 2019, not a share of attacks today, and the 70% is Chromium's figure for its own high-severity bugs. No source I found gives a share of all vulnerabilities that comes from JavaScript, so I do not give one. Google's figure under 10% covers the exploitation it observed, and Google itself says attackers have become harder to observe. What the JITless flag does I take from a community thread, not from Brave's own documentation, and Brave's community forum has threads from September 2026 about problems with the setting and the flag that I have not checked. I have not measured how much slower my own browsing is. The passkey exception is what I see with one password manager, and I have not tested others.

Related

• A clean Windows install for agent work
• Define what an agent may do with your data