Request: Custom filters immune to subscription exceptions

[[none]]

Per a recent thread, it seems that end-user created custom filter rules that block something can be overridden by subscription list exception rules. If and when that occurs, something that the end-user explicitly wanted blocked and expected to be blocked will not be blocked. This can happen when a user is more aggressive about blocking things, and more willing to break things, than subscription list maintainers. I think we'd consider the consequences "serious" if the custom filter rule that is overridden was meant to protect the user against a privacy threat or eliminate unnecessary exposure to potential security threats. Concerned users should check their subscription list exceptions against their custom filter rules and determine if this issue applies to them.

There seems to be no good way for such users to cope with this. Abandoning subscription lists isn't a good option. Adding another extension to fix this ABP issue isn't a good option. Having to review and manually disable each undesired exception rule in subscription lists isn't a good option. You'd basically have to check subscription lists for conflicting exception rules each time you create a new custom block rule, and also each time the subscription lists are updated in case a new exception rule was added. If you think there is some other genuinely good way for affected users to deal with this issue, would you please spell it out?

Assuming there is no satisfactory way of eliminating or working around this issue, my request is actually that this issue be put on the "we need to address this, lets determine the best way to do so and then get it done" list. ABP developers who know the code will know what that best way is. Maybe it is having a special blacklist filter group that is checked first, maybe it involves a new type of rule and syntax used to create a "no exceptions block rule". Whatever. Would ABP developers please pursue this? Thanks.

[mapx]

can you provide some examples of what do you want to do ?

[[none]]

I would like to create a custom filter rule such as:

||example.com^
/example/*
/example.js

that *can't* be overridden by an exception rule in a subscription list. I have seen this happen - EasyPrivacy+EasyList exceptions overriding my intentionally more aggressive custom filter rules. I can't remember which specific exceptions those where, but that doesn't matter. The mere possibility that such a subscription could purposely or accidentally override an end-user's custom filter rules is a problem.

[mapx]

-the exception rules avoid the breaking of sites functionality, so if you find some useless/excessive exception filter ==> report here

-in firefox there are no problems: you can disable the "bad" exception rule
-in chrome actually you cant disable an exception filter (but you can use only your custom filters, disabling all official subscriptions)

[[none]]

in firefox there are no problems: you can disable the "bad" exception rule

What you are suggesting is that every user who wants their custom filter blocking rule to work reliably must:

1) Carefully examine every exception rule in every subscription to identify which exceptions are OK and which exceptions would conflict with their own rules.
2) Disable the conflicting exception rules

Then either:

a) Repeat steps #1 and #2 above each and every time subscriptions update (in case a new conflicting exception was rolled out)
or
b) Disable subscription updates

Also note that if the user disables conflicting exceptions they will always see the "Some filters in this subscription are disabled" warning. A warning that is quite useful in terms of reminding you that you temporarily disabled something that you will want to re-enable. That usefulness goes away if you use this approach and disable an exception. It could also create a situation where the user forgets they disabled some exceptions on purpose and clicks the "Enable disabled filters" option to undo a temporary change, inadvertently breaking their custom filter rules (again).

All that just to make user-created custom filter rules work properly?

[mapx]

first, you need to disable an exception filter ONLY in some rare cases. And again ==> these exception rules are necessary to avoid the breaking of the sites.

second, you have to do all those steps only when something does not work (and, in firefox, you'll see all those filters in the blockable items list where you can enable / disable all the filters you need).

third: all this is theory, do you have some real example ? report it.

[[none]]

first, you need to disable an exception filter ONLY in some rare cases.

I'm not familiar with all the subscriptions in use and whether or not disabling a subscription exception would be a rare event for all cases, but for discussion purposes I'm willing to go with "infrequent". However, I think the far more important question would be the effort required to monitor for conflicting subscription exceptions.

second, you have to do all those steps only when something does not work (and, in firefox, you'll see all those filters in the blockable items list where you can enable / disable all the filters you need).

You would want to make sure your custom rules won't be overridden before you run into a case where they are overridden. The approach you describe reveals overrides and bypasses after the fact. It would involve browsing with ABP's blockable items list open all the time (because websites change), continuously scanning (and possibly scrolling) through the list at every website to see if something you wanted blocked got through. The user would either have to perfectly remember all the custom rules they had created and what should be blocked, or keep their custom filter rules open and check those against the exceptions that show up.

[[none]]

I did a quick survey of some subscription lists, counting the lines beginning with @@ (exception rules) and separately counting the lines containing a single @ (apart from a few special cases, these are element hiding exceptions are they not?). From a protection POV I'm not sure how much of a problem element hiding exceptions could be but I figured I'd count those while I was at it. Results:

Code: Select all

List                          @@ lines         @ lines
------------------------------------------------------
EasyPrivacy+EasyList.txt      2162             489
easylist.txt                  2162             489
easyprivacy.txt               486              0
fanboy-annoyance.txt          157              68
fanboy-social.txt             124              60
Antisocial.txt                9                0
malwaredomains_full.txt       0                0

I quickly scanned all of the EasyPrivacy+EasyList @@ exceptions lines (extremely tedious) and spotted roughly two dozen lines that appeared to make sense for my context. IOW, rules which might break something at a site I would both a) visit and b) care about in terms of breaking things. So for some aggressive blockers I think this is a needles in haystack situation.

In addition to the "identify encountered exceptions by browsing with blockable items open" approach mentioned by mapx, I thought of another approach. Enable Count Filter Hits. Browsing the sites where you might care about something being broken. Then go into Filter Preferences and sort subscription list rules in order of decreasing hits. Scan down that list looking for exception rules that were hit. You can try disabling ones you don't think are necessary for your context and see if you run into any problems.

I don't see a way to disable multiple selected rules in one shot. A context-menu option to do this would be nice. So if you want to disable very many exception rules other than a select few, I think you'd want to create a helper script. From within Blockable Items or Filter Preferences, copy the desired exception rules to a keepers file. Via custom program or script, you can modify an Adblock Plus backup file (disable the @@ exception rules that aren't in the keepers file). Afterwards, import that modified backup file. Some work, and you'd still have to be on the lookout for new exception rules being included in updates.

[MonztA]

I don't see a way to disable multiple selected rules in one shot.

You can do that by pressing the space bar.

[[none]]

Yes I can now that you have pointed it out to me. Thank you!