Qutebrowser
qutebrowser.org
qutebrowser.org
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)
"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."
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.
> 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.
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).
If QuteBrowser supported chrome extensions it would be the perfect browser.
Would recommend BitWarden as an alternative.
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. )
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`.
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.