Discussed quite recently so the current post is probably a dupe.

Qutebrowser 2.0 - https://news.ycombinator.com/item?id=25940453 - Jan 2021 (128 comments)

Also, while at it:

Qutebrowser – A keyboard-driven, Vim-like browser based on PyQt5 - https://news.ycombinator.com/item?id=18070367 - Sept 2018 (107 comments)

Qutebrowser – a keyboard-focused browser with a minimal GUI - https://news.ycombinator.com/item?id=15458824 - Oct 2017 (91 comments)

Qutebrowser (vim-like web browser) Kickstarter: v1.0 and per-domain settings - https://news.ycombinator.com/item?id=14202843 - April 2017 (3 comments)

Qutebrowswer: Browser with Vim-like UI - https://news.ycombinator.com/item?id=11634683 - May 2016 (4 comments)

Qutebrowser – a keyboard-driven, vim-like browser based on PyQt5 and QtWebKit - https://news.ycombinator.com/item?id=8774609 - Dec 2014 (11 comments)

I looked up the obvious stuff: process isolation and sandboxing, fully expecting not to find any good info on that or security support/lifecycle. Instead, this actually seems pretty interesting. https://qutebrowser.org/doc/faq.html

"Most security issues are in the backend (which handles networking, rendering, JavaScript, etc.) and not qutebrowser itself.

qutebrowser uses QtWebEngine by default. QtWebEngine is based on Google’s Chromium. While Qt only updates to a new Chromium release on every minor Qt release (all ~6 months), every patch release backports security fixes from newer Chromium versions. In other words: As long as you’re using an up-to-date Qt, you should be receiving security updates on a regular basis, without qutebrowser having to do anything. Chromium’s process isolation and sandboxing features are also enabled as a second line of defense."

In Debian, libqt5webengine5 is security-support-limited:

> qtwebengine-opensource-src No security support upstream and backports not feasible, only for use on trusted content

The fact that Firefox and Chromium are kept up-to-date with security patches represents a carve-out from the normal Debian security process (ability to build without fully packaging the dependencies).

This may also be partly related to Qt's security backports only existing on commercial LTS branches and not the public LGPL branches.

> This may also be partly related to Qt's security backports only existing on commercial LTS branches and not the public LGPL branches.

The 5.15 LTS branch for QtWebEngine is still public: https://code.qt.io/cgit/qt/qtwebengine.git/log/?h=5.15.3 https://code.qt.io/cgit/qt/qtwebengine.git/log/?h=5.15

The 5.12 LTS (supported until the end of the year) also is public, for all of Qt.

Debian/Ubuntu just don't seem to care enough about security issues in QtWebEngine to keep it updated (it can be combined with an older version of Qt itself, so that wouldn't be an issue, at least in theory).

I didn't look too closely at the code, but have written a toy browser in just this way.

The problem is that QT on targets rarely gets updated, at least not as fast as Chromium.

I had the misfortune of targeting old RHEL systems, whose QT was missing a lot of what I needed.

So then you get into the game of compiling QT yourself, and in my case having to compile python as well, etc. It turns into a real mess.

I imagine modern desktop systems are a bit better today, but am curious how the author solves that(if at all).

Something like Docker existing at the time probably would have been a huge help.

I unironically love this browser and use it on my arch setup, but it uses QtWebEngine (based on Chromium) which doesn't support chrome extensions. As someone who uses lastpass for everything, it's a bit frustrating. I've had to learn how to use the lastpass CLI for everything.

If QuteBrowser supported chrome extensions it would be the perfect browser.

I hope you've moved away from LastPass (like many of us) following their recent changes to their pricing and free tier.

Would recommend BitWarden as an alternative.

BitWarden won't fix my QuteBrowser issue :( and I've written lastpass bash scripts for sites I use on my arch partition (typically aws etc) so I'm a bit invested in lastpass. Not sure if it's worth $30/year for me to change things.

You might be interested in the qute-lastpass userscript: https://github.com/qutebrowser/qutebrowser/blob/master/misc/...

Text based one is great. Not all the times. But text and keyboard is good enough for many. GUI and user friendliness with with training is great. As they said in 1980s. But there are still niche for text as it is faster without jumping to mouse.

Use text browser in linux old days. Or many text editor are keyboards oriented. ... hope the niche still be persevered. May be one can even has text script.

(Still those windows click click for system administration is a horror to check and confirm, a reality one accepted but if one has a choice. )

How qute :) alternative browsers are awesome.

next gen browser for hackers who can handle a learning curve. The-Compiler is my hero.

:)

I switched from Firefox + Chromium to Qutebrowser a few weeks ago. So far it is really nice. Since QtWebengine is Chromium-based and is a relatively recent version of Chromium, it works very well with all sites so far, vastly better than the older QtWebkit version I tried a year ago.

I hope that someone will write a Qutebrowser version of Bypass Paywalls [1].

I also find that the Qutebrowser's ad blocking is a bit underwhelming compared to uBlock Origin, with a lot of ads getting through or being incompletely blocked, although work is being done on that [2].

The password filling scripts are also hit or miss but I just copy my passwords from the terminal using `pass`.

[1] https://github.com/iamadamdev/bypass-paywalls-chrome

[2] https://github.com/qutebrowser/qutebrowser/issues/5754

Make sure you're using the adblocking based on the Python "adblock" library - :version will tell you whether it's available.

With that library, the main missing thing is element hiding (cosmetic filtering). Without it, qutebrowser automatically falls back on host blocking, which is much worse.