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

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • Appwrite - The Open Source Firebase alternative introduces iOS support
  • Scout APM - Less time debugging, more time building
  • JetBrains - Developer Ecosystem Survey 2022
  • SonarLint - Deliver Cleaner and Safer Code - Right in Your IDE of Choice!
  • user.js

    Firefox privacy, security and anti-tracking: a comprehensive user.js template for configuration and hardening

    >Is there a safer JavaScript engine folks can use without having to worry about this sorta thing? Even if it's slower, less compatible, more resource-intensive, etc.?

    You can disable JIT in firefox[1], which makes it fall back to an interpreter. That should theoretically make it safer as there are less optimizations going on and less generated code being directly executed by the CPU.

    [1] https://github.com/arkenfox/user.js/blob/b4225baaf2f8d15f856...

  • goja

    ECMAScript/JavaScript engine in pure Go

    There are certainly other javascript implementations. For example, here's one I stumbled upon recently that's written in plain Go: https://github.com/dop251/goja

    Of course, it won't help you since it's not built into a web browser.

  • Appwrite

    Appwrite - The Open Source Firebase alternative introduces iOS support. Appwrite is an open source backend server that helps you build native iOS applications much faster with realtime APIs for authentication, databases, files storage, cloud functions and much more!

  • V8

    The official mirror of the V8 Git repository

    Looks like these are the two commits, based on the issue number:

    https://github.com/v8/v8/commit/0981e91a4f8692af337e2588562a...

    https://github.com/v8/v8/commit/a2cae2180a7a6d64ccdede44d730...

    Although there could be others.

  • opensnitch

    OpenSnitch is a GNU/Linux port of the Little Snitch application firewall

  • tinysnitch

    an interactive firewall for inbound and outbound connections

  • ECMAScript 6 compatibility table

    ECMAScript 5/6/7 compatibility tables

    It depends on what "Javascript engine" means, and what sort of javascript you want to execute.

    If you want something that can run ES5 code, this might be your ticket. But if you want something that can run "modern javascript" (where the meaning of "modern" changes over time), then IE11/Trident won't help. It doesn't even support ES6, which came out in 2015. Modern websites often depend on javascript language features newer than that. Npm packages are the same.

    [1] https://kangax.github.io/compat-table/es6/

  • quickjs

    Public repository of the QuickJS Javascript Engine. Pull requests are not accepted. Use the mailing list to submit patches.

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

  • Scout APM

    Less time debugging, more time building. Scout APM allows you to find and fix performance issues with no hassle. Now with error monitoring and external services monitoring, Scout is a developer's best friend when it comes to application development.

  • media-source

    Media Source Extensions

    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.

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts