> 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.
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.
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.
(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”.)
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.
21 comments
[ 0.22 ms ] story [ 55.4 ms ] threadAnd 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
> 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.
-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?
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.
email != secure channel
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.
Until then these browsers will be just 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.
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.
(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 commits pulled in on November 8, 2020.[0]
[0] https://github.com/clbr/fifth/commits/master
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.