Fifth Browser | Hacker News Reader

Fifth Browser

github.com

66 pointsapp4soft21 comments

Better link: http://fifth-browser.sourceforge.net/

(Though it does include a gratuitous and poorly-executed 3.3MB animated GIF of 43 words: “Who should control your web? / Not the advertisers / Not even the site designer / You // Browsers should / stay out of your way / avoid change for change's sake / not copy Chrome just because // Avoid monitoring / Web for sites, not apps / Stay lean // Fifth / Join us”.)

Last release almost six years ago.

> Last release almost six years ago.

Last commits pulled in on November 8, 2020.[0]

[0] https://github.com/clbr/fifth/commits/master

> SSL certificates handled in a SSH-like manner

> CAs are ignored, the only thing that matters is that the cert does not change. With today's rogue CAs and governments, this policy is better suited for detecting man-in-the-middle attacks than a browser blindly trusting a CA.

I'm not sure this is a good idea. SSH best practice is that you acquire the server's key fingerprints via a previous secure channel. E.g., Hetzner will email them to you when they set up your server.

It would be nice to merge the two approaches.

-Attest a CA for initial connection

-Alert on change, include CA details, with option to (not) override cache

Will this browser make it into EPEL?

IMO, HSTS handle it better

Don't worry. If I'm following the code correctly, then the definition of "the certificate changed" is "either the issuer name, notBefore, or notAfter fields change." Unless you are Google, Cloudfare [1], or the issuer is Let's Encrypt, in which case that check isn't bothered with as those sites update too frequently. No need to worry about, let's say, the public key possibly different. I'm not sure how much of the rest of the certificate process is being done (e.g., making sure that the cryptographic signature is valid), since I'm not savvy on OpenSSL's APIs to know what you do yourself and what OpenSSL does for you.

Even for a TOFU implementation of SSL, this repository is amazingly bad.

[1] Yes, those site names are hardcoded. By server name. So anyone could MITM google here. Or cdnjs.cloudfare.com.

> I'm not sure this is a good idea. SSH best practice is that you acquire the server's key fingerprints via a previous secure channel. E.g., Hetzner will email them to you when they set up your server.

email != secure channel

DKIM provides integrity, which is what is important here.

DIY/Open source is cool in that everyone gets to scratch their own itch, but…

I wouldn't want to bet my web experience on a browser maintained by a small team of volunteers diverging from a known engine. Seems like it would be easy to end up in a state where modern features are unavailable or security vulnerabilities are unpatched, because some dude on the Internet prioritized his own life over being the maintenance guy for your browser.

I do agree that most projects end up like this sadly. But the ones that do have some sort of sponsorship or donation or revenue stream. Have financial incentive to actively maintain and develop opensource projects. This of course has its own problems but overall better for the users i think.

I agree. I'm guessing over time we will see the layering of the browsers improve so eventually maintaining the browser engine updates needs low maintenance, mostly just bumping version numbers.

Until then these browsers will be just nice toys for random browsing, but dangerous for more sensitive things like banking or buying things online.

>nice toys for random browsing, but dangerous for more sensitive things like banking or buying things online.

Wouldn't it be the other way around? I personally am more afraid of some random site exploiting an vulnerability on me than my banking site exploiting a vulnerability on me.

I think most exploitable vulnerabilities live in the WebKit, so the outer UI matters less in this regard.

OTOH a number of sensitive things, such as TLS certificate handling, or custom extensions, is external to WebKit, and may be exploitable.

The chances an exploit would be developed especially for a narrow-niche browser like Fifth are pretty slim, though. Some security through utter obscurity.

Here is Phoronix' article about Fifth from 2014.[0]

And on official site there is "Propaganda" page with comparison to other browsers.[1]

[0] https://www.phoronix.com/scan.php?page=news_item&px=MTg0MDk

[1] http://fifth-browser.sourceforge.net/propaganda.html

So "invoking the fifth" has a new meaning on Linux?

What's the purpose of sharing this abandonware?

The title should be tagged with 2020, given the last commit was back then.

It’s hard to imagine why any recent project still use autoconf.

It isn't recent

From a user's (or at least, builder's) perspective, autotools have the nice property that they work pretty much everywhere without requiring any additional tools than some shell and some make while also understanding a ton of standard-ish (well, they are part of GNU standards anyway) configuration options in terms of where to build something, where it would install, where to copy the files, etc.

I tend to build a lot of programs from source code and those that use autotools are always the most frictionless, especially since i like to put things in their own directories (so that i can easily remove them) instead of installing them globally.

From a developer's perspective, i tried to use autotools at some point and i really wish there was a real replacement that provides all the features autotools have (including not requiring to have that replacement installed, like cmake, meson, etc do) while being a bit more user friendly.

It's hard to imagine which build system is better than autotools. So far the others got from a half to a tenth of its features.

Reply on news.ycombinator.com