Brave fails tests on simple-adblock.com

[jonathansampson]

• Did you search for similar issues before submitting this one?
  Yes

• Describe the issue you encountered:
  Originally reported on Twitter. Brave presently fails the two tests featured on http://simple-adblock.com/faq/testing-your-adblocker/

• Platform (Win7, 8, 10? macOS? Linux distro?):
  Windows 10

• Brave Version (revision SHA):
  0.13.0

• Steps to reproduce:

  1. Navigate to http://simple-adblock.com/faq/testing-your-adblocker/
  2. Note failing tests

• Is this an issue in the currently released version?
  Yes

• Can this issue be consistently reproduced?
  Yes

• Screenshot if needed:

[lukemulks]

I'm just skimming this now, but we're blocking the Google Analytics call that is made here (sending empty url resulting in a 307 redirect that fails).

Kind of a funky test for Brave, because we don't element-hide as it has perf negatives, so the rt side of the test applies less in our use-case. IMO

The "testing adblocking" test on the left is kind of weird too, the test is site-served via iframe from this URL:

http://simple-adblock.com/adblocktest/adblocktest.htm

Which seems like a not-so-genuine way to test an adblocker, unless you're the one that owns the adblocker, and want every other blocker except your own to fail the test. When I see who owns this blocker, I'm not surprised in the slightest that this test is setup this way.

I'm also not seeing any 3rd party ad requests aside from the Google Translate call, which seems like more of a webcompat item than ad blocking:
Request URL:http://translate.google.com/translate_a/element.js?cb=googleTranslateElementInit

I'd suggest we apply a site-hack for this iframe URL request to resolve w/minimal friction:
http://simple-adblock.com/adblocktest/adblocktest.htm

Can def assist further as needed.

[lukemulks]

Confirming that brave/adblock-lists custom filtering rules will not work to resolve this.

The subdocument is 1p hosted, which loads in the element-block and element-hide tests into this iframe: http://simple-adblock.com/adblocktest/adblocktest.htm

If we can a siteHack for the simple-adblock.com domain to block the URL above, it should resolve the issue.

[jonathansampson]

@lukemulks Looks like they block based on a CSS selector:

simple-adblock.com
ELEMHIDE
##.AD_300x250
EasyList
 
simple-adblock.com
ELEMHIDE
##.Ad_300x250
EasyList
 
simple-adblock.com
ELEMHIDE
##.ad_300x250
EasyList

[lukemulks]

@jonathansampson You're right about that.

I also was kind of short-cutting the fix here, because their testing method is pretty weak. This simulation is great if you own this blocker - otherwise, meh, the other blockers have to subscribe to the same rules, or are branded as non-functional. I could see this method being legit if they actually were serving ads from an ad server to test, but serving the test from the same domain is kind of like cheating in my opinion.

In addition to the CSS selector blocking that you pointed out, they're applying a simple /adbanner. string blocking rule that we're not covering (we'll only cover 3rd party ad requests - though this may change due to some recent discoveries).

I probably was being a little short-sighted with the fix on this, but since we don't block by CSS selection, and since we don't block 1p url requests, I was leaning toward a fix that cut the legs out from under the test.

So there are basically 2 options here:

• Option 1: we block the iframe source for the test, which would produce the effect that blocking would actually reflect in the wild (this is why I initially suggested that route).

• Option 2: we set a string replacement override for the red images, to swap with the image names for the green OK messages.

WDYT? Part of me thinks Option 1 is a little more badass since it snips from a higher level, but another part of me thinks a replacement/emulation is a more apples:apples result.

[jonathansampson]

@lukemulks I think you're right; this test doesn't reflect the web. Blocking the iframe source is appropriate IMHO. If we wanted to block the elements, we can do that too. We've started doing some basic selector-based hiding via the Brave manifest. We could make an entry for this domain, or apply a more global rule.

[bbondy]

Pls avoid any fix that is only getting the test to pass in a specific way.

[bbondy]

Also I think we don't need to prioritize this in a milestone unless there's some generic things to learn about why we aren't blocking correctly. Unless there's big external pressure for it by many.

[jonathansampson]

@bbondy SGTM