Lots of good comments with good points but none about security so far. There is no lack of alternative browsers, really. Personally, I find projects that take a new approach highly interesting. More interesting than those that that clone what Chrome and Firefox do. I used surf, uzbl and luakit extensively, but what prevents me from adopting them as daily drivers is always the nagging concerns about security.
As unlikely as it may seem, I can well imagine that a dedicated team produces an alternative browser that - feature-wise and functionally - is good enough for daily use for most people. For the life of me, I cannot imagine they will come up with a browser that is as secure as Chrome.
Let's face it the amount of work and money that has been put into Chrome's security is amazing. As much as I love Rust and how it helps us write more secure software, it only gets us so far when it comes to the multiple threats a web agent implementation has to face.
A pure Rust browser is immensely more secure than any browser written in C++, at least against memory safety bugs. There is still the source of logic bugs, stuff like the same origin policy, but the worst that can happen is an XSS attack instead of RCE or similar. The browser would be ideal to access the 99% of websites you don't log in to (provided that the browser can actually render them correctly), and eliminate the main danger from them. For websites you log in to, you can still use Chrome.
Something like 70% of all CVEs in C++ applications (including browsers--the actual type of application doesn't seem to matter much) are memory safety issues. Yet the myth persists that memory safety isn't an important bug class for stuff written in modern C++. I think the converse is true: most C++ programmers tend to significantly underestimate the number of remaining bugs in their code that are memory safety bugs.
Bugs related to the JIT are normally counted separately, AFAIK. The 70% figure tends to hold even in systems with no JIT. However, it would not surprise me if about 70% of JIT CVEs are memory safety bugs. The trend for unsafe Rust so far seems to be very similar BTW (about 70% of unsafe Rust CVEs are memory unsafety--contrasted with virtually no non-unsafe Rust CVEs that are memory unsafety, and all that were are due to compiler bugs).
The overall trends tell me that in the absence of a proof assistant, however carefully you scour your code for bugs, you will miss some. And 70% of the ones you miss will be memory unsafety unless you are using a system that explicitly prevents this.
There have been a few other studies besides those two pointing to the 70% figure. It seems to be a curiously persistent figure, and I agree that it's not just about C++.
No, that is a different statistic from the one I’m talking about. The one I’m talking about was a survey of security bugs in Firefox, including the private ones. This one (and the Microsoft one) show an even higher number!
I'd imagine the great majority of security work happens in the JS engine, because that's what executes foreign, turing-complete code from every site you visit (natively via JIT, even). So one option would be to simply use V8, and only build the other subsystems from scratch. Performant (and complete) JS interpretation is probably going to be the hardest thing to implement anyway, before you even get to the security concerns.
I do not think this is really much of a concern in practice. Nobody would bother to attack a browser that isn't popular (unless it is used by someone who is a target themselves, but the attack wouldn't be for the browser but for the target and the chance of others being affected will be very very low) and by the time the browser becomes popular it will also have attracted a developer base and pairs of eyes large enough to have those bugs fixed.
Remember the claims about Mac OS X security back in the early 2000s? Mac OS X wasn't secure because it had no security issues, it was secure because nobody bothered to attack it. As it became more popular (and it had to become very popular compared to what it used to be, which took several years by itself), it also attracted people attacking it.
That would be the same story with a new browser. Or anything new and obscure for that matter.
Right, I feel like any new desktop browser that is aiming for wide adoption needs to be (for example) multi-process and privilege-separated from the start. Rust certainly makes some bugs impossible that this sort of sandboxing prevents, but not everything.
Designing these sorts of security features up front isn't fun, and makes it take a bit more time before you get to your first page render, so there's a lot of slogging to do before you get there. I can understand how someone might lose motivation that way.
As unlikely as it may seem, I can well imagine that a dedicated team produces an alternative browser that - feature-wise and functionally - is good enough for daily use for most people. For the life of me, I cannot imagine they will come up with a browser that is as secure as Chrome.
Let's face it the amount of work and money that has been put into Chrome's security is amazing. As much as I love Rust and how it helps us write more secure software, it only gets us so far when it comes to the multiple threats a web agent implementation has to face.