[meibo]

What you're asking for will probably put you more at risk than V8 does:

1) JavaScript engines with any kind of usable performance are inherently complex

2) V8 is hardened, battle-tested and fuzzed/verified by the best engineers at Google and indepentently by third party researchers, since inception - the engine you will be using probably won't be

All of this is really a side-effect of Chrome's popularity and Google's resources, even the CVE itself. You would be relying on security by obscurity(in which obscurity = no big userbase = not a high value target). Have a look at payouts for RCE-capable V8 bugs.

[fulafel]

> V8 is hardened, battle-tested and fuzzed/verified by the best engineers

It's built on unsound foundations that causes an endless stream of this kind of bugs. They make compromises regarding security engineering and then do indeed put a fair amount of engineering resources to mitigate the resulting security problems.

This can be said to be good or bad engineering depending on your viewpoint, the alternatives might for example have performance tradeoffs and it can be valid engineering to make tradeoffs that favour other things at expense of security. But also we certainly do know practical and proven ways to eliminate this class of memory safety bugs in JS implementations, so it's definitely an engineering choice.

[tessierashpool]

yeah, plus that "the best engineers at Google" has an element of hyperbole. this is one of those times where you can move a statement from being ridiculous to being correct just by throwing in a "some of." it's not like they assigned Jeff Dean to AI instead of Chrome because he just couldn't cut it.

[pas]

can you please elaborate on those unsound foundations?

[fulafel]

Formulating a plan to make V8 safe with a high degree of assurance sounds like a tall order for a monday HN comment!

I'll just point out that this type confusion bug class is just one of many that plague v8 based on perusing the CVE list, and memory safety errors and other security bugs typical of unsafe C++ seem to play a large part in many. V8 is also huge, and complexity is the enemy of security, there are much smaller JS implementations around.

Just fixing these most high profile bug classes might only reveal some other fundamental soundness issues. So it may be necessray to start from a clean slate with soundness and safety design constraints when adding features.

[_Nat_]

I'd prefer a [provably secure](https://en.wikipedia.org/wiki/Provable_security ) JavaScript-engine as a default. Or, if provable-security would be a bit much for a near-term project, something more heavily based in a simple engine-design, without trying to optimize stuff and perhaps including seemingly-redundant run-time checks.

Ya know, stuff like type-checking arguments, using stronger restrictions on async-calls to avoid potential race-conditions, more parameter-validation, relying on automatic-memory-management to avoid bugs, always bound-checking on array-accesses, always overflow-checking math, and so forth. In general, code that's designed to be simple and plainly correct, resisting the temptation to optimize.

Don't get me wrong, I appreciate that a lot of security-folks do good work trying to help identify-and-patch vulnerabilities in V8/etc.. And I appreciate that that enables a balance between performance and security that might be right for some applications. However, there're a lot of cases where I'd prefer a heavier focus on security.

[rurban]

https://bellard.org/quickjs/ would be the easiest effort then

[relaunched]

I've been in the security field a while, what exactly do you mean by provably secure?

[sterlind]

probably a JS engine with guarantee through formal methods that sandbox escapes are impossible. for a JIT engine, this might mean asserting that control flow inside generated code never leaves it, and only accesses pages allocated to it. these obligations would also need to be carried through to standard library implementations.

i.e. probably secure analogously to how seL4 is provably secure. this would be infeasible for a browser, but you could actually accomplish it by running seL4 and executing the JS in an seL4 VM. you'd still have to prove everything the VM has access to is similarly secure, so still not feasible for a browser, but you could maybe make the Node.js equivalent of MSR's Ironclad.

[labawi]

I wish we could and I think we should.

I'm just very sad we don't have safe hardware w.r.t. memory corruption via rowhammer and I don't think any of the typical formal methods or seL4 account for it. Safely running untrusted code is nearly impossible on modern computers.

[stjohnswarts]

What he wants is basically impossible for software projects as big as v8 or chrome, but I guess one can dream :)

[creata]

> JavaScript engines with any kind of usable performance are inherently complex

Depends on what you're using it for, surely? If you're just watching videos or scrolling through the news (where the JavaScript takes a back seat) then wouldn't any implementation be fast enough?

[OscarDC]

> just watching videos [...] (where the JavaScript takes a back seat)

If you're talking about media websites like YouTube, Netflix, Amazon Prime Video, Twitch and so on or even just videos on sites like Facebook, video streaming actually needs a lot of JavaScript behind the hood. Some of it even being already performance-sensitive today.

[creata]

Why would that JavaScript be performance-sensitive?

[meibo]

Video streaming/processing is done by JavaScript or even wasm binaries in popular sites nowadays - only decoding is on the browser itself. YouTube for example also does elaborate obfuscation of parameters to their video CDNs, which gives you a nonce that you can use to access them with usable speeds.

[OscarDC]

It depends heavily on the website we're talking about but there's generally a lot going on when streaming video on the web.

Usually what happens at the core is that JavaScript will download video, audio and subtitles progressively through small chunks of data called "segments" and push them to JS-exposed buffers called 'SourceBuffer'. Deciding which chunk to download, downloading them and pushing them already require a lot of JavaScript (for example, you need to decide which video and audio quality to download through adaptive algorithms, which tend to be quite complex, moreover there's also a lot of media events that needs reaction to, like when seeking, rebuffering, changing track etc.). You also have a lot of JavaScript there to limit risks of playback stalling and if you have DRMs, a lot of JavaScript there to be able to recuperate the right decryption keys (an operation you generally wish to finish as soon as possible as it is often the last step before playback).

On some websites, you might want to play with as low latency as possible between the broadcaster and the user. In those cases, you might want to optimize your JS code, have very small checking intervals, and you might again prefer to run as much code as possible in a worker to avoid rebuffering due to the risk of the main thread being too occupied doing other things to push media segments.

Even on non-low-latency contents, some websites which already have a lot of JavaScript running beside video playback such as at least Facebook and YouTube pushed browsers for quite some time now to be able to use the main JavaScript media streaming APIs in a worker (https://github.com/w3c/media-source/issues/175), e.g. in another thread.

You could also have complex contents (lot of audio and subtitles languages, many audio and video qualities, multiple decryption keys, long duration etc.) that may lead to big performance and memory issue when parsing them on the JS-side. Those contents are usually described through a file named "manifest" or "playlist" which in this case can take a lot of resources to process (the document can be up to a huge 15MB XML where I work), often leading either the linked JavaScript to run in a worker or to use webassembly (a solution we chosed). Even more if you consider live contents, where this document might have to be regularly refreshed.

You might also want to apply some processing on the media played, for example transmuxing mpeg-ts segments to MP4 ones so they can be played by more browsers. Those are very frequent operations that can be performance-sensitive and are also often performed in another thread.

Again it very much depends on the website and I mainly know the use cases I personally encountered. Generally, adaptive media player are very complex JavaScript beasts.

Also performance issues and poor memory management from the browser-side can lead to a lot of issues. A recurring issue at my work is bad performance leading through side-effect to a very poor quality being played (due to the high overhead in loading segments, pushing them to the buffer etc.).

All these would suffer without a powerful and featureful JS engine like we generally have today on most browsers.