201–210 of 242 posts
https://issues.chromium.org/issues/483569511 - [TBD][483569511] High CVE-2026-2441: Use after free in CSS. Reported by Shaheen Fazim on 2026-02-11
> Access is denied to this issue. Access to this issue may be resolved by signing in.
Earlier quoted context omitted.
> Don't we have a bunch of tools that should create memory-safish binaries by applying the same validation checks that memory-safe languages get for free purely from their design? No, we don't. All of the ones we have are heavily leveraged in Chromium or were outright developed at Google for similar projects. 10s of billions are spent to try to get Chromium to not have these vulnerabilities, using those tools. And he…
> No, we don't. All of the ones we have are heavily leveraged in Chromium or were outright developed at Google for similar projects. 10s of billions are spent to try to get Chromium to not have these vulnerabilities, using those tools. And here we are. Chromium is filled with sloppy and old code. Some of the source code (at least if dependencies are included) is more than 20 years old, and a lot of focus has been on…
Chromium is also some of the most highly invested in software with regards to security. Literally entire technologies that we now take for granted (seccomp-ebpf comes to mind) exist to make Chrome safe. Sanitizers were a Google project that Chromium was an aggressive adopter and contributor towards. I could go on.
> Using Rust does not necessarily solve this. First, performance-sensitive code can require 'unsafe', and unsafe allows for memory unsafety, thus going back to square one, or further back.
This isn't really true? I have no idea what "further back" means here. The answer seems to just be "no". Unsafe does allow for memory unsafety but it's hilarious to me when people bring this up tbh. You can literally `grep unsafe` and ensure that your code in that area is safe using all sorts of otherwise insanely expensive means. Fuzz that code, ensure coverage of that code, run `miri`, which is like a sanitizer on steroids, or literally formally verify it. It's ridiculous to compare this to C++ where you have no "grep for the place to start" capability. You go from having to think of 10s of millions of lines of code that holds a state space vastly greater than the number of particles of this universe 100000000x over, to a tiny block.
With the level of investment that Google puts into things like fuzzing, Rust would have absolutely made this bug harder to ship.
> And second, memory safety isn't the only source of vulnerabilities.
It's the source of this one and every ITW Chromium exploit that I can recall off of the top of my head.
Earlier quoted context omitted.
The listed browsers are basically skins on top of the same chromium base. It’s why Firefox and Safari as so important despite HN’a wish they’d go away.
HN wants Firefox but with better stewardship and fewer misdirected funds. Mozilla - wrongly - believes that the majority of FF users believe in Mozilla's hobby projects rather than that they care about their browser. That's why - as far as I know - to this day it is impossible to directly fund Firefox. They'd rather take money from google than to be focusing on the one thing that matters.
It would be great to get transparency on this…
Earlier quoted context omitted.
> No, we don't. All of the ones we have are heavily leveraged in Chromium or were outright developed at Google for similar projects. 10s of billions are spent to try to get Chromium to not have these vulnerabilities, using those tools. And here we are. Chromium is filled with sloppy and old code. Some of the source code (at least if dependencies are included) is more than 20 years old, and a lot of focus has been on…
> Chromium is filled with sloppy and old code. Some of the source code (at least if dependencies are included) is more than 20 years old, and a lot of focus has been on performance, not security. Chromium is also some of the most highly invested in software with regards to security. Literally entire technologies that we now take for granted (seccomp-ebpf comes to mind) exist to make Chrome safe . Sanitizers were a Go…
Earlier quoted context omitted.
HN wants Firefox but with better stewardship and fewer misdirected funds. Mozilla - wrongly - believes that the majority of FF users believe in Mozilla's hobby projects rather than that they care about their browser. That's why - as far as I know - to this day it is impossible to directly fund Firefox. They'd rather take money from google than to be focusing on the one thing that matters.
We have no idea what is in that contract with Google. They get to be the default search engine, but what else? Does it prevent Firefox from accepting some sources of funding, like donations? It would be great to get transparency on this…
Earlier quoted context omitted.
> Chromium is filled with sloppy and old code. Some of the source code (at least if dependencies are included) is more than 20 years old, and a lot of focus has been on performance, not security. Chromium is also some of the most highly invested in software with regards to security. Literally entire technologies that we now take for granted (seccomp-ebpf comes to mind) exist to make Chrome safe . Sanitizers were a Go…
[flagged]
Earlier quoted context omitted.
> both of these are not the case in practice though No, people routinely write Rust with no third-party dependencies, and yet people do not routinely write C code that is memory-safe. Your threat model needs re-evaluating. Also keep in mind that the most common dependencies (rand, serde, regex, etc) are literally provided by the Rust project itself, and are no more susceptible to supply chain attacks than the compile…
People also write Rust code that is not memory-safe. https://materialize.com/blog/rust-concurrency-bug-unbounded-...
Earlier quoted context omitted.
We have no idea what is in that contract with Google. They get to be the default search engine, but what else? Does it prevent Firefox from accepting some sources of funding, like donations? It would be great to get transparency on this…
Do you mean Firefox specifically? Because you can donate to Mozilla: https://www.mozillafoundation.org/en/donate/ it's that you can't specify where you want the funds to go.
this is insane! what other zero days are out there and being used also this seems chromium only so it doesnt impact firefox ?
Earlier quoted context omitted.
> Chromium is filled with sloppy and old code. Some of the source code (at least if dependencies are included) is more than 20 years old, and a lot of focus has been on performance, not security. Chromium is also some of the most highly invested in software with regards to security. Literally entire technologies that we now take for granted (seccomp-ebpf comes to mind) exist to make Chrome safe . Sanitizers were a Go…
[flagged]
If you'd like me to construct a formal syllogism to communicate my points then I might be able to abide. You first though because I find it utterly ridiculous to complain about "logical errors" in what I've written when your post made numerous unsupported or seemingly irrelevant claims.
[0] https://web.archive.org/web/20221001182026/https://www.grapl...