281–290 of 524 posts
> 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.
Only 30%? In 2026? With CloudFlare and Anubis et al absolutely everywhere? Not to mention SPAs
Earlier quoted context omitted.
> SPAs will be slow no matter what. Uh…no? You’re presumably talking about specific terrible prebuilt frameworks - not someone building a nice vanilla SPA.
At this point SPA pretty much implies React. But even if you optimize everything the best you could and avoid any third-party runtime dependencies, it's still going to be significantly more work to make API requests and do client-side rendering vs just rendering HTML server-side.
Earlier quoted context omitted.
I still do "random" browsing in FF with NoScript, that said, I'll acknowledge the frequency of updates of Chrome,etc and years of hardening. It's not the Bonzi-buddy and driveby-installed IE toolbars wild west of the early 00s.
The browsers on the computers at work show that it is very much still the driveby tool-bar install days.
Can you please provide a link to a page where a “toolbar drive-by install” occurs?
Earlier quoted context omitted.
If the vulnerability is already being exploited in the wild --- as in, it's a vector people already know about and are tracking --- it's possibly not worth much at all. Vulnerability valuations depend heavily on the lifespan of the vulnerability; payments on black market are tranched (explicitly or less explicitly, as with "maintenance payments") based on whether they're patched. Further: a vulnerability is probably…
I was under the impression that the three letter agencies and contractors bought vulnerabilities?
Earlier quoted context omitted.
> Posted from a memory safe browser - WebKit MiniBrowser compiled with Fil-C. Pretty sure this is safer than even V8 and the heap sandbox. It's easy to be safer, as long as performance can be sacrificed for it.
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…
Let'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…
Earlier quoted context omitted.
But google is also a monopsony. There isn't anyone else the researcher can ethically sell it to. They just have to take whatever bounty google decides to pay.
I'm just saying it's more evidence that Google should be broken up.
Earlier quoted context omitted.
> See most of the ecosystem around React, for reference. I've never used React myself, but what I've heard about it makes me question my own sanity. So are you going to tell me that instead of just updating the DOM tree directly I'm going to apply the changes to my data, then pass the entire model to the framework, which would then diff it with the previous version to get the changes back out , it would then call my…
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…
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 recalculated, potentially going up the tree as necessary. The only exception is if your script tries to get any layout-related property, e.g. offsetWidth. Then, as if as part of the getter of such a property, the layout recalculation will run immediately.
That is to say, if you need to make a lot of changes to the DOM, you should make them within one JS invocation so only one layout pass happens sometime after you're done.
Earlier quoted context omitted.
Firefox with uBlock Origin. It’s astonishing how many exploits uBO stops before they ever reach your browser engine. It’s the antivirus of the 2020s.
Brave would be a much better option if you want security and good adblocking.
Per OP link, it only affects Chrome versions prior to .82; .82 was released as stable 2 days ago. [1]
(HN title also does not match the original title, which is the CVE ID -- not particularly intuitive.)
[1] https://chromereleases.googleblog.com/2026/09/stable-channel...