Gngr – A new browser championing privacy | Hacker News Reader

Gngr – A new browser championing privacy

gngr.info

55 pointshrjet20 comments

I am not the target audience. Mozilla/Firefox it is for me and while I hate useless Javascript (Hey, blogger.. Great to see a spinner!) I wouldn't want to disable it by default.

But maybe this is a good idea and maybe there is a need for a secure by default browser.

What I don't quite like is the 'low level languages are dangerous' paragraph and then implementing the thing in Java/on the JVM. As far as I'm aware the security record of that platform isn't exactly stellar as well and especially older versions are widely reported to be vulnerable to exploits (admittedly usually using applets as a vector here).

Is the JVM really a great (or decent) choice, if security is the main concern? I truely don't know, so .. honest question here.

> As far as I'm aware the security record of that platform isn't exactly stellar as well and especially older versions are widely reported to be vulnerable to exploits (admittedly usually using applets as a vector here).

Yes, historically, there have been major concerns about security of the JVM platform. Applets (which we don't support) have been a big vector. Also, as per my understanding, there was a transition period when Oracle took over the reigns from Sun, during which security patches were not released as frequently as vulnerabilities were discovered. However, the frequency of patches has increased in recent times.

Moreover, OpenJDK has emerge as a complete open-source implementation of Java. So, atleast in theory, it should be possible for the community to fix the holes and not rely on a single company.

I think the issue with Java has been with applets that are able to escape the sandbox. In other words, with running apps you don't quite trust. That's not an issue here: you are implicitly trusting the browser itself, just like you trust firefox.

So in my opinion, Java isn't inherently worse than a lower level language. (I'm not 100% convinced it's better, though.)

1 - Written behind closed doors and released as a code dump later

2 - Written in Java and running on the JVM

3 - Written by unknowns attempting to tackle arguably the most difficult software endeavor currently feasible

4 - Have absolutely nothing to show for all their talk right now

Keep an eye on servo, disregard this nonsense.

Servo by Mozilla: https://github.com/servo/servo

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

So they want to disable by default every website online? I'm all for innovation but why not just invent a completely new browser that is a better runtime for apps if you're going to disable every website anyway?. Heck, pick a more easily optimizable language than javascript as the default scripting language, have built in GPG so we can throw away passwords, force HTTPS everywhere, use a non-centralized dns like namecoin - why not just go all the way here?

HN itself is perfectly readable without cookies or Javascript.

Even if you want to login, vote, comment, and post, all of that can be done without Javascript (though you do need to at least temporarily enable cookies).

I am really grateful to HN for making this design choice. Javascript is superflous for 99.9% of websites. It's an unfortunate design choice to use it anyway.

I wish I could say that I hope website creators would move away from Javascript and other "dynamic" (ie. turing-complete, overpowered) technologies. But it's clear that's not going to happen.

In light of that, privacy and security tools will have to adapt and somehow find a way to protect their user's privacy and security despite having Javascript enabled.

Right now, the best hope I see for something like that is having light-weight disposable VMs/jails/containers and sandboxes. At least that could limit the damage that Javascript does to a single tab or session.

> Javascript is superflous for 99.9% of websites.

For web sites, yes. For web applications though (of which there are more every day), it's definitely not.

"Superfluous" is not the same as "not necessary in practice" in this case. There are many websites that use JavaScript for polyfills, browser detection, screen detection, and scroll detection. In some cases there are alternatives, but that doesn't mean those alternatives are ubiquitous.

> Heck, pick a more easily optimizable language than javascript as the default scripting language, have built in GPG so we can throw away passwords, force HTTPS everywhere, use a non-centralized dns like namecoin - why not just go all the way here?

We actually do want to implement some of those ideas (and other similar ones)! But we don't believe it is necessary to ditch the existing standards for that. There can be a transitionary period and this (or any other browser) could be a test-bed for new ideas.

> "gngr.info/major-version"

That ... is not minimalistic. Speaking as a person whose browser sends `User-Agent: browser` and `Referer: https://news.ycombinator.com/` (that is, dynamically the root of the requested site). I have never seen anything break because of user-agent, and only a few things because of referer (and more than a few things break when I do send correct referers). I do agree with the going all the way part though; web browsers seem to view security as a afterthought to be bolted on after the fact.

Why not just use lynx/links/w3m?

Given that browsers, especially on mobiles, are now used by every-one, we need a flavour that guarantees blanket security/privacy for users and prevent shooting themselves in their foot. My questions would be, 1. does it have a roadmap to get ported on mobile ? 2. given that browsers are already losing ground to native apps, will ginger make things even worse for mobile developers who want to target browsers ?

1. Java apps are inherently portable, and there is atleast one mobile platform that supports it. We don't have it immediately on the roadmap since our current focus is on the desktop version.

2. Needs more thought from my side, but my immediate response is: this could be solved with better UIs for managing a website's permissions. Perhaps websites could ship metadata about the kind of permissions they require (similar to a mobile app) and the user could "approve" them with a single click (like an app).

Thanks for the mention of our Epic Privacy Browser (fast, secure & private). This looks like an interesting project as well, very ambitious. Java is an interesting choice (I've found it a pain to work in). You should post the names/bios of everyone involved in the project -- I guess it's coming soon.

This category of thing would be nice for situations like servers that rarely and occasionally need to use HTTP to trusted-source websites to lookup some things or download some packages, but doesn't need to do any of the fancy garbage from "modern" websites.

If what you want is a minimalistic browser, don't run a JVM, use elinks! It even has colors: http://4u.1nw.eu/elinks_hn.png

Tor Browser will soon have a slider to regulate stuff like how much stuff is allowed (the current settings will be the lowest on a scale of 5 or so points). This is supposed to help fixing the problem of JavaScript vs fingerprinting when only certain websites are allowed or even worse, running your own "highly secure" settings that make your browser unique from a fingerprinting point of view. Maybe that will be a better option in the long run.

'tis a noble idea, but I don't see this project going very far. I think operating systems suck in general, but I can't just sit down with a couple of buddies and write a new one that competes on all the practical levels it would need to in order to become mainstream.

Well, have fun kids!

Gross java runtime.

Reply on news.ycombinator.com