After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 757824 - Port the adblocker to the Content Blockers API
Port the adblocker to the Content Blockers API
Status: RESOLVED OBSOLETE
Product: epiphany
Classification: Core
Component: General
git master
Other Linux
: Normal normal
: ---
Assigned To: Adrian Perez
Epiphany Maintainers
Depends on:
Blocks: 776514
 
 
Reported: 2015-11-09 16:14 UTC by Emanuele Aina
Modified: 2018-08-03 20:42 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Emanuele Aina 2015-11-09 16:14:14 UTC
The current adblocker has a few "interesting" issues:

* it is currently broken (see bug #754954)
* it does not handle hiding elements through CSS
* it does not handle several filter options
* it internally tracks filter options using comma-separated strings and runs a regex every time it needs to checks if an option is active or not, when a bitfield would have been the obvious choice
* it uses g_strdup("1")/g_strdup("0") to store the cached results of the URL match in a GHash when a boolean would have been the obvious choice

Moving to the Content Blockers framework[1] recently added to WebKit would give us the chance to get support for hiding elements using CSS, automatic support for every filter feature supported by Safari as all the logic is in WebKit and probably better performance with likely less code and less sillyness.

[1] https://www.webkit.org/blog/3476/content-blockers-first-look/

For reference, here's the Safari version of the AdBlockPlus extension: https://hg.adblockplus.org/adblockplussafariios/
Comment 1 Michael Catanzaro 2015-11-09 19:38:13 UTC
Hi Emanuele, this sounds good. Are you planning to work on this? Will it require new API in WebKitGTK+?
Comment 2 Emanuele Aina 2015-11-09 22:11:32 UTC
> Are you planning to work on this?

I would like to, but don't hold your breath. In any case I won't be able before next year.

> Will it require new API in WebKitGTK+?

I guess so, as the application would need a way to push the JSON-encoded rules to WebKit.
Comment 3 Emanuele Aina 2015-12-09 10:36:22 UTC
For the record, Mozilla released a Safari extension which uses the Content Blockers machinery: https://github.com/mozilla/focus/blob/master/build-disconnect.py
Comment 4 Adrian Perez 2016-02-22 20:48:21 UTC
I have filed in a bug in the WebKit Bugzilla to track progress
on the WebKitGTK+ side of this, because it is going to need new
a couple of new functions in the API:

  https://bugs.webkit.org/show_bug.cgi?id=154553
Comment 5 francoism 2016-08-15 17:19:10 UTC
Any update on this? :)

See http://simple-adblock.com/faq/testing-your-adblocker/ => Testing element hiding doesn't work.

Also I don't know if it possible, but it would be great to have more filters available, like Easyprivacy, etc.
Comment 6 Michael Catanzaro 2016-08-15 18:21:43 UTC
(In reply to francoism from comment #5)
> Any update on this? :)

There's recent progress in the WebKit bug.

> See http://simple-adblock.com/faq/testing-your-adblocker/ => Testing element
> hiding doesn't work.

I guess it will be supported with Content Blocking.

> Also I don't know if it possible, but it would be great to have more filters
> available, like Easyprivacy, etc.

Yeah, this is planned.
Comment 7 francoism 2016-08-21 12:36:08 UTC
@Michael Catanzaro: Thanks for the update, will keeping an eye on the git repo. :)
Comment 8 Ryan Farmer 2017-06-24 04:24:26 UTC
Hello,

I was reading the Roadmap to 3.26 and it seems like there could be an opportunity to solve two problems at once here. Once Web is transitioned to the Content Blocking API, Web could subscribe to Spam404 and Malware Domains Adblock Plus Lists as part of the "Block dangerous websites using a safe browsing API" feature.

That could complement using something like Google Safe Browsing by making sure that if Google misses something that are on these lists, Web can't load the site anyway due to the content block. Firefox can be configured this way.
Comment 9 Michael Catanzaro 2017-06-24 12:25:19 UTC
Hm, that's backwards... we can subscribe to those filters now, because they are ABP filters and that's the format we currently support. Once we port to the superior content extensions format used by Safari, we won't be able to use them anymore until they release Safari-compatible filters.

But I have a question about how these work. Our adblocker is only designed to block subresource loads, never the main resource. So I'm not sure if a malware domains block list is going to be very useful. Moreover, we really want to display some sort of explanation if we're going to block content due to a reported security issue, and that won't really be possible if we use adblock filters. So I kinda think it's better to use Google Safe Browsing only, but certainly we need to offer an adblock configuration dialog so you can sign up for whatever filters you want.
Comment 10 Ryan Farmer 2017-06-24 17:08:42 UTC
Hmm, I guess I was wrong about what the actual goal of this was to do.

Back to the subject of blocking content, Webkit/Blink browsers apparently have some sort of bug where a really awful thing called "Ad Choices" can detect that you're blocking the ads and load ads that are even worse than the ones that were blocked. (Taboola-style, only worse than Taboola. Taboola is also currently unblocked by Gnome Web.), so if the new method of content blocking can defeat Ad Choice *and* taboola, then that would be the gold standard, at least from my perspective. 

uBlock-Origin works around the bug that enables Ad Choices with a helper extension called uBlock Origin Extra whose additional goal goes into defeating hostile activity from websites in general, such as disguising third party requests as first party ones, which gets around the cookie policy of the browser, sites evading the blocking policy by (ab)using WebRTC, etc.

The next problem is...sites detecting that ads are blocked and displaying a nag screen or locking the user out entirely. So far, I've been able to break the majority of these blockades with browser configured with uBlock Origin, uBlock Extra, Tampermonkey extension, and Anti-Adblock Reek userscript+ABP style filter.

The web is getting to a point where if you want to turn off advertising, it's like the children's song about the old lady who swallowed a fly, and then swallowed the spider to catch the fly, then a bird to catch the spider, then a cat to catch the bird, then a dog to catch the cat....

Is there really a way to manage all of this stuff with a single checkbox? If there is, I'm not seeing it, and Google plans to use Chrome as a protection racket (by blocking ads not approved by their sockpuppet "Coalition for Better Ads), and then roll out "Funding Choices", which is another anti-adblock platform. Could this be a losing battle against ads/trackers? Of course it could be. Google has the resources to keep Funding Choices working faster than Anti-Adblock Reek or anything else can catch up to it. So, what is the scope of ad blocking in Gnome Web? Obviously simple is good, but simple leaves out a ton of cases where Evil Inc. can game the rules to get a foot in the door.

I do like the work that gorhill has done with uBlock Origin. It's so much more than a simple adblocker. He's put a lot of work into catching and defeating corner cases. In one example, he's replaced things like Google Analytics with a "neutered script" that gets loaded instead, with the minimum API that problem websites expect in order to stop them from failing. The guy is unstoppable. :)

We're going to need something powerful to keep up here.
Comment 11 Michael Catanzaro 2017-06-24 17:24:42 UTC
(In reply to Ryan Farmer from comment #10)
> So, what is the scope of ad blocking in Gnome Web? Obviously simple is good,
> but simple leaves out a ton of cases where Evil Inc. can game the rules to
> get a foot in the door.

So let's be clear. First goal is to enable WebKit content filters, which are already used in Safari. Apple's goal is to block all ads, because Apple is not an advertising company and promoting adblocking hurts Google, so our interests are perfectly aligned here. So it's very unlikely that WebKit would ever gain the sort of Ad Choices feature that Google is pushing (and, if so, we would disable it in any case).

> I do like the work that gorhill has done with uBlock Origin. It's so much
> more than a simple adblocker. He's put a lot of work into catching and
> defeating corner cases. In one example, he's replaced things like Google
> Analytics with a "neutered script" that gets loaded instead, with the
> minimum API that problem websites expect in order to stop them from failing.
> The guy is unstoppable. :)
> 
> We're going to need something powerful to keep up here.

Yes, I agree, but none of this extra work besides porting to content filters is going to be on our TODO list anytime soon I'm afraid, so we'll need a volunteer to push this forward. There's lots more we ought to be doing out-of-the-box, like blocking 1x1 px images (web beacons).
Comment 12 GNOME Infrastructure Team 2018-08-03 20:42:39 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/epiphany/issues/288.