Chrome 0day is being exploited now for CVE-2022-1096; update immediately

For another simple example, [buffer-overflow attacks](https://en.wikipedia.org/wiki/Buffer_overflow#Exploitation ) could be trivially prevented through the same sorts of checks.

A popular website for programmers, [StackOverflow](https://stackoverflow.com/ ), was named after this sort of thing.

Then there're memory-management errors that could be prevented through automated-memory-management (e.g., [use-after-free](https://en.wikipedia.org/wiki/Dangling_pointer#Security_hole... )), invalid-parameter exploits that could be prevented by parameter-validation, format-exploits that could be prevented by proper encoding (e.g., [SQL injection](https://en.wikipedia.org/wiki/SQL_injection )), etc..

Likewise, the current zero-day affecting Google's Chrome presumably could've been prevented with more robust type-checking on everything (assuming the bug is as-reported in the article). Such type-checking might be a bit slower, and possibly require a bit more RAM if objects weren't already carrying type-identifiers, but then no such zero-days, either.

A specific optimization that might be faulted for this zero-day in Google's Chrome, etc., might be describable as [type erasure](https://en.wikipedia.org/wiki/Type_erasure ). Presumably this was done because carrying type-identifiers (basically a tag that says what type an object is) requires more RAM (to store the type-identifiers) and more computation (to check that type-identifiers are correct/etc.). However, other optimizations may've been factors in this zero-day too.

In my defence the documentation implies that the willReadFrequently flag is only a hint to the browser, to take a different approach when performing getImageData() operations[1]. However setting the flag to true also impacts drawImage() functionality[2].

I tried reporting the issue as a bug last night - at the very least the issue needs to be documented - but the form for reporting issues kept collapsing on me so I gave up.

[1] - https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasE...

[2] - minimum demo of issue - https://codepen.io/kaliedarik/pen/bGaqMVj

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.