There's still zero day exploits found in chromium, wouldn't using using this put you at a huge risk of running into malware in the wild that this browser can't protect against?
In general, the sites I want to browse use minimal JavaScript, prudently, if at all, just where it is strictly necessary to add little dynamic features. So, I don’t really care about JavaScript performance at all.
Optimization sometimes introduces additional complexity, which might open up the possibility of security holes (at least it seems to be the case to me, as a not-security-related programmer. I don’t know anything about security on a technical level, so I’m interested in other perspectives on this from people that actually work in those sorts of fields). I wonder if there’s room for a browser engine that ditches performance and just focuses on correctness and safety.
Rendering documents ought to not be computationally intensive, right? Advertisements of blazing fast JavaScript performance make me worry what corners have been cut.
Isn't this just the noscript, which breaks most sites to a degree where they're impossible to use or load?
Sometimes, I just have to load a site that has JavaScript running. Or is unfortunate, but some work sites don’t work without it, etc. I’m fine with those sites being slow (I’ll minimize my use of them naturally), but totally blocking them is slightly inconvenient.
Obviously this isn't the same as making "absolutely no security compromises", but in practice most JS-related security exploits go through the JIT iiuc. Your JS will be executed with a safe interpreter, where by "safe" I mean the dispatching and basic value manipulation are going to be simple enough to be bulletproof, and also slow enough to prevent most timing attacks. The underlying implementation of all of the built-in methods is still going to be more vulnerable, but those tend to be relatively safe as compared to JIT-optimized versions of them. They also don't change much, so have been tested for much longer as compared to the JITs that tend to get refactored and rewritten relatively frequently.
There is a newer class of generic malware that exploits CPU bugs (e.g. Spectre) - are you perhaps referring to that? If so, that's a fair concern but unlikely to matter much in practice. For Spectre itself, I believe the mitigations were applied within the major JS engines directly (or at least for v8 they were).
Anyway, security issues are best compared when there's a lot more attention to your browser. But given that there's a huge amount of exploits that depend on buffer overflows that are simply impossible in the first place with Rust, it's likely that the browser's likely to mostly suffer only from architectural issues & fewer implementation issues whereas other browsers will still have architectural issues and implementation issues to boot that prevent them from addressing it. Yes, newer browser = likely more immature architecture, but at the same time there's fewer implementation issues to worry about in terms of exploiting architectural issues in the first place.
Do you have a citation for "cannot"? Maybe "prefer not because of non-functional requirements" but if it's a choice between a ~~webpage~~ ad vector loading 10 seconds slower versus the goddamn plague of RCEs coming out of Chrome, I know which one I'd take
We see no realistic path for an evolution of C++ into a language with rigorous memory safety guarantees that include temporal safety.
A large-scale rewrite of all existing C++ code into a different, memory-safe language appears very difficult and will likely remain impractical[0].
[0] https://security.googleblog.com/2024/03/secure-by-design-goo....
Long story short; they are stuck with millions of C++ LOC and they can't transition to Rust completely because of the enormous complexity of various gigantic codebases e.g. Android, Chrome or whatever they want to move to memory-safe language/s.
They said they will try to write as much new native code in Rust as they can plus they will interop from C++ to Rust in order to reduce memory-safety bugs.
Also doing that doesn't solve the standards problem we currently have.
Google is able to push through any "standard". And those standards "unwittingly" help them maintain their search/ad dominance or prevent competitors. For example see manifest v3 or FloC (a.k.a Topics API).
Once they gain enough traction and become indispensible, you either implement them or risk losing users.
https://gs.statcounter.com/browser-market-share
which means Google has significant control over web standards
There will be two classes of products one officially sanctioned version and the others that are used by enthusiasts. Apps or sites in this case may chose to work on one and not on others. Imagine the new wave of "works best on IE" with "best viewed on chrome variations a,b,c". Its not farfetched as some sites already do this.
As much as it is easy to maintain a fork, it is that much easy to give up or change path and accept upstream changes.