4 ms·

I think the problem is that we've let JS engines become absurdly complex so there's no way to avoid them having really gross bugs. That said, I think that the

I think the problem is that we've let JS engines become absurdly complex so there's no way to avoid them having really gross bugs. That said, I think that the V8 team has done a fantastic job of securing their engine. Their heap sandbox feature is really inspiring! It's really wild that (as far as I can understand this issue) someone is able to bypass it. (Posted from a memory safe browser - WebKit MiniBrowser compiled with Fil-C. Pretty sure this is safer than even V8 and the heap sandbox.)

ruuda 29d ago
In Chromium you can turn off V8's JIT compiler for this reason. You can even opt in again for sites you trust that need the additional performance.
- a022311 28d ago
  I'm glad I've already done that! I haven't seen any difference in performance like others mention though. Weird. The only override I've made is for a website which needs to run some client-side cryptography code and it would take ages without the JIT.
- preg_match 28d ago
  The additional performance from the JIT is actually really small for most tasks. It should, ideally, be disabled by default. For your average JS you get <10% performance gain. Most of the cost is browser API, not JS, so the performance is underwhelming. It’s only very heavy calculations that see a boost in performance. But, realistically, how many websites require this or currently use this today? <1%? Maybe <.1%? This is pretty typical across JIT engines, too. PHP also sees only a slight increase in performance from the JIT. Because of the nature of PHP applications, most time is spend on the network and database. Only very CPU-heavy code sees a significant speed up. That’s even the case for C#, which is why the dotnet runtime only conditionally JIT compiles code. Only hot path code is eligible for JIT compilation.
  - kccqzy 28d ago
    I’ve done that long ago. In fact on iOS it’s simpler: since Apple doesn’t allow third party browsers to use the JIT, using any browser other than Safari will disable the JIT.
    - gsnedders 28d ago
      This hasn’t been true in over a decade.
    - acchow 28d ago
      Chrome on iOS has always been JIT'd because it used a WKWebView. It still uses a WKWebView today, even in the EU, despite Apple now allowing alternative browser engines in the EU as of 2 years ago. I'm sure Chrome will eventually ship Blink+V8 in the EU. It will take some time
  - cageface 28d ago
    Do you have any citations for this? Not that I doubt you but I’d like to read more about it.
    - preg_match 27d ago
      Yes, the V8 team released a blog when they introduced jitless mode: https://v8.dev/blog/jitless https://v8.dev/blog/jitless In synthetic benchmarks, there was a 40-80% reduction in performance when disabling the JIT. But in a simulated test on YouTube.com, the performance delta was only 6%. This isn’t the best source as it’s a bit old, and it wasn’t just JIT that was disabled. But the core idea is the same: calculation-heavy code can see an improvement, but most code won’t. Why this matters is how people actually use JS on the web. It’s not for cryptography and such, it’s to manipulate the DOM. Microsoft also has some benchmarks here: https://microsoftedge.github.io/edgevr/posts/Super-Duper-Secure-Mode/ https://microsoftedge.github.io/edgevr/posts/Super-Duper-Sec... For PHP the RFC analyzes it: https://wiki.php.net/rfc/jit https://wiki.php.net/rfc/jit We see a similar pattern: in synthetic benchmarks, the performance gain is large. But Wordpress, by far the largest PHP deployment in the wild, only saw ~3% performance gain. It again comes down to how PHP is used. It’s mostly HTML construction and database calls, neither of which will see any performance gain from a JIT. And, PHP has extensions, where most heavy code is moved to. Things like cryptography are done in PHP extensions, in C, where the JIT doesn’t matter. I’m more familiar with PHP, so I’ve known about the history of PHP not shipping a JIT due to the lackluster performance.
creshal 29d ago
> Posted from a memory safe browser - WebKit MiniBrowser compiled with Fil-C. Pretty sure this is safer than even V8 and the heap sandbox. It's easy to be safer, as long as performance can be sacrificed for it.
- vanderZwan 29d ago
  We live in a world where my laptop is forced to waste tons of computational power on immensely bloated websites even with ad-block, with now even having to worry about agentic bullshit that I didn't ask for, and plenty of others apparently still think throwing computational cycles at cryptocurrency is good for anything. Complaining about a relatively small performance price for Fil-C in that context honestly feels like that one famous newspaper photo of a smoking pregnant woman drinking a beer with a caption saying she's wbrried about the effects of the loud construction noises next door on her unborn child. Except even that is wrong, because at least she had a point about the construction noises, while this is more of a "refusing to eat your vegetables" kind of situation.
  - ChocolateGod 28d ago
    We also live in a world where site owners purposely put anime cat girls on their websites that serve no purpose then to waste cpu cycles.
    - vanderZwan 28d ago
      Using personal websites read by a handful of programmer nerds that work fine if you turn off javascript to justify literally everyone else being forced to navigate bloated, broken company websites isn't particularly convincing as an argument against memory-safe C imo.
    - tclancy 28d ago
      Perhaps you do.
- pizlonator 28d ago
  > easy to be safer It took over two years and help from contributors to get to the point where WebKit could be made fully memory safe.
odyssey7 28d ago
When Chromium and V8 are written in a memory-safe language then I might believe this. Yes, if your JavaScript engine is written in C++, it’s going to be very hard to avoid very gross bugs. We have better options now. The ability of adversaries to find and exploit very gross bugs in C++ codebases should have already compelled the industry to move to memory safety. Now that AI has democratized the ability to scour C++ codebases for really gross and exploitable bugs, I should think that our hands are at last being forced. I’m not impressed by what I’ve seen in the industry with respect to taking memory safety seriously.
- rvz 28d ago
  Exactly this. This is a never ending problem with C/C++ and it's these same memory corruption CVEs appearing all the time. I also cringe at projects that "compile C to WASM" and then believe that it is immediately "memory-safe". (It really is not.) The only exception for C/C++ projects is Fil-C which that is memory-safe. New projects at this point should just consider using Rust instead.
- tsoukase 27d ago
  I believe programmers still write in C(++) after memory safe options, in order to continue being occupied afterwards, fixing the bugs that will arise. Without criminals, police is obsolete.
- account42 26d ago
  A JIT by definition bypasses the safety mechanisms of whatever language you write it in. Think before you post.
heresie-dabord 28d ago
> WebKit MiniBrowser compiled with Fil-C Sir, do you happen to have instructions for doing this? We who benefit from your philanthropy salute you.

ruuda 29d ago

In Chromium you can turn off V8's JIT compiler for this reason. You can even opt in again for sites you trust that need the additional performance.

a022311 28d ago
I'm glad I've already done that! I haven't seen any difference in performance like others mention though. Weird. The only override I've made is for a website which needs to run some client-side cryptography code and it would take ages without the JIT.
preg_match 28d ago
The additional performance from the JIT is actually really small for most tasks. It should, ideally, be disabled by default. For your average JS you get <10% performance gain. Most of the cost is browser API, not JS, so the performance is underwhelming. It’s only very heavy calculations that see a boost in performance. But, realistically, how many websites require this or currently use this today? <1%? Maybe <.1%? This is pretty typical across JIT engines, too. PHP also sees only a slight increase in performance from the JIT. Because of the nature of PHP applications, most time is spend on the network and database. Only very CPU-heavy code sees a significant speed up. That’s even the case for C#, which is why the dotnet runtime only conditionally JIT compiles code. Only hot path code is eligible for JIT compilation.
- kccqzy 28d ago
  I’ve done that long ago. In fact on iOS it’s simpler: since Apple doesn’t allow third party browsers to use the JIT, using any browser other than Safari will disable the JIT.
  - gsnedders 28d ago
    This hasn’t been true in over a decade.
  - acchow 28d ago
    Chrome on iOS has always been JIT'd because it used a WKWebView. It still uses a WKWebView today, even in the EU, despite Apple now allowing alternative browser engines in the EU as of 2 years ago. I'm sure Chrome will eventually ship Blink+V8 in the EU. It will take some time
- cageface 28d ago
  Do you have any citations for this? Not that I doubt you but I’d like to read more about it.
  - preg_match 27d ago
    Yes, the V8 team released a blog when they introduced jitless mode: https://v8.dev/blog/jitless https://v8.dev/blog/jitless In synthetic benchmarks, there was a 40-80% reduction in performance when disabling the JIT. But in a simulated test on YouTube.com, the performance delta was only 6%. This isn’t the best source as it’s a bit old, and it wasn’t just JIT that was disabled. But the core idea is the same: calculation-heavy code can see an improvement, but most code won’t. Why this matters is how people actually use JS on the web. It’s not for cryptography and such, it’s to manipulate the DOM. Microsoft also has some benchmarks here: https://microsoftedge.github.io/edgevr/posts/Super-Duper-Secure-Mode/ https://microsoftedge.github.io/edgevr/posts/Super-Duper-Sec... For PHP the RFC analyzes it: https://wiki.php.net/rfc/jit https://wiki.php.net/rfc/jit We see a similar pattern: in synthetic benchmarks, the performance gain is large. But Wordpress, by far the largest PHP deployment in the wild, only saw ~3% performance gain. It again comes down to how PHP is used. It’s mostly HTML construction and database calls, neither of which will see any performance gain from a JIT. And, PHP has extensions, where most heavy code is moved to. Things like cryptography are done in PHP extensions, in C, where the JIT doesn’t matter. I’m more familiar with PHP, so I’ve known about the history of PHP not shipping a JIT due to the lackluster performance.

creshal 29d ago

> Posted from a memory safe browser - WebKit MiniBrowser compiled with Fil-C. Pretty sure this is safer than even V8 and the heap sandbox. It's easy to be safer, as long as performance can be sacrificed for it.

vanderZwan 29d ago
We live in a world where my laptop is forced to waste tons of computational power on immensely bloated websites even with ad-block, with now even having to worry about agentic bullshit that I didn't ask for, and plenty of others apparently still think throwing computational cycles at cryptocurrency is good for anything. Complaining about a relatively small performance price for Fil-C in that context honestly feels like that one famous newspaper photo of a smoking pregnant woman drinking a beer with a caption saying she's wbrried about the effects of the loud construction noises next door on her unborn child. Except even that is wrong, because at least she had a point about the construction noises, while this is more of a "refusing to eat your vegetables" kind of situation.
- ChocolateGod 28d ago
  We also live in a world where site owners purposely put anime cat girls on their websites that serve no purpose then to waste cpu cycles.
  - vanderZwan 28d ago
    Using personal websites read by a handful of programmer nerds that work fine if you turn off javascript to justify literally everyone else being forced to navigate bloated, broken company websites isn't particularly convincing as an argument against memory-safe C imo.
  - tclancy 28d ago
    Perhaps you do.
pizlonator 28d ago
> easy to be safer It took over two years and help from contributors to get to the point where WebKit could be made fully memory safe.

odyssey7 28d ago

When Chromium and V8 are written in a memory-safe language then I might believe this. Yes, if your JavaScript engine is written in C++, it’s going to be very hard to avoid very gross bugs. We have better options now. The ability of adversaries to find and exploit very gross bugs in C++ codebases should have already compelled the industry to move to memory safety. Now that AI has democratized the ability to scour C++ codebases for really gross and exploitable bugs, I should think that our hands are at last being forced. I’m not impressed by what I’ve seen in the industry with respect to taking memory safety seriously.

rvz 28d ago
Exactly this. This is a never ending problem with C/C++ and it's these same memory corruption CVEs appearing all the time. I also cringe at projects that "compile C to WASM" and then believe that it is immediately "memory-safe". (It really is not.) The only exception for C/C++ projects is Fil-C which that is memory-safe. New projects at this point should just consider using Rust instead.
tsoukase 27d ago
I believe programmers still write in C(++) after memory safe options, in order to continue being occupied afterwards, fixing the bugs that will arise. Without criminals, police is obsolete.
account42 26d ago
A JIT by definition bypasses the safety mechanisms of whatever language you write it in. Think before you post.

heresie-dabord 28d ago

> WebKit MiniBrowser compiled with Fil-C Sir, do you happen to have instructions for doing this? We who benefit from your philanthropy salute you.