I wish I could have the best of all worlds here - a minimal browser like qutebrowser but also built on the latest Chromium (or whatever engine you prefer, something built on Servo would be cool) but sadly even the qt5-webengine backend is stuck back in Chromium 65.X which was released at the very beginning of this year
To be fair, I've not done enough research to KNOW whether or not that poses any real security risk but it's still a concern. There's also the FOMO that I'm missing some modern browser features that I can only test out in other browsers :/
It's OSS though, so I should probably shut up and roll up my sleeves
While the Chromium version in QtWebEngine only gets updated for major releases (all ~6 months), they do backport security fixes. The latest 5.11.2 release comes[1] with fixes up to Chromium 68.0.3440.75, and the upcoming 5.12 release (scheduled[2] for November) updates[3] the baseline to Chromium 69.
It's a bigger issue if you're on a distribution like Debian Stable, which ships an ancient Qt version without security updates[4]. There, you get Qt 5.7.1 based on Chromium 49 (2016-03-02) with security fixes up to 54 (2016-10-19)... I'll probably drop support for that soon even if it's annoying for some Debian Stable users, but people really should stop using such old QtWebEngine versions.
Missing web features usually isn't much of a problem in my experience, as most sites still wait a bit before they start using them.
FWIW I agree something based on Servo would be cool, and as soon as there's some project making Servo embeddable from Python with Qt integration, I'll get my hands dirty to at least have a proof of concept!
Considering that 5.12 is an LTS release, they are evaluating to separate WebEngine from the normal QT release cycle.
> This is still under research, but there seem to be quite tangible benefits from carving out Qt WebEngine to a separate item. Current thinking it that as a separate item we should be able to release Qt WebEngine every three months, following nicely the schedule of Chromium releases every six weeks. For Qt 5.12 LTS users this would mean the possibility to get not only the security updates, but a full new Chromium version supported on top of the long-term-supported release of Qt.
The main thing that I miss when using Qutebrowser is extensions.
On Chrome I rely on 3 extensions: 1Password, uBlock Origin and Vimium. I obviously don't need Vimium on Qutebrowser. I could possibly get by without 1Password if I switched to something like Pass. However, I can't give up uBlock Origin. I run it in "medium mode" (3rd party frames/js blocked by default) and I can't give this up.
I would pay decent money to be able to run uBlock Origin on Qutebrowser.
qutebrowser comes with a built-in adblocker, but that's quite basic (it only blacklists hosts, like a /etc/hosts file would).
I'd absolutely like something like uMatrix in qutebrowser (see [1]), and since I recently started work on a plugin API[2], that'll hopefully happen soon-ish.
As for password manager integration, check qutebrowser's userscripts[3] (which are unrelated to Greasemonkey scripts), but a plugin API should provide a better foundation for that as well.
I'm a happy qutebrowser user, too; but I too would've liked some password manager integration (to the point where I considered investing some time into the Keepass RPC API, since that's my pwd manager of choice).
I really like the suckless approach to GUIs in this case. Yes, you don't get stuff like automatic url matching with this, and you have to manually add new entries, but its functionality is works great for me nontheless.
Maybe, there's also an easy way for you to get (or write) a dmenu interface for 1password?
> but sadly even the qt5-webengine backend is stuck back in Chromium 65.X which was released at the very beginning of this year
Good shout, I did not realise this, however the last release (5.11.2) was relatively recently in June... however I can't find release details for qtwebengine, where are you getting your release information from RE chromium?
This was the main reason I was attracted to this browser because the old webkit2 based vim-like browsers were hopelessly out of date to point of being very dangerous.
Yeah, they don't call out what version they're on without some digging. I had to actually download the browser and check manually
> This was the main reason I was attracted to this browser because the old webkit2 based vim-like browsers were hopelessly out of date to point of being very dangerous.
Same here. I had to forgo other browsers I quite like because of their older versions of webkit
If the user-agent string is to be trusted the latest version released in June is still based on chrome 65.x like you said... :/ it's not terrible but not great either.
However they do claim to backport security patches on their front page so it should technically be secure.
I suppose it would take a lot of repetetive effort going through the same process to pull apart chromium each major release, so perhaps they settle on backporting patches in between larger breaks.
Yeah, I recall them saying they need something like two man-months for each Chromium release to adapt (the changed lines in the imported Chromium source is usually somewhere around a couple of million...).
With 5.12 today you get Chrome 69, but your point is valid. I use CEF [0] because it tracks closely with Chromium release timelines/versions so I'm never far behind on security fixes unless I'm lazy. With a bit of plumbing, it works with Qt just fine.
I have considered using CEF as well (via cefpython), but the main deal breaker was that it isn't packaged anywhere - so I'd need to ship my own copy of it with qutebrowser, which is usually not something you can do with Linux distribution packages.
But you can't rely on any external entity's free service. Spotify are a great example of an org who'll deprecate it (if you are lucky) this week and then shut it down the next. Or maybe suddenly change it underneath you. If you are going to do this you must be able to build and host it yourself. And that's the hassle that was alluded to.
I don't rely on it, I leverage it because it's there. Of course I can build it and host it myself. But when compiling Chromium, prebuilt libs have value for quick iteration.
Note the "Linux distribution packages", as in "your application being packaged by Linux distributions". That's pretty much not going to happen if you ship your own engine.
Could you elaborate why you'd prefer shipping it with the browser rather than sharing it?
Because I'm the only one using it, it occassionally has backwards incompatible API changes, most browsers ship with their own engines, it has a compilation step anyways for the wrapper, it is self-contained, etc. How do these packages ship Chrome or FF? They don't make them ship Blink or Gecko as shared system-wide libs IIRC. My browser is no different. (now, Qt on the other hand, is a different story, like Gtk or whatever)
Chromium and Firefox are kind of an exception there, as they are big enough for distributions to justify bundling the engine, and they are also the upstream projects where those engines are developed.
It's kind of irritating that we're always trying to keep up with the latest version. In a way, it's actually putting the power into their hands. Making it easier for them to get away with sleazier stuff because the majority are on the most recent version.
And because everyone's on the latest version, it's harder for individuals to downgrade or stay on old versions for longer without getting obsoleted.
It's actually closing the web. The excuse for aggressive upgrades & auto-updates are mainly for security purposes, with the side benefit of reducing the work of web developers. But on the flip side, it's actually huge centralization move.
To be fair, I've not done enough research to KNOW whether or not that poses any real security risk but it's still a concern. There's also the FOMO that I'm missing some modern browser features that I can only test out in other browsers :/
It's OSS though, so I should probably shut up and roll up my sleeves