Opened on 06/06/2014 at 08:09:21 AM

Closed on 10/05/2015 at 12:32:03 PM

Last modified on 11/16/2015 at 11:50:38 AM

#647 closed change (fixed)

Add $genericblock filter option that can be used to disable all generic request blocking filters for a website

Reported by: arthur Assignee: kzar
Priority: P2 Milestone: Adblock-Plus-2.6.12-for-Firefox
Module: Core Keywords: 2015q3
Cc: Crits, mapx, barbaz, trev, manvel, greiner, famlam, sergz, ben Blocked By: #2738
Blocking: Platform: Unknown
Ready: yes Confidential: no
Tester: Unknown Verified working: no
Review URL(s):

Description (last modified by kzar)


We need a way to disable all generic request blocking rules for a given website. At the moment we can only disable each generic filter individually which is time consuming and verbose!

(Also see ticket #616 which is very similar and interrelated but for generic element hiding rules instead of generic blocking ones.)

What to change

Add the new $genericblock filter option to the lib/filter... code in the adblockplus repository.

It should match all generic generic request blocking rules for the given domain(s) / sitekey(s) and act as a way to easily disable them.

When a $genericblock filter is applied to a page it should also recursively apply to all child frames.

Generic filter rules count as rules that:

  • Do not have a domain / sitekey specified. "Block this request for all domains"
  • Have only domain / sitekey exceptions specified. "Block this request for all domains except"

Attachments (0)

Change History (35)

comment:1 Changed on 06/06/2014 at 08:23:24 AM by mapx

  • Cc mapx added

comment:2 Changed on 06/07/2014 at 12:00:38 AM by barbaz

This could be the effect of the $~elemhide option on whitelist rules (IIUC that option currently has no meaning).

(Can someone please add me to CC list for this issue as I don't see how to do it?)

comment:3 Changed on 06/07/2014 at 02:41:25 AM by Crits

  • Cc barbaz added

comment:4 follow-up: Changed on 06/09/2014 at 03:23:42 PM by Crits

I think generic rules can be defined as the rules beginning by ||.
I don't think the rules beginning by |http: can be considered as generic rules, and many of them are already used to circumvent anti-adblock anyway.

@barbaz : $~elemhide may not be understandable enough. Why not create a new option altogether?

comment:5 in reply to: ↑ 4 Changed on 06/09/2014 at 04:28:21 PM by barbaz

Replying to Crits:

I think generic rules can be defined as the rules beginning by ||.

In my enormous custom filter lists, it's the rules beginning with || that are the least generic. Why not define generic rules to be those with no leading anchor (meaning, not starting with | or ||)?
That way, this option is harder to unintentionally "abuse"; in otherwords, this definition of generic rules makes it unlikely that using this option will have the side-effect of whitelisting requests to "evil" domains that the end user does not ever want their computer connecting to.

@barbaz : $~elemhide may not be understandable enough. Why not create a new option altogether?

Could, but then there would be yet another meaningless inverse boolean filter option.
I was thinking that since $elemhide matches pages and disables all element hiding rules on the page, the logical inverse of that option for whitelist rules would be to disable blocking rules on the matched page.

Really, it depends how hard it is to add aditional type options and how often filterlist authors will want to use both $elemhide and this new option on the same page.

Last edited on 06/09/2014 at 04:29:45 PM by barbaz

comment:6 follow-up: Changed on 06/10/2014 at 03:57:03 PM by Crits

About ||: sorry, I of course meant not beginning by ||

[...] another meaningless inverse boolean filter option

Is it a big deal?
$~elemhide meaning whitelisting generic filters is not logical for me, as elements are not the contrary of HTTP requests.

comment:7 in reply to: ↑ 6 Changed on 06/10/2014 at 05:02:03 PM by barbaz

Replying to Crits:

[...] another meaningless inverse boolean filter option

Is it a big deal?

No big deal at all, it was just a suggestion.

comment:8 Changed on 07/07/2014 at 12:05:54 PM by trev

  • Cc trev added
  • Platform set to Unknown

comment:9 Changed on 07/22/2014 at 04:10:02 PM by saroyanm

  • Cc added

comment:10 Changed on 09/15/2014 at 04:45:49 PM by greiner

  • Cc greiner added

comment:11 Changed on 09/16/2014 at 09:02:35 PM by trev

  • Priority changed from P2 to P3

comment:12 Changed on 10/06/2014 at 11:46:17 AM by fhd

  • Keywords 2014q4 added
  • Priority changed from P3 to P2

comment:13 Changed on 10/06/2014 at 08:58:59 PM by mapx

  • Cc famlam added

comment:14 Changed on 12/09/2014 at 03:43:29 PM by sergz

  • Cc sergz added

comment:15 Changed on 01/19/2015 at 11:21:31 AM by kzar

  • Description modified (diff)
  • Owner set to kzar
  • Summary changed from Disable generic blocking rules for a specific domain to Add $genericblock filter option that can be used to disable all generic request blocking filters for a website

comment:16 Changed on 01/19/2015 at 04:43:01 PM by arthur

btw it would be great if that would also allow to disable generic blocking rules in an iframe ( on a site ( I know a site that's doing that for quite some time (of course the URL of the iframe constantly changes).

comment:17 Changed on 01/19/2015 at 05:43:36 PM by greiner

  • Description modified (diff)

comment:18 Changed on 02/13/2015 at 02:20:40 PM by kzar

  • Description modified (diff)

comment:19 Changed on 05/08/2015 at 11:04:40 AM by kzar

  • Review URL(s) modified (diff)
  • Status changed from new to reviewing

comment:20 Changed on 07/12/2015 at 04:46:41 PM by kzar

  • Blocked By 2738 added

comment:21 Changed on 07/30/2015 at 05:40:42 PM by fhd

  • Keywords 2015q3 added; 2014q4 removed
  • Tester set to Unknown

comment:22 Changed on 08/05/2015 at 10:42:14 AM by arthur

  • Cc manvel ben added; removed

comment:23 Changed on 08/26/2015 at 10:55:00 AM by kzar

So this issue and #616 have been progressing, if slowly. I've given Arthur a test build of the Firefox extension to try out and it seems we need to give this some more thought. What makes a filter "generic"?

At the moment filters are considered "generic" if there are no domain / sitekeys specified, or if there are only exceptions specified Specifically the implementation as it stands looks like this.

It has been suggested that a more useful test might be to just check if the filter text starts with | or not, rules that don't start with | could be considered generic. But as Arthur points out that's not a perfect test either, for example ||^$third-party could arguably be considered generic.

(The other issue with this is that we need to check if filters are generic _a lot_, so we should be mindful to perform the minimum work possible in the check.)

So defining what actually makes a filter generic is currently blocking us, there's no point going ahead until we've agreed something that's actually useful for you guys!

Any suggestions?

comment:24 Changed on 08/26/2015 at 12:37:12 PM by greiner

I quickly talked to Arthur about that and apparently there are the following problems:

  • If we block such filters then it would lead to a lot of additional effort in maintainance of the filters because each of those kind of generic filters would need to be explicitily blocked again by adding a specific blocking filter.
  • Not blocking such filters would, however, decrease the usefulness of this feature for countering adblocker detection solutions and it would make this filter option more confusing to understand correctly because it would no longer affect all generic filters.

Let's consult more filter authors before making a decision on that.

comment:25 follow-up: Changed on 08/26/2015 at 01:01:40 PM by famlam

I assume it isn't an issue for #616?

Personally I'm not at all in favor of having this option for _blocking_ rules:

  1. it kills privacy/social lists
  2. requires large amounts of specific filters
    • for the site itself in the adblocking list (both first party and third party resources)
    • for the site itself in the social list and the privacy list (which is annoying as EP and social include international filters and are thus also affected by what the filter list for _name your random language_ does)
    • for any third party inline frames (including widgets, social media), which all need their specific filters to cover for them as well
    • therefore adds a very lot of filters that are useless on *all* other sites as other filters already cover for it.
  3. sites that are troublesome enough to warrant a $genericblock filter in the first place, probably have no trouble with extending their anti-adblock checks for specific filters; and if the specific filters are used to block ads, then they can just change the path to the ads.
  4. (it basically kills my redundancy check as I cannot say if the filter ||thirdpartydomain/ads/css. is redundant due to /ads/css., or should be kept because we have @@||firstpartydomain^$genericblock. This is of course not an issue for ABP, just for me, but it does no longer allow authors to find redundant filters, which are quite often present )

However, since other people (apparently) see the benefits, a relatively simple suggestion I could make, on top of the domain and sitekey check, is:
(with rule = the rule without the options)
rule[0] !== "|" || rule[rule.length - 1] === "^"
(or use String.prototype.startsWith/endsWith; not sure how fast they are).

However, if you wish to deal with
I don't see any fast solutions, other than using rule.indexOf/rule.includes to check for all of them (/, ^ and *) separately...

(Note: don't get me wrong: I do love to get this feature for hiding rules; I just don't like it for blocking rules.)

Last edited on 08/26/2015 at 01:21:58 PM by famlam

comment:26 in reply to: ↑ 25 Changed on 08/26/2015 at 02:23:04 PM by kzar

Replying to famlam:

I assume it isn't an issue for #616?

The issue of how we define a generic filter applies to both #647 and #616, both will make use of the same .isGeneric() filter method. (Sorry it's a bit of a mess with the two separate issues at the moment.) We need to think of a check that will work for both blocking and hiding rules.

Personally I'm not at all in favor of having this option for _blocking_ rules...

Do any of the other filter list maintainers think $genericblock will be useful to them or do you agree with famlam's points? (There's nothing to stop us only implementing $generichide if that's more useful.)

However, since other people (apparently) see the benefits, a relatively simple suggestion I could make...

Thanks for the suggestions, very helpful!

comment:27 Changed on 09/02/2015 at 10:00:05 AM by greiner

Thanks everyone for your feedback. Since there is cause for a timely solution and the current implementation is almost through the review we are going to release it the way it is currently specified. That means that an exception rule with $genericblock will unblock all resources blocked by filters that don't specify either $domain or $sitekey.

That being said, this feature should be considered experimental and may go away at any point for something more appropriate so please use it sparingly but still wherever it is necessary. Note that a feature with the suggested functionality would require to be named differently no matter what due to it not applying to only some generic filters.

comment:28 Changed on 09/29/2015 at 01:50:50 PM by mapx

test case ABP firefox:
go to

add this filter


open blockable items list ==> I don't see in green all the whitelisted items (even if they are really whitelisted !)

for example this item:

Last edited on 09/29/2015 at 01:53:32 PM by mapx

comment:29 Changed on 09/29/2015 at 03:11:18 PM by kzar

I think this is to be expected due to the way that it's implemented, when $genericX options are in effect we only search for specific blocking rules. As far as the code is concerned the generic blocking rule never matched, instead of it being matched and then whitelisted.

This was a trade-off we made to avoid having to perform an extra search for matching filters. Otherwise we would have to search for all matching blocking filters, and then later for specific ones if a $genericX whitelist rule was in effect.

comment:30 Changed on 09/29/2015 at 03:15:05 PM by mapx

a side effect of this approach:
I can click a such (invisible) whitelisted item and create a blocking filter for it.

comment:31 Changed on 09/29/2015 at 03:28:09 PM by kzar

Well IMHO you should be able to create a blocking filter for those items, the suggested blocking filter should just be a specific one. I think you have a valid point anyway that this is not ideal as it stands.

comment:32 Changed on 09/29/2015 at 03:53:34 PM by mapx

right, the specific domain filters can be added.

comment:33 Changed on 10/05/2015 at 12:32:03 PM by kzar

  • Resolution set to fixed
  • Status changed from reviewing to closed

OK, I have filed issue #3162 for this problem mapx. Thanks for reporting it, I'm going to try to see if I can at least fix the suggested filters in this situation.

In the mean time I'm going to finally close this issue :)

comment:34 Changed on 10/08/2015 at 01:59:16 PM by kzar

  • Milestone set to Adblock-Plus-for-Firefox-next

comment:35 Changed on 11/16/2015 at 11:50:38 AM by trev

  • Milestone changed from Adblock-Plus-for-Firefox-next to Adblock-Plus-2.6.12-for-Firefox

Adblock Plus 2.6.12 is being released from branch, this change is part of it.

Add Comment

Modify Ticket

Change Properties
as closed .
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from kzar.
Note: See TracTickets for help on using tickets.