Earlier quoted context omitted.
Prior art: the evil bit https://datatracker.ietf.org/doc/html/rfc3514
The idea is to make it harder for malicious actors to produce a valid proof than it is for benign actors.
Actively exploited sandbox RCE in all Chromium versions
541–548 of 548 posts
Re: Actively exploited sandbox RCE in all Chromium versions
#542Earlier quoted context omitted.
In the future we can ask that your JaveScript and Wasm comes with a proof of being benign.
What would that even look like? What is "benign"? The browser environment already has pretty strict rules for what the JS can do. It's not allowed to read your files, see your webcam without permission, know about other tabs or windows etc. The problem here is that the browser failed to correctly implement those rules. If the chromium team cannot do that, what makes you think they can implement any other kind of "ben…
Re: Actively exploited sandbox RCE in all Chromium versions
#543> Type confusion in V8 Fortunately I disabled js by default. Unfortunately, it breaks about 30% of the web. Including nvd.nist.gov, which shows a completely blank page without js enabled, even though with js it’s just a simple page with only static content.
> Unfortunately, it breaks about 30% of the web. More like 99% I use Firefox with Noscript and I'm _totally aware_ that almost no website works without allowing it JS. Even using Noscript it's becoming more and more exhausting every year, it's plain impossible to browse the internet without JS at all.
Re: Actively exploited sandbox RCE in all Chromium versions
#544> Type confusion in V8 Fortunately I disabled js by default. Unfortunately, it breaks about 30% of the web. Including nvd.nist.gov, which shows a completely blank page without js enabled, even though with js it’s just a simple page with only static content.
> Unfortunately, it breaks about 30% of the web Only 30%? In 2026? With CloudFlare and Anubis et al absolutely everywhere? Not to mention SPAs
Anubis is trivially bypassed by an extension.
Re: Actively exploited sandbox RCE in all Chromium versions
#545Earlier quoted context omitted.
In Chromium you can turn off V8's JIT compiler for this reason. You can even opt in again for sites you trust that need the additional performance.
The additional performance from the JIT is actually really small for most tasks. It should, ideally, be disabled by default. For your average JS you get It’s only very heavy calculations that see a boost in performance. But, realistically, how many websites require this or currently use this today? This is pretty typical across JIT engines, too. PHP also sees only a slight increase in performance from the JIT. Becaus…
The only .NET implementations that interpret CIL were the .NET Compact and Micro frameworks due to hardware limitations, nowadays mostly gone as .NET workloads, and alternative implementations like Mono.
Re: Actively exploited sandbox RCE in all Chromium versions
#546Let's take a moment to talk about the monetary value of this vulnerability. According to the Chrome release page ( https://chromereleases.googleblog.com/2026/09/stable-channel... ), Google paid a researcher $1000 for ethically reporting this. The CVE associated with it (CVE-2026-85046) is already being exploited in the wild. If we put our thinking caps on, how much do you think this vulnerability is actually worth? H…
Re: Actively exploited sandbox RCE in all Chromium versions
#547Earlier quoted context omitted.
What’s the stack? Is it being used even sort-of in the right place / way? Feels like a glaring omission =]
The stack is Rails / React SPA for the frontend. > Is it being used even sort-of in the right place / way? It's a SaaS where users are mostly always logged-in, kind of an app so you would think it should work from the outside. I think these are the full requirements I would put for a good SPA experience: - low users - low number of features / or a single main feature reused in different ways - low number of employees…
at any point,
I’ll be checking back around later!
Until then: just talk smack about React!
None of these things you listed are critiques of single-page apps (SPA).
Re: Actively exploited sandbox RCE in all Chromium versions
#548Earlier quoted context omitted.
The stack is Rails / React SPA for the frontend. > Is it being used even sort-of in the right place / way? It's a SaaS where users are mostly always logged-in, kind of an app so you would think it should work from the outside. I think these are the full requirements I would put for a good SPA experience: - low users - low number of features / or a single main feature reused in different ways - low number of employees…
If anyone wants to show up and talk non-React anything, at any point, I’ll be checking back around later! Until then: just talk smack about React! None of these things you listed are critiques of single-page apps (SPA).
I'm sure counter examples of well managed SPAs do exist somewhere, it's just that it seems much easier to do the wrong thing compared to a traditional stack. This is why I'd not advise for it unless you have a very good reason.
The good stacks should make the good choices the natural way to do things, again my opinion.