167 karma · joined December 20, 2014
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.
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).
That one is indeed because most of those things are opaque to qutebrowser. They're handled by the underlying QtWebEngine/Chromium, and only for a few of those things there's a way for qutebrowser to delete them. There's an issue about it here: https://github.com/qutebrowser/qutebrowser/issues/58 - but many things probably can't be done, or only in a hackish way (e.g. by qutebrowser reading/manipulating those internal Chromium files, before it starts up fully).
You can however remove ~/.cache/qutebrowser and ~/.local/share/qutebrowser/webengine/ manually.
> The ultimate goal would be some way to replace the functionality of "Temporary Containers" or alternatively "Cookie Autodelete" (you keep all the history, but everything else is in Incognito mode except for whitelisted sites.)
Via qutebrowser's `--temp-basedir` (or `--basedir`) flag, you can already start an isolated instance - but indeed the history won't be shared with the main instance (and neither will e.g. the config, but there's the --config-py flag).
There are also some "profile managers" which are based on the `--basedir` flag: https://www.reddit.com/r/qutebrowser/comments/l6zj0z/compari...
Finally, I'd indeed like to have a container-like feature integrated into qutebrowser itself in some way: https://github.com/qutebrowser/qutebrowser/issues/4102 - automatically switching containers based on the URL unfortunately won't be possible, but I think even just launching a new window with a different storage path (i.e. profile) would provide a lot of value.
> Can't disable WebRTC (= unique device id can always be tracked)
I think to fully disable it, you'll need to rebuild QtWebEngine. As far as I know, this is a Chromium limitation. Can you elaborate on "unique device id" though? I'm only aware of WebRTC leaking internal IPs, which can be prevented via the `content.webrtc_ip_handling_policy` setting.
> Great project, keep it up :)
Thanks for all the feedback, I really appreciate it!
There aren't really many alternatives. The main one is WebKitGTK, but that comes with its own set of issues (mostly performance/compatibility). You can use qutebrowser with QtWebKit as well, but I wouldn't recommend it - it's based on a 2018 WebKit with many known security issues: https://github.com/qtwebkit/qtwebkit/releases
I had hoped for Servo to fill that gap at some point, but so far that hasn't happened yet: https://github.com/servo/servo/issues/27579
Another possibility is for Geckoview to be ported to Desktop platforms some day: https://mozilla.github.io/geckoview/ - something the people behind Tridactyl would like to happen: https://tridactyl.xyz/ideas/#port-geckoview-to-x86_64
> and Qutebrowser privacy related settings also seem quite limited compared to Firefox... (and even compared to Chromium.)
Can you be more specific? Pretty much anything that's possible to expose (either via a QtWebEngine API or via Chromium commandline arguments) is exposed. Certain things (like deleting cookies belonging to a tab when it's closed) just aren't possible without implementing them in QtWebEngine first unfortunately.
FWIW there's an overview here: https://github.com/qutebrowser/qutebrowser/issues/4045
> I wonder if it is worth it to fork an existing browser (Chromium, Firefox) for your purpose. But this is probably impossible to maintain and keep in sync with upstream.
Yeah. People have suggested that in the past, but keeping up with e.g. Chromium is insane. When QtWebEngine updates their Chromium snapshot (a subset of the entire source) all couple of months, we're talking about millions of changed lines, and I've heard they need around a person-month every time to adjust their stable API to that.
Also see:
- https://chromium.googlesource.com/chromium/src.git/+log - https://twitter.com/the_compiler/status/1330896103911264257
It's pretty much a commit all couple of minutes, almost around the clock.
> I wonder whether there are other simple ways to hook into the browser. After all, you are in control of the OS, and you can inject some code. On MacOSX, there was actually some nice way to script things like this. But I think they restricted that very much now.
I was actually wondering what someone could do via ChromeDriver: https://chromedriver.chromium.org/
But I suppose the kind of UI/UX you could build with that would still be quite limited, perhaps even more so than what WebExtensions like Vimium or Tridactyl can do.
Looks like it started in 2012, but I've never heard about it until a recent plan from Qt to write a wrapper around it:
https://lists.qt-project.org/pipermail/development/2021-Janu...
(Probably so that simple things like their help viewer don't need a rather heavy QtWebEngine)
I'm afraid it seems pretty much dead at this point... Looking at https://github.com/KDE/falkon/commits/master there's only a (non-automated) commit all couple of months or so. Also see https://github.com/KDE/falkon/graphs/contributors
I've updated the related issue earlier this week though: https://github.com/qutebrowser/qutebrowser/issues/5359#issue...
FWIW, saving isn't the problem - restoring a tab's back/forward history from the saved file is.
Another possibility is for Geckoview to be ported to Desktop platforms some day: https://mozilla.github.io/geckoview/ - something the people behind Tridactyl would like to happen: https://tridactyl.xyz/ideas/#port-geckoview-to-x86_64
I had hoped for Servo to fill that gap at some point, but so far that hasn't happened yet: https://github.com/servo/servo/issues/27579
Another possibility is for Geckoview to be ported to Desktop platforms some day: https://mozilla.github.io/geckoview/ - something the people behind Tridactyl would like to happen: https://tridactyl.xyz/ideas/#port-geckoview-to-x86_64
However, the new built-in adblocker does a big part of what uBlockOrigin does. As for uMatrix, there's https://gitlab.com/jgkamat/jmatrix (though it's a rather unofficial hack, and I have no idea if it still works with v2.0.0).
I'd really like to integrate something uMatrix-like (with nice keyboard usage) into qutebrowser some day, but so far I didn't get around to it: https://github.com/qutebrowser/qutebrowser/issues/28
It's a bit of a pain to set up, but it should be possible to get it to work. Basically, you'll need to get an older Chrome version (corresponding to whatever Qt version you're running), extract the needed .so files from there, and then put them in the right place so QtWebEngine picks them up. Unfortunately, there's almost no feedback when it doesn't work.
Here's a rough guide: https://www.reddit.com/r/qutebrowser/comments/jwb90w/how_do_...
Alternatively, someone there reported installing Google Chrome on the same system did help.
https://github.com/qt/qtwebengine/blob/v5.15.2/src/core/cont...
So that flag is only needed if the file is in some strange place (like I'm guessing is the case on NixOS).
In my day-to-day work, I only use Linux - so the Windows/macOS releases are pretty much "best effort" I'm afraid, until someone steps up to fix platform-specific issues there.
I'd really like to integrate something uMatrix-like (with nice keyboard usage) into qutebrowser some day, but so far I didn't get around to it: https://github.com/qutebrowser/qutebrowser/issues/28
As for password managers, as someone already mentioned in another reply, there are userscripts: https://github.com/qutebrowser/qutebrowser/tree/master/misc/...
It's... challenging sometimes, but still working surprisingly well overall.