[The-Compiler]

The majority of security issues in browsers is in the more low-level components (rendering engine, sandbox, network stack, JS runtime, etc.). None of those small browsers implement any of that themselves, they either build on top of WebKit (e.g. via WebKitGTK, like Luakit), or on top of Chromium (via QtWebEngine like qutebrowser, or via Electron like Vieb).

So you'll mostly need to focus on keeping that up to date. Some distributions (Debian/Ubuntu for example) unfortunately do a bad job at that, but you can also quite easily install them as a binary from upstream.

You still will lag behind a bit on security fixes compared to Chromium directly, that's true. In the case of QtWebEngine, they backport security fixes to the next patch release, and I know of some distributions (I think it was Fedora?) that continuously backport those before Qt releases.

That leaves you with any security issue that's e.g. in the UI, or anything that's in the browser code itself.

For the former, I believe browsers aimed at more technical users can select different tradeoffs that make things more secure (e.g. qutebrowser always shows the punycode-encoded version of a URL if there's non-ASCII in it, while big browsers try to detect whether there are any confusables in it and only show it then - yet new ones are added every once in a while).

For the latter, qutebrowser has had three security bugs in almost 11 years.

[weinzierl]

Unfortunately I don't share your optimism regarding how hard it is to mess up in the upper layers. I also don't think it really is a technical problem.

The question is if we can get a significant number of eyeballs on such a hackable browser. If enough people have a vested interest, security will follow. Without enough users every effort is futile.

I really hate to be harsh to alternative browsers, because they are all we've got right now now, but three security bugs in 11 years says not much if the user base is that small.