Question Is it necessary to block "JavaScript optimization" in Chromium-based browsers?

[lokamoka820]

Recently, I've noticed that "JavaScript optimization" is suggested to be blocked in settings in privacy and security guides for browsers based on Chromium. Is this a good idea or is it a paranoid action?

Thank you.

 

[Parkinsond]

Trading security for speed; I keep it on.

 

[Sampei.Nihira]

Recently, I've noticed that "JavaScript optimization" is suggested to be blocked in settings in privacy and security guides for browsers based on Chromium. Is this a good idea or is it a paranoid action?

Thank you.

It significantly reduces performance, which you can verify with the Speedometer 3.1 test.
So it's up to you.

 

[KnownStormChaser]

Most patched exploits in the Chromium browser are because of JavaScript. So if you disable it, you'll significantly reduce the chances of experiencing an exploit. But it will reduce the performance of webpages, so it's up to you if it's worth the trade-off.

 

[oldschool]

I always disable JIT and don't notice any appreciable performance hit. GOS disables it by default in Vanadium.

 

[ForgottenSeer 116559]

Modern Chromium benefits from the V8 Sandbox, an in-process isolation mechanism specifically designed to contain memory corruption bugs in V8, including the vast majority in JIT.

Even if a JIT optimization bug gives an attacker arbitrary read/write inside V8's heap, the sandbox confines that corruption to a dedicated ~1 TB virtual-address region. This has been the default since Chrome 123 (early 2024) and is formally part of Google's Vulnerability Reward Program—bypasses are rare and treated as high-value bugs.

This article on the V8 Sandbox provides some good insights:

Similarly, disabling the JIT compilers would also only be a partial solution: historically, roughly half of the bugs discovered and exploited in V8 affected one of its compilers while the rest were in other components such as runtime functions, the interpreter, the garbage collector, or the parser.

Beyond that, Chromium layers multiple other defenses that work well with JIT enabled, like the renderer sandbox + strict site isolation. Real-world exploit chains now need multiple bugs: one inside V8 and at least one more to break out of the renderer sandbox.

An effective ad/tracker blocker further reduces attack surface by limiting the chance of a drive-by exploit from third parties. Only enabling JavaScript on trusted domains à la NoScript reduces the risk further yet, if that fits your style.

 

[Parkinsond]

I always disable JIT and don't notice any appreciable performance hit. GOS disables it by default in Vanadium.

Yes, the speed taxing is minimal with a fast internet plan.

 

[Sampei.Nihira]

Modern Chromium benefits from the V8 Sandbox, an in-process isolation mechanism specifically designed to contain memory corruption bugs in V8, including the vast majority in JIT.

Even if a JIT optimization bug gives an attacker arbitrary read/write inside V8's heap, the sandbox confines that corruption to a dedicated ~1 TB virtual-address region. This has been the default since Chrome 123 (early 2024) and is now formally part of Google's Vulnerability Reward Program—bypasses are rare and treated as high-value bugs.

This article on the V8 Sandbox provides some good insights:


Beyond that, Chromium layers multiple other defenses that work well with JIT enabled, like the renderer sandbox + strict site isolation. Most real-world exploit chains now need two bugs: one inside V8 and another to break out of the renderer sandbox.

An effective ad/tracker blocker further reduces attack surface by limiting the chance of a drive-by exploit from third parties. Only enabling JavaScript on trusted domains à la NoScript reduces the risk further yet, if that fits your style.

Although, in my opinion, the default level of Chrome's sandbox is insufficient.
EnableCsrssLockdown is also important because it blocks privilege escalation and makes malware process injection more difficult.
Ultimately, hardening Chrome's sandbox significantly reduces the risk.
It is therefore better to have the Renderer in Appcontainer.

 

[TairikuOkami]

Is this a good idea or is it a paranoid action?

I even disable GPU/Webgl, since it acts similarly to javascript and flash. I never use GPU tasks. Netflix runs just fine, though browser games can run like 1FPS per sec.
Besides using GPU was recommended in the past to optimize give CPU some breathing room, but these days, CPUs lay dormant and using CPU is more energy efficient.

Spoiler

rem 0 - Disable Microsoft Windows Just-In-Time (JIT) script debugging
reg add "HKCU\Software\Microsoft\Windows Script\Settings" /v "JITDebug" /t REG_DWORD /d "0" /f
reg add "HKU\.Default\Microsoft\Windows Script\Settings" /v "JITDebug" /t REG_DWORD /d "0" /f

rem 1 - AllowJavaScriptJit / 2 - BlockJavaScriptJit (Do not allow any site to run JavaScript JIT)
reg add "HKLM\Software\Policies\Microsoft\Edge" /v "DefaultJavaScriptJitSetting" /t REG_DWORD /d "0" /f

Microsoft Edge Browser Policy Documentation DefaultJavaScriptJitSetting

Windows and Mac documentation for supported Microsoft Edge Browser policy: Control use of JavaScript JIT

learn.microsoft.com

 

[ForgottenSeer 116559]

Although, in my opinion, the default level of Chrome's sandbox is insufficient.
EnableCsrssLockdown is also important because it blocks privilege escalation and makes malware process injection more difficult.
Ultimately, hardening Chrome's sandbox significantly reduces the risk.
It is therefore better to have the Renderer in Appcontainer.

These experimental/optional sandbox options are quite impractical for the majority of Chromium users. I'm not going to rebuild my copy of Brave from source to enable experimental flags.

The default sandbox is still strong. Exploits are rare and require chaining multiple bugs, and incidents have been serious enough to trigger government advisories.

A user can find other means of strengthening defenses and reasonably enjoy peace of mind.

 

[Sampei.Nihira]

These experimental/optional sandbox options are quite impractical for the majority of Chromium users. I'm not going to rebuild my copy of Brave from source to enable experimental flags.

The default sandbox is still strong. Exploits are rare and require chaining multiple bugs, and incidents have been serious enough to trigger government advisories.

A user can find other means of strengthening defenses and reasonably enjoy peace of mind.

Only enabling the Appcontainer Renderer is “above average” because it requires two steps.

All other sandbox hardening measures are applied with simple Chromium Command Line Switches:

List of Chromium Command Line Switches « Peter Beverloo

Therefore, they are within the reach of all users.