Doesn't everyone else immediately update everything on their computer before they start doing anything?
Is that frequent enough? I mean an update might be issued after you start doing something.
Actively exploited sandbox RCE in all Chromium versions
301–310 of 527 posts
Re: Actively exploited sandbox RCE in all Chromium versions
#302Earlier quoted context omitted.
this is why again, researchers should just honestly sell these to vuln brokers instead of donating them to trillion dollar companies for nothing. nothing will change until big tech can no longer rip off security researchers
They're not going to stop underpaying security researchers just because security researchers decide to sell them to vuln brokers. Advocating for this is reckless.
they will if it becomes common knowledge that nobody serious is participating in their bug bounty programs. besides, they have incredibly deep pockets and they can afford to pay 6 figures for bugs like these
advocating for this is much more ethical than donating money to Google. I'd rather have that money go my family than a multi trillion dollar company.
Re: Actively exploited sandbox RCE in all Chromium versions
#303Earlier quoted context omitted.
We live in a world where my laptop is forced to waste tons of computational power on immensely bloated websites even with ad-block, with now even having to worry about agentic bullshit that I didn't ask for, and plenty of others apparently still think throwing computational cycles at cryptocurrency is good for anything. Complaining about a relatively small performance price for Fil-C in that context honestly feels li…
We also live in a world where site owners purposely put anime cat girls on their websites that serve no purpose then to waste cpu cycles.
Using personal websites read by a handful of programmer nerds that work fine if you turn off javascript to justify literally everyone else being forced to navigate bloated, broken company websites isn't particularly convincing as an argument against memory-safe C imo.
Re: Actively exploited sandbox RCE in all Chromium versions
#304Earlier quoted context omitted.
That's largely because a lot of developers have made the devil's bargain of replacing standard web stuff with badly re-implemented JS versions of same. People did it because they could , but never considered if they should . See most of the ecosystem around React, for reference. It's idiotic that things like URL management are done in Javascript. Or form controls. I guarantee that if we stopped doing this kind of stu…
The problem is not url management. That should happen just once or twice during the life cycle of a page. If it takes 0.1ms or 1ms doesn't have any impact on the usability. One of my problems was that I wanted to show data in the browser. It is a convenient delivery platform, after all. However, Chrome (and Chrome in particular) has tremendous trouble displaying large pages. A 400x400 table takes a long time to rende…
[deleted]
Re: Actively exploited sandbox RCE in all Chromium versions
#305Earlier quoted context omitted.
We live in a world where my laptop is forced to waste tons of computational power on immensely bloated websites even with ad-block, with now even having to worry about agentic bullshit that I didn't ask for, and plenty of others apparently still think throwing computational cycles at cryptocurrency is good for anything. Complaining about a relatively small performance price for Fil-C in that context honestly feels li…
We also live in a world where site owners purposely put anime cat girls on their websites that serve no purpose then to waste cpu cycles.
Perhaps you do.
Re: Actively exploited sandbox RCE in all Chromium versions
#306I’m so tired. I think I’m just going to get a job as a garbage man and cancel my internet.
Just in time.
Re: Actively exploited sandbox RCE in all Chromium versions
#307Earlier quoted context omitted.
Which browser has a better security track record?
Despite what people are saying here, chrome has a really excellent track record. Nobody is perfect. Switching just because chrome got exploited one time will likely result in you switching to something worse. If you're paranoid, disable JIT.
It's not about switching because chrome got exploited one time, it's about switching not to reward unethical behavior.
Re: Actively exploited sandbox RCE in all Chromium versions
#308Earlier quoted context omitted.
The DOM is the slowest part of the browser. It's not Javascript, it's the DOM. React is an attempt to manage the slowness of the DOM. One seemingly small change to a page (like setting innerText) can have many ripple effects with reflow on mamy parts of a page. With thousands of DOM elements on a page, the DOM becomes a bottleneck. This isn't the fault of front-end developers, and it's not really the fault of browser…
> One seemingly small change to a page (like setting innerText) can have many ripple effects with reflow on mamy parts of a page. I haven't looked into how browsers actually do it, but my mental model for it is that if something changes, this merely sets a flag on that element or its parent that its layout is not valid any more. Then, on next vsync, all the elements that have this flag set have their layout recalcula…
[deleted]
Re: Actively exploited sandbox RCE in all Chromium versions
#309CVE-2026-85046 and Northstar web browser:
https://github.com/nordstjernen-web/northstar-browser/blob/m...
Re: Actively exploited sandbox RCE in all Chromium versions
#310Earlier quoted context omitted.
The DOM is the slowest part of the browser. It's not Javascript, it's the DOM. React is an attempt to manage the slowness of the DOM. One seemingly small change to a page (like setting innerText) can have many ripple effects with reflow on mamy parts of a page. With thousands of DOM elements on a page, the DOM becomes a bottleneck. This isn't the fault of front-end developers, and it's not really the fault of browser…
> One seemingly small change to a page (like setting innerText) can have many ripple effects with reflow on mamy parts of a page. I haven't looked into how browsers actually do it, but my mental model for it is that if something changes, this merely sets a flag on that element or its parent that its layout is not valid any more. Then, on next vsync, all the elements that have this flag set have their layout recalcula…
OP here. The steel-man argument for React is not that it is faster at rendering. It cannot be, because it ultimately relies on the same DOM that everyone else does to do the job, and it has to set up a massive JS data structure to do what it does, which uses a lot of memory and has big GC costs. Arguments that assert that the React virtual DOM are faster than the native/shadow DOM are simply wrong [1]. Even the React team admits this [2] (though back in the day, they made a number of puffed-up claims about speed that never made sense).
The principle argument in favor of React today are developer ergonomics. People don't have to manually alter individual elements anymore -- they just describe state, and React takes care of the UI change set. On top of that, you have components, etc., that are debatably more pleasant to work with, and at the least create an ecosystem advantage for users of the framework. One can certainly see the argument for something like facebook, where there are probably dozens of different things changing independently at any given time.
But that said, one really has to question whether React makes sense anymore, given LLMs. Back when the alternative was that someone had to bespoke code every UI component, it might have been worth taking the hit of having to adopt the entire React ecosystem. But now that LLMs are writing the code, there's really no argument for developer ergonomics, and suddenly, things like "rewriting URL handling in JS" are pure liabilities.
[1] Though sadly, many front-end devs don't know this.
[2] https://rossenahuh.netlify.app/React/react-concept-1---virtu...