Yes (from the Google blog post linked elsewhere in the thread):

> CVE-2022-42856, a WebKit remote code execution exploiting a type confusion issue within the JIT compiler (0-day at time of exploitation).

Lockdown mode disables the Webkit JIT.

Routing numbers aren't, but account numbers are: traditionally in the US it's possible to use a routing+account number to withdraw from someone's account.

You need the account holder's name as well.

Perhaps even more evil:

kill -SEGV $1

Looking at the contents of the macOS installer (I haven't tried to run it), it seems to be both. Looks like it's based on https://www.cabbageaudio.com?

Well yes, but GTK and Qt apps feel about as native on macOS as Electron apps do.

Isn't Edge just Chromium these days? The page you linked says:

> Evergreen distribution. Rely on an up-to-date version of Chromium with regular platform updates and security patches.

> probably prone to issues if you can’t update multiple as part of the same transaction

IIRC one of FoundationDB's features is that it does support such transactions, so you can easily implement indexing on top of it.

This is essentially doing that—it would allow browsers to parse and run TypeScript. What it isn't doing is actually having browsers do type checking, for good reason: the TypeScript type checker is a large and complex piece of software, so browsers would either have to incorporate it (and they're probably not excited to have a large chunk of JS code in the critical web-page-rendering path, nor would they be excited to have a critical chunk of the browser with a single implementation), or reimplement it themselves (which would be a huge amount of work, and make changes to the language much slower and more difficult).

Ya this seems like an awesome idea. Let devs run the type checking before they ship code, and then let the browsers run the code just as they would plain JavaScript, ignoring the types. If someone's going to use TypeScript they would be tye checking it first anyway, so no real need to check it again at the browser.

> I am not claiming that running on an OS is the same as dynamically linking with a library

In pretty much any case, it literally is: you're dynamically linking against the libc. This is a little fuzzier on Linux (because, as you mention, multiple libc implementations exist), but on Windows, macOS, and the BSDs, the only supported way to make syscalls is to make calls into a dynamically linked libc, provided by the operating system.

Well, theoretically you could make a (pretty useless) Windows program that doesn't do any syscalls itself. It would mostly be limited to heating up the processor, but it would be a valid program. In fact, you could probably actually do some basic syscalls without linking to NTDLL by using very old DOS syscalls for things like printing to the console, perhaps with a compatibility mode.

Also, being pedantic, in Windows libc is a wrapper over Win32, which is partly itself a wrapper over NTDLL. For example, msvc's malloc() simply calls HeapAlloc() or some variant thereof.

Laptops have batteries, so an AC power failure doesn't mean they immediately crash: they just keep running on battery until the battery gets low, at which point the system cleanly hibernates.