hmmm.... "/ads/" is not a filter? why not? too many false positives?
go to sourceforge.net, and click on any project. you'll see an ad that can be blocked by "/ads/" or something else.
Ares2: Split from filter suggestion.
Testing /ads/*
Added more specific /ads/img/* filter for now: https://hg.adblockplus.org/easylist/rev/ec74a28b8efc
/ads/* has been removed for 2 reasons in the past: 1. It caused many false positives and 2. it was a slow rule with the old matching algorithm.
The second part is not true any more now, so it would actually be possible to try the rule again, but we will definitely have to test it thorough if decide that we want to readd it.
/ads/* has been removed for 2 reasons in the past: 1. It caused many false positives and 2. it was a slow rule with the old matching algorithm.
The second part is not true any more now, so it would actually be possible to try the rule again, but we will definitely have to test it thorough if decide that we want to readd it.
How can I help test filters like this? Just add them myself to My Ad Blocking Rules? Just wondering if there was a testing filterset that I could somewhat help with.
It wasn't planned to add that filter until now and there is no test filterlist because the rules we add usually doesn't require any specific testing. But yeah, adding it manually would help in case we decide that we should give it a try.
@Other authors: What are your opinions about readding /ads/*? Should we start testing that or is it not worthwhile due to false positives?
@Other authors: What are your opinions about readding /ads/*? Should we start testing that or is it not worthwhile due to false positives?
I'd be inclined to suggest that there would be too many false positives from the rule, although would appreciate any data to either support or refute this claim.
Well, then I would suggest each of us should add that rule to his personal rules to see where that goes. It would surely have a huge gain both in ad blocking efficiency and in filter rule performance (and we already have lots of whitelists for the "more specific" versions of /ads/*, so it might not be as bad after all, time will tell).
Well heck already found one. I know there is a lot of adblocking going on, but live365.com is not working properly when this rule is engaged. What happens is it's blocking something in that box that pops up and doesn't allow the station to go on playing. Without this rule the station would go on playing after a few seconds, sometimes on it's own or you can click the x, but no ads would display in the box. But with this rule it still pops up, but the x displays instantly and the station won't play. Not even if you wait a while. The box isn't blocked either way.
That page actually had some more issues for me (most notably no main content area due to ##.adshome), I think I fixed everything and got rid of most ads (works for regular users as well as when testing /ads/* ): https://hg.adblockplus.org/easylist/rev/817b93541c56
I don't really think that it is advisable to start adding whitelists to EasyList unnecessarily and would therefore propose that we should collect the filters that would potentially be required in this topic in order to make a decision about /ads/*, only committing the exceptions if we also add the blocking rule to the repository.
@Michael: This seems to be a misunderstanding: I acted as if this test wouldn't take place. Take a close look on the filters I've added/changed as well as on live365.com itself (player, switch station, navigate the subpages, ....) to understand why my commit looks the way it does and why it doesn't have anything to with this test.
I just mentioned that there is no additional whitelist necessary even if /ads/* is used.
I just mentioned that there is no additional whitelist necessary even if /ads/* is used.
I apologise - I misinterpreted your comment "works for regular users as well as when testing /ads/*" and assumed that you had added the domain exception for regular users and the whitelist for /ads/* testers.