First release of gngr web browser
blog.gngr.info
blog.gngr.info
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
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.
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. ;)
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.
Little details. Especially, the page doesn't even mention it's a fork of the Lobo project, http://lobobrowser.org which was halted a few years ago. Most of the implementation started before the focus on privacy (even not specifically to this project, mostly as a trend) and all commits in the GH repo seem related to the README.
The complete set of commits, spanning almost an year, from lobo code to the present gngr code is in this repo: https://github.com/UprootLabs/gngrPreHistoric
Yes, it is based on the Lobo browser. You can find a complete list of credits here: https://gngr.info/doc/credits.html (The website isn't hyper-linked well, yet.)
A little background about our goals and motivations: https://gngr.info/doc/introduction.html
Nice idea. Very competitive space, hard to make a dent. Good luck, see you in a year or two!
- So, it's a browser, got some screenshots? What's the ACID test score?
- What rendering engine does it run on?
- Privacy, but no https?
- It's an evolution of the Lobo project apparently?
Conservative defaults and easier to audit since it is implemented in a high-level language / runtime. The runtime (java) needs auditing of course, but that cost is distributed over many projects.
> So, it's a browser, got some screenshots? What's the ACID test score?
For the screenshots you need to scroll down the home-page. ACID test score is probably zero; when we last tried it, it was failing catastrophically.
> What rendering engine does it run on?
We haven't named it. It is a library inside the project. I believe the Lobo project wanted to spawn it of as a separate library called COBRA.
> Privacy, but no https?
It does support https. The bullet point in the roadmap was not clear: we need to take it beyond "it works; let's ship". We need to properly configure the networking library (okhttp) with the correct cipher-suites and fallbacks, for example.
> It's an evolution of the Lobo project apparently?
Yes, our credits page lists all the details: https://gngr.info/doc/credits.html
> process isolation architecture
At the moment, it is module isolation rather than process isolation. It leverages the Security System of the Java Runtime.
Process isolation would help too but that's not on our immediate roadmap for lack of resources.
A very brief look at the source code turns up mention of lobobrowser, a Java project that seems to have stalled about 5 years ago...
I do understand that the purpose of this browser is to be privacy-first, but what we don't need is a new browser that's just like IE6 in terms of bad web practices but with better privacy settings.
Always happy to see a new browser enter the fold. How is development funded right now?
Currently, the development is sponsored by a for-profit company, and we plan to accept financial contributions to the project soon. We realize that backing by a for-profit company may not be perceived well for a project of this sort, but we believe that's currently our best option; it allows us to sustain the project through multiple avenues of income. Eventually, we would like to spawn it off as a non-profit when we have the bandwidth and the critical-mass.
I just can't take java software seriously these days. Sorry. It's not you, it's me.
I just searched through the FreeBSD ports tree's list of java software and I can't find any that I would ever need.
I can, however, say my experience with java software in the last 15 years has consistently been negative. Every vendor provided software product that was java based has been especially painful. A recent example: I'm looking at you, Ubiquiti. (Who also uses MongoDB which requires manual intervention for crashed databases -- unacceptable to not be using an ACID database)
Java is just more noticeable. It's the new client-side business app platform, and there are a ton of UI toolkits that scream "This is a Java app!"
But on the other side of the token, some of the best software I've used has been written in Java. Tons of Android apps, along with all the JetBrains IDEs (I love PyCharm), and Mirth Connect - software for processing HL7 that one of my company's products relies on heavily.
Also, I think android at least sort of qualifies.