What is gngr?

gngr is a new browser that is currently under active development.

Why another browser?

Creating a browser is a Herculean task and there are several implementations already. Why are we creating a new browser then?

The rise of tracking and fall of privacy

These days, even the simplest of websites is more than a collection of web-pages. It often includes third-party trackers, traffic-analysers, ad-services, feedback-gatherers and what not! The combined power of cookies, javascripts, user-agent identifiers and referrers allows these third-parties to track you and your browsing habits.

The looming power of Javascript

Although Javascript is sandboxed, there are subtle vulnerabalities that it enables. For example, tab nabbing can be easily implemented with a little Javascript.

Further, scripts can steal your CPU cycles and network bandwidth (for example, to mine bitcoins surreptiously).

gngr has conservative defaults

gngr by default disables cookies, Javascripts, referrers, third-party frames and has a minimalistic UA string: "gngr.info/major-version".

All of the above settings will be configurable with a unified and intuitive interface, globally and per-site.

What about extensions like NoScript or uMatrix?

While these are excellent projects and we appreciate the effort being spent into them, at the end of the day, extensions are a band-aid. They might miss some requests due to API changes in the browser or because some requests are made behind-the-scenes. We think privacy is critical functionality that should be designed and built right inside the browser.

Moreover, plugins introduce a third-party into the equation. Wasn't it a little surprising to know that a plugin intended to improve privacy was collecting and selling information to advertisers!

Update: We are compiling a list of extensions and their known limitations in this wiki page.

What about privacy focussed forks of existing browsers?

Yes, this could have been a possibility and there are some promising forks already. (We haven't done extensive research on them; use at your own discretion). (Update: We removed the links to the forks. On closer look; they have been releasing binaries without releasing their source-code for a long time. The links were to forks called Epic and Iron)

However, there is another problem with existing browsers; almost all of them are implemented in low-level languages and their code runs natively. This exposes the browser to vulnerabilities and makes auditing harder. Which brings us to the next topic...

The virtues of the Java-runtime

The Java language tends to be ridiculed because of its verbosity. The Java runtime, on the other hand, has some well designed and rare features, though it is often overshadowed by its popular sibling.

We believe that the Java-runtime is a great fit for our project because:

• We get sandboxing for internal modules. More on this below.
• We get instant portability! From legacy Windows systems to the newest Linux distro, from 32bit x86 to 64bit ARM, our code runs everywhere! (Atleast, that's what it promises)
• We get memory safety and type-safety! It is impossible to de-reference a null-pointer, access unallocated memory or type-cast an object to the wrong type.
• We can benefit from JIT optimisations.

Sandboxing

The Java runtime has a neat but little known feature called the Security Manager. Once a security manager is installed, any significant operation such as file i/o, network i/o or execution of native code, is audited. If the currently executing code stack doesn't have the requisite permission an exception is thrown. Every piece of code is assigned a protection domain (based on the location from which the code was loaded).

This mechansism allows code modules to be sandboxed. For example, the CSS parsing library that we use isn't given any permissions. It can't make any network requests nor can it read/write from the file system. Which means auditing our code is easier; there is very little surface area that needs to be covered when manually checking for vulnerabilities.

Why did you choose Java-the-language?

That is a short-term choice based on circumstances; mostly a lack of resources. We plan to migrate to a more concise JVM based language soon. We are considering Scala, Kotlin and Ceylon.

What about Servo and Rust?

These are great initiatives and we are keeping an eye on their progress. From what we understand, Rust will help avoid a number of vulnerabilities at the language level, but will take some time to mature. Moreover, there is nothing equivalent to the Java-runtime in Rust-land. Compiled code is run directly on the bare machine. Sandboxing will have to be implemented using an external mechanism, which will take even more time to mature.

Servo might help improve layouting and rendering performance for very large websites through parallelisation. Similar parallelisation might be also possible in JVM land, but perhaps not with the same safety guarantees. This needs more investigation. However, there are many other opportunities for parallelisation; browsers are embarassingly parallel.

Whereto from here?

Update: December 2014. Our first release is out and you can try it from the download page. Please follow our blog to be notified of updates.