Actually JPEG XL is based in part on Google's PIK format. The Zurich team from Google Research (which developed PIK and Brotli) is even actively working on JPEG XL to this day.
The reason why Chrome (also a Google product) removed it at first is more likely to be internal politics. Google is a very large corporation after all, with each faction within it having its own priorities and alignments. In the case of Chrome the team there are probably more aligned with the AVIF/AOM team than with Zurich/PIK when it came to the next-gen image format to be pushed (which would explain why Chrome did not have problems with Brotli, because there wasn't a competing Google faction that is developing a replacement for gzip).
WebExtensions still have them? I thought the move to HTML (for better or worse) would've killed that. Even install.rdf got replaced IIRC so there shouldn't be much traces of XML in the new extensions system...
Simply a consequence of multi-process' inter-process communication (IPC) swamping the task scheduler. Changing the title requires a message to be sent from a content process to the UI through IPC. If you sufficiently flood the IPC protocol with messages, it will bring your browser to a halt in its entirety because you're basically DoSing the browser's internal communications.
Single-process browsers (e.g. Pale Moon) and browsers that have previously been designed primarily with a single-process model in mind and only adopted multi-process later (Firefox, Safari) would've handled this better by at the very least not locking up the browser and eventually the OS with a runaway meltdown in memory allocation.
To test this theory I've forced the Brash code to run with `Brash.run({burstSize: 8000,interval: 1});` in the devtools console. Why the PoC author decided to arbitrarily restrict the running the PoC only to Chrome-based browsers, I don't know. If non-Chrome truly is not vulnerable we should be able to verify that for ourselves.
In a fresh profile of Pale Moon without add-ons (and immediately closing the devtools afterwards) the UI does slow down but it's still usable (and therefore the offending tab can be closed even after a while). If you never reopen devtools in the offending tab the memory never even reaches 1 GB. In the worst-case scenario where the browser would hang (which could happen if you try to open up devtools in the offending tab for example), the memory allocation doesn't get instantly out of control, and the OS will recognize that it's hanging and let you close it.
In Firefox the UI is still working somewhat but memory allocation is faster than Pale Moon (but a bit slower than Chrome). Memory becomes manageable though when you switch focus to another tab; it no longer allocates more memory and the garbage collector was able to free up memory in the offending tab's content process with the JavaScript engine no longer blocking it thanks to the said content process being suspended in the background. However the main UI process will still hold a lot of memory unless you switch back to the offending tab for the garbage collector to recognize it needs to free up memory there. And if you close the offending tab before that you get yourself a memory leak, i.e. the memory allocated by the UI process will never go away, at least until you rerun the Brash code again (where the garbage collector will then recognize there is memory to be freed in the UI process).
I don't know about Safari, I have no Apple device to test it with unfortunately.
And it's not just the WebKit monopoly in iOS, but also being slow on adopting new features pushed by Google. Often even being slower than Mozilla funnily enough. I don't care about what Apple's intentions could be for being a slowpoke on adopting the new features, as long as it allows independent browsers like Pale Moon to catch up with the mainstream.
I tried the link preview feature on a link to the English Wikipedia article about Touhou Project, and the LLM's key points are just hilariously bad. For some reason it's focusing too much on the PS4 and Nintendo Switch (which the LLM "thinks" were both released on August 15, 1997). I have a screenshot 6 days ago when it wasn't a Firefox Labs feature yet in my Misskey: https://makai.chaotic.ninja/notes/a6d86p8n26
Tried it today in an updated Nightly and the key points are still the same lol.
"Bot attack protection" mode is also opt-in and many sysadmins just enable it immediately after setting up their website with CF and forget about it (because Cloudflare's marketing suggests it), leading to legitimate browsers being blocked: https://news.ycombinator.com/item?id=43329320
With so much hate towards LLMs right now (which isn't unjustified) being vented on the internet there's no doubt sysadmins will do the same here and niche user agents will again suffer.
"Tracking" is pretty vague and trying to stop it is just unenforceable, unlike "selling personal information" which is very clear and what GPC and the CCPA and GDPR cover. I often criticize Mozilla but they're correct in replacing unenforceable DNT (which is also worse fingerprinting-wise since it has three possible values instead of being a binary on-off signal) with GPC. It's long overdue.
By default the browser checks for available updates, whether for the browser or the add-ons (in the latter case, it's most probable that at least one installed add-on is hosted in the Pale Moon add-ons site). There's also the sync service, and default start page at start.palemoon.org. You can probably gather some stats from those sources.
The reason why Chrome (also a Google product) removed it at first is more likely to be internal politics. Google is a very large corporation after all, with each faction within it having its own priorities and alignments. In the case of Chrome the team there are probably more aligned with the AVIF/AOM team than with Zurich/PIK when it came to the next-gen image format to be pushed (which would explain why Chrome did not have problems with Brotli, because there wasn't a competing Google faction that is developing a replacement for gzip).