If you configure Firefox to run in private browsing mode permanently and remove all the Google and Mozilla services aren't you pretty much there? Maybe add something random to the user agent to throw off sites using fingerprinting
In the case of gngr, it can't even render Reddit or Google.com correctly. Can you imagine how badly it breaks on more complex sites? Can you imagine how broken its core is?
Diversity is good, but it requires resources, lots of them.
Compatibility is a slog, but it's a doable one. Remember, to be usable on a lot of real-world sites you don't need to catch up with Firefox Nightly or Chrome Canary - you only need to catch up with IE6, or maybe IE8.
Of course, I'm also disappointed that they didn't choose to build their browser on Servo instead. ;)
There is quite some diversity, since unlike basically any other technology of comparable complexity there are already three fully independent browser implementations, with a fourth one (servo) coming. But they are not fully compatible and will never be, which is why every website has to be tested and adapted slightly for each engine.
Even more diversity will actually weaken the web as a platform, not strengthen it. So, no, it is probably not a good thing if taken too far.
And, besides, how likely is it that this particular implementation will ever come close to the existing ones in terms of compatibility? Highly unlikely.
Not for the goals of this project, no. All existing browsers, including Firefox and Chrome, are large C++ codebases with histories going back to the 90's. This project wants to use a safer language, in this case Java - which would avoid the large amount of vulnerabilities we see in C++ codebases that are not possible in Java. The Servo project is writing a new browser in Rust for similar reasons.
It's true that running in private mode, disabling services and features, etc., can get you a lot of security in one sense. But there is another sense of security in which C++ is imperfect.
Just having a Java interpretor installed on your system opens you up to untold security threats.
Honestly, it sounds a lot more like the majority of the software people on this project simply liked/knew Java, rather than made a informed choice of Java based on security considerations.
Not Java-bashing, it just the whole "C has pointers, pointers are not-safe, thus C is not safe, while Java has not pointers, and thus is safe."
Has somebody actually compiled statistics of the relative frequency of security threats in respect to language in which they were written.
That's not the case at all. A Java interpreter doesn't run with any kind of privileges, so it adds no added security threat above those that already exist when you are able to run code as a user. Having it installed is no more dangerous than having libboost or python installed on your system, if you have any kind of sane setup.
The part of Java with a bad security track record is the applet sandbox, which is supposed to make it safe to run arbitrary code in a browser. The sandbox has turned out to be pretty leaky. So I would not recommend relying on the applet sandbox to run arbitrary untrusted Java code from the internet. But for a local app it's a perfectly reasonable platform (vaguely in the same category as Microsoft's CLR, which is heavily JVM-inspired).
However, Java does avoid memory corruption errors which are sadly easy to create in C and C++. We see exploits of such things all the time. It does make sense to use a language like Java or Rust (or C# or JavaScript - basically, any modern sandboxed language) for that reason.
But yes, Java specifically has seen plenty of exploits, and that is a cause for concern.