More sophisticated adblocking

[The-Compiler]

There should be an adblocker.

edit: A host-based adblocker which is sufficient for most cases is implemented since a long time already, this issue is still open because it could be improved by implementing ABP-like filterlist support.

The eric IDE helpviewer does have one (in Python), which might be a good inspiration

[The-Compiler]

Before we have a real blocker we could use http://www.floppymoose.com/ in the default user-stylesheet. We probably should check the license though.

[The-Compiler]

https://github.com/foxhead128/nimbus also does adblocking which might be another inspiration

[The-Compiler]

host-file adblocking has been implemented in 0134646 - leaving this open for more sophisticated blocking

[HalosGhost]

I would recommend µblock as a model to use. It aims to be much lighter and faster than ABP while actually extending some functionality.

[1-61803]

Is there any ad-blocking implementation as of now, internal or via plugin?

[parchd-1]

Yes, there is host-file adblocking, as you can see above.
The plugin system isn't done yet, so other adblock systems aren't either. You can also see that in the issue linked to above ;).

[1-61803]

@parchd-1 I skimmed. I see the hosts file implementation from 2014 and #30 has adblock stroke through. What is the actual state of development of plugins that would allow better ad blocking but also plugins like ublock and greasemonkey?

[The-Compiler]

What is the actual state of development of plugins

There isn't anything other than the thoughts listed in #30 so far.

that would allow better ad blocking but also plugins like ublock

What from ublock are you missing, other than having adblockplus-like block lists?

and greasemonkey

Something similar to it should be possible with per-domain settings (#27) which is the current main focus - in around a week I'll launch qutebrowser's second crowdfunding, to work on this (and maybe start some work on plugins if there's time left) during my summer holidays. Subscribe to that issue if you want to get notified once it's up!

[1-61803]

What from ublock are you missing, other than having adblockplus-like block lists?

I just have switched to ublock as ABP caused high CPU usage. Having the same lists makes rendering sites equally across hosts. Just a first impression after switching blocker.

I still have to make it work in my main older machine on 10.8. I encountered the same problem pointed out here. It should compile from source, it's python and qt, right?

Something similar to it should be possible with per-domain settings (#27) which is the current main focus - in around a week I'll launch qutebrowser's second crowdfunding

Subscribed. What's the best way to get regular (weekly but not daily) news? If I compile it in my 10.8 I'll be certainly donating to your project.

[The-Compiler]

I still have to make it work in my main older machine on 10.8. I encountered the same problem pointed out here. It should compile from source, it's python and qt, right?

There's nothing in qutebrowser itself you'll need to compile, as it's Python. You'll need a working Python with PyQt though. If you can get a Python 3.5 or 3.6 installed (maybe via Homebrew or pyenv), you should be able to do something like pip install PyQt5 qutebrowser (optionally in a virtualenv). If you need help, open a separate issue though, please.

What's the best way to get regular (weekly but not daily) news?

There isn't anything like a regular newsletter. You can look at the changelog and github activity manually though.

I'd also recommend subscribing to the qutebrowser-announce mailinglist where important announcements like new releases are posted.

[ghost]

so if I want to give the rust adblocker a shot, what should i do?

[The-Compiler]

@treeshateorcs You'd need to write Python bindings for it (e.g. using PyO3), then use those from qutebrowser (similar to the current adblocking module).

[ArniDagur]

I'm interested in creating Python bindings for Brave's Rust adblocker and integrating them into qutebrowser, as discussed above. @The-Compiler Has anything changed since this was discussed, that would be a reason for me not to proceed?

[The-Compiler]

@ArniDagur Sounds great! Nothing changed as far as I know. You might also want to set up cibuildwheel to build Python wheels (binary packages) of the Rust adblocker and Python bindings.

[ArniDagur]

See #5317

[srcrip]

Just wanted to say I'm so pumped for #5317 to be merged. Host adblocking never felt quite 'right' to me and kept me going back to chromium.

[gordon-quad]

I have a question about #5317.
It mentions that it supports ABP syntax but it looks like adblock-rust repo mentions only URL matching against easylist-like filters. So my use-case is a little bit different, I use uBlock-like extension not only to block ads but also quite frequently use "block element" item from popup menu to block unwanted UI elements that might originate from website itself (e.g. modal "register right now" popups, cookie banners etc.). So will I be able to do so with #5317 merged or shall I create a separate issue/feature request for that?

[ArniDagur]

I use uBlock-like extension not only to block ads but also quite frequently use "block element" item from popup menu to block unwanted UI elements that might originate from website itself (e.g. modal "register right now" popups, cookie banners etc.). So will I be able to do so with #5317 merged or shall I create a separate issue/feature request for that?

That is called cosmetic blocking, and is supported by the underlying adblocking library. See https://github.com/brave/adblock-rust/blob/master/src/cosmetic_filter_cache.rs for example.

In the comments of #5317 we discussed implementing cosmetic filtering in qutebrowser (see #5317 (comment)), The conclusion was that there would need to be more work done on the underlying infrastructure to support cosmetic blocking. The aforementioned pull request therefore only tackles network filtering.

[The-Compiler]

FWIW there's also the delete target for :hint, though that isn't persisted.

[jgkamat]

Árni Dagur writes:

In the comments of #5317 we discussed implementing cosmetic filtering in qutebrowser (see #5317 (comment)), The conclusion was that there would need to be more work done on the underlying infrastructure to support cosmetic blocking. The aforementioned pull request therefore only tackles network filtering.

Note that it's been possible for year(s) to implement cosmetic filtering through greasemonkey - for anyone who wants it there shouldn't be any blockers other than qt bugs. #29 (comment)

[gordon-quad]

Thanks, I will take a look at it, that sounds like maybe a suboptimal from performance standpoint but a solution nonetheless.

[jgkamat]

gordon-quad writes:

Thanks, I will take a look at it, that sounds like maybe a suboptimal from performance standpoint but a solution nonetheless.

suboptimal in what way exactly? I don't think qb is doing anything intentionally to slow down scripts (to my knowledge at least) - and if it was that should be fixed. I don't really see how any alternative available would launch scripts any faster unless the greasemonkey wrappers were significant.

[crocket]

The userscript is slow.

[jgkamat]

crocket writes:

The userscript is slow.

In what way, and how can it be fixed in qb? I don't think the greasemonkey wrapper would run js much slower than an extension, although I could be wrong.

[crocket]

You mentioned

Right now, we load all global styles on page load, which can add significant overhead (~10ms in my testing). Doing this differently may be more efficient, but would make it harder to measure the overhead.

[jgkamat]

crocket writes:

You mentioned > Right now, we load all global styles on page load, which can add > significant overhead (~10ms in my testing). Doing this differently may be > more efficient, but would make it harder to measure the overhead.

Yes, that's actually the way ABP does (or used?) to do cosmetic filtering. I found the overhead negligable compared to other parts of qutebrowser unrelated to greasemonkey (which were orders of magnitude slower), so I didn't see a need to optimize it when there were much bigger saves elsewhere. It's not a blocker to cosmetic filtering - it should be easy to do better if you would like to!

[crocket]

I think jhide is a bit inconvenient because I can just save cosmetic filter rules in uBlock Origin.

[iio7]

Is there a reason why the ad blocker isn't working on YouTube even though it is blocked in the Steve Black hosts list?

[iio7]

Just found the answer here, so never mind: https://old.reddit.com/r/qutebrowser/comments/hv085s/why_does_the_adblock_not_work_also_how_do_i_turn/

[The-Compiler]

It's taken a while, but @ArniDagur's ad blocking integration based on Brave's Rust library has been merged! 🎉 ✨

[koiuo]

@The-Compiler , do you plan to release a new version some time soon?

[cole-h]

@edio See #5317 (comment); specifically:

There's some follow-up work I want to do here (e.g. announcing this via mailinglist and reddit and such), but not today

[The-Compiler]

This will be released as part of v2.0.0, which will still take a while (even if it originally was planned for end of 2020, which probably was a bit ambitious) - there's still various work to do (also see #5749), and I also want to give this some time to settle (and perhaps catch regressions).