5 ms·

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, somet

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

tomxor 8y ago
> 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.
- igneo676 8y ago
  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
  - tomxor 8y ago
    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.
    - The-Compiler 8y ago
      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...).
      - tomxor 8y ago
        > the changed lines in the imported Chromium source is usually somewhere around a couple of million. Yeah that sounds truly horrifying, I guess they must employ some degree of automation though.
- The-Compiler 8y ago
  It's in their documentation (but a bit hidden): http://doc.qt.io/qt-5/qtwebengine-overview.html#qt-webengine-core-module http://doc.qt.io/qt-5/qtwebengine-overview.html#qt-webengine... (This version of Qt WebEngine is based on Chromium version ...). I usually check their script, which also lets you switch between versions easily: http://code.qt.io/cgit/qt/qtwebengine.git/tree/tools/scripts/version_resolver.py?h=5.12#n41 http://code.qt.io/cgit/qt/qtwebengine.git/tree/tools/scripts... And I also have an overview here: https://github.com/qutebrowser/qutebrowser/blob/master/qutebrowser/utils/version.py#L309 https://github.com/qutebrowser/qutebrowser/blob/master/quteb...
drakenot 8y ago
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.
- sandov 8y ago
  Have you thought about using your hosts file to ads?
  - The-Compiler 8y ago
    qutebrowser has a hosts-based adblocker built in, so that probably won't make a big difference.
- skidd0 8y ago
  I saw this in the qutebrowser quick start page: Run :adblock-update to download adblock lists and activate adblocking
- The-Compiler 8y ago
  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. [1] https://github.com/qutebrowser/qutebrowser/issues/28 https://github.com/qutebrowser/qutebrowser/issues/28 [2] https://lists.schokokeks.org/pipermail/qutebrowser-announce/2018-September/000051.html https://lists.schokokeks.org/pipermail/qutebrowser-announce/... [3] https://github.com/qutebrowser/qutebrowser/tree/master/misc/userscripts https://github.com/qutebrowser/qutebrowser/tree/master/misc/...
- btschaegg 8y ago
kodablah 8y ago
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. 0 - https://bitbucket.org/chromiumembedded/cef https://bitbucket.org/chromiumembedded/cef
- The-Compiler 8y ago
  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.
  - kodablah 8y ago
    > 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. You definitely can. I do: https://cretz.github.io/doogie/ https://cretz.github.io/doogie/. Prebuilt versions are available at http://opensource.spotify.com/cefbuilds/index.html http://opensource.spotify.com/cefbuilds/index.html. In fact, I'd say shipping with the browser is ideal for a few reasons. It's not a lib that should be shared across the system IMO.
    - The-Compiler 8y ago
      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?
      - kodablah 8y ago
        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)
fouc 8y ago
What's wrong with Chromium 65?
- The-Compiler 8y ago
  That the newest stable release is Chromium 69, and ideally you wouldn't want to lag behind that.
  - fouc 8y ago
    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.
The-Compiler 8y ago
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! [1] http://code.qt.io/cgit/qt/qtwebengine.git/tree/dist/changes-5.11.2/?h=v5.11.2 http://code.qt.io/cgit/qt/qtwebengine.git/tree/dist/changes-... [2] https://wiki.qt.io/Qt_5.12_Release https://wiki.qt.io/Qt_5.12_Release [3] http://code.qt.io/cgit/qt/qtwebengine.git/tree/tools/scripts/version_resolver.py?h=5.12#n41 http://code.qt.io/cgit/qt/qtwebengine.git/tree/tools/scripts... [4] https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#browser-security https://www.debian.org/releases/stable/amd64/release-notes/c... - only mentions QtWebKit, but applies to QtWebEngine too
- rjzzleep 8y ago
  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. https://blog.qt.io/blog/2018/02/22/qt-roadmap-2018/ https://blog.qt.io/blog/2018/02/22/qt-roadmap-2018/
  - The-Compiler 8y ago

tomxor 8y ago

> 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.

igneo676 8y ago
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
- tomxor 8y ago
  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.
  - The-Compiler 8y ago
    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...).
    - tomxor 8y ago
      > the changed lines in the imported Chromium source is usually somewhere around a couple of million. Yeah that sounds truly horrifying, I guess they must employ some degree of automation though.
The-Compiler 8y ago
It's in their documentation (but a bit hidden): http://doc.qt.io/qt-5/qtwebengine-overview.html#qt-webengine-core-module http://doc.qt.io/qt-5/qtwebengine-overview.html#qt-webengine... (This version of Qt WebEngine is based on Chromium version ...). I usually check their script, which also lets you switch between versions easily: http://code.qt.io/cgit/qt/qtwebengine.git/tree/tools/scripts/version_resolver.py?h=5.12#n41 http://code.qt.io/cgit/qt/qtwebengine.git/tree/tools/scripts... And I also have an overview here: https://github.com/qutebrowser/qutebrowser/blob/master/qutebrowser/utils/version.py#L309 https://github.com/qutebrowser/qutebrowser/blob/master/quteb...

drakenot 8y ago

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.

sandov 8y ago
Have you thought about using your hosts file to ads?
- The-Compiler 8y ago
  qutebrowser has a hosts-based adblocker built in, so that probably won't make a big difference.
skidd0 8y ago
I saw this in the qutebrowser quick start page: Run :adblock-update to download adblock lists and activate adblocking
The-Compiler 8y ago
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. [1] https://github.com/qutebrowser/qutebrowser/issues/28 https://github.com/qutebrowser/qutebrowser/issues/28 [2] https://lists.schokokeks.org/pipermail/qutebrowser-announce/2018-September/000051.html https://lists.schokokeks.org/pipermail/qutebrowser-announce/... [3] https://github.com/qutebrowser/qutebrowser/tree/master/misc/userscripts https://github.com/qutebrowser/qutebrowser/tree/master/misc/...
btschaegg 8y ago

kodablah 8y ago

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. 0 - https://bitbucket.org/chromiumembedded/cef https://bitbucket.org/chromiumembedded/cef

The-Compiler 8y ago
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.
- kodablah 8y ago
  > 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. You definitely can. I do: https://cretz.github.io/doogie/ https://cretz.github.io/doogie/. Prebuilt versions are available at http://opensource.spotify.com/cefbuilds/index.html http://opensource.spotify.com/cefbuilds/index.html. In fact, I'd say shipping with the browser is ideal for a few reasons. It's not a lib that should be shared across the system IMO.
  - The-Compiler 8y ago
    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?
    - kodablah 8y ago
      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)

fouc 8y ago

What's wrong with Chromium 65?

The-Compiler 8y ago
That the newest stable release is Chromium 69, and ideally you wouldn't want to lag behind that.
- fouc 8y ago
  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.

The-Compiler 8y ago

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! [1] http://code.qt.io/cgit/qt/qtwebengine.git/tree/dist/changes-5.11.2/?h=v5.11.2 http://code.qt.io/cgit/qt/qtwebengine.git/tree/dist/changes-... [2] https://wiki.qt.io/Qt_5.12_Release https://wiki.qt.io/Qt_5.12_Release [3] http://code.qt.io/cgit/qt/qtwebengine.git/tree/tools/scripts/version_resolver.py?h=5.12#n41 http://code.qt.io/cgit/qt/qtwebengine.git/tree/tools/scripts... [4] https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#browser-security https://www.debian.org/releases/stable/amd64/release-notes/c... - only mentions QtWebKit, but applies to QtWebEngine too

rjzzleep 8y ago
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. https://blog.qt.io/blog/2018/02/22/qt-roadmap-2018/ https://blog.qt.io/blog/2018/02/22/qt-roadmap-2018/
- The-Compiler 8y ago