Option to disregard all exception filters in filter lists

[sebast889]

I know a lot of exception filters are there to prevent some kind of breakage but I really wish there was a way to disregard/not apply any exception filters from filter lists. 99% of time I don't need the exception filters in lists as the breakage is minimal already without them and allowing whitelisted requests usually allows some tracking script or request to a 3rd party that I don't want to make. An optional function or option to disable whitelist filters in filter lists globally or per-list (like a button to disable next to filter list name) would be amazing. I don't think I'm alone in wishing for an option like this.

[gorhill]

Use dynamic filtering to override filter list rules -- that's one of its main purpose.

[sebast889]

I don't understand how dynamic filtering can solve this. Filter lists have hundreds or thousands of exception filters with more added daily. It's not possible to block them all manually using dynamic filtering.

[gorhill]

The purpose of exception filters in any list is to un-break specific sites which are broken as a result of broader block filters -- they are an essential part of the a list.

But basically, if you do not trust filter lists, why use them at all? In such case, just use default-deny mode, this way you don't have to trust anyone.

[sebast889]

I trust their block filters since even with them I don't make any requests to unwanted parties where it is not the same case with whitelisted filters. I don't see why there has to be a scenario where you either you use all the block and whitelist filters or none at all.

There are many instances where whitelist filters are not needed for me since they cause no breakage at all many times or just cause minimal breakage like part of the footer is missing or login button broken for sites I don't even have accounts for. Even instances where filters are written for Chrome but aren't needed for Firefox (example uBlockOrigin/uAssets#521 and uBlockOrigin/uAssets#458 where even you mention the unnecessary exception filters when Firefox wasn't even affected by IL crap at the time)

[sebast889]

@gorhill can you reconsider your view on this? I'm not asking for this to be default but rather something advanced users must willingly turn on or enable. There is no easy way for a user to disable all whitelisted filters and many of these without a doubt leak data to 3rd party ad/tracking companies in exchange for not breaking something (or even times where they are old filters/browser specific filters that don't cause any breakage). If there really is some breakage the user wants to fix they can create exception filters themselves since it will only be for advanced users who go out for their way to enable this.

I don't understand why users who want to utilize filter lists' block filters must use block filters as well as whitelisted filters or none at all. I just hope you can give the user the ability to choose for themselves.

[gorhill]

I suggest you fork and modify as you wish. If ever your feature proves to be in high demand, I will reconsider.

To keep asking me to throw code at uBO with all the potential consequences, i.e. larger code base, higher potential for new bugs, regressions, added complexity to the UI, more ways for mainstream users to screw their config (with me on the receiving end), etc. is easy. I believe it's a pointless feature, and if anyone is interested, it's going to be a ridiculously small minority given that it's already possible to simply point-and-click to override anything in static filter lists. So, if you believe in it, do the work for it, I do not believe in such feature.

---

Also, let me add that as soon as I read your request, I saw your rationale for such feature as flawed:

allowing whitelisted requests usually allows some tracking script or request to a 3rd party that I don't want to make

Why do you believe in the first place that these lists protect you completely from useless 3rd parties? There is no need for exception filters for what is not blocked, so it's not because there is no exception filters in a list that this list protects you from pointless 3rd parties. Why don't you also worry about all the 3rd parties which are not blocked at all such that no exception filters are necessary? Again, the cure for such worries about 3rd parties is dynamic filtering -- it's already in there available, just use it.

[sebast889]

Dynamic filtering can work on sites that I investigate myself as having whitelist filters have but again I don't see how it is possible to block every single whitelist filter in filter lists using it. I also didn't say this would block unwanted 3rd party requests completely. If I was thinking like that then why would I use a blocker since I will never ever be able to block every single 3rd party ad/tracking requests. My rationale is I want to block as many 3rd party ads/tracking requests as possible and thanks to the great work of filter maintainers their block filters work well for this.

If I could code this I would but I'm just a user who requests this as I see a benefit for other users like myself. I personally don't think it is a feature any less appealing to small minority of users than some of the tickbox options in the Settings pane. But at the end of the day it is your extension and I respect your expertise and very much understand the worries you have about adding this to the code base.

[jspenguin2017]

This just landed in Nano, here is the diff if you are interested: https://github.com/NanoAdblocker/NanoCore/pull/67/files Update: This diff had a bug that can break element picker, well, it is outdated due to the recent (Jan 2018) refactor anyway. There are too many commits to Nano and it's hard to tell which one is for this feature now...
The diff for /src/js/advanced-settings.js is partial, so you have to fix lines 45 and 46 manually.

Removes ~8k network ~2k cosmetic on Nano's (almost) default. Removes ~7k rules from EasyList, probably something ultra paranoid people would be interested in. uBO has ignoreRedirectFilters and ignoreScriptInjectFilters, I don't see why not add ignoreThirdPartyWhitelist. Meh, even if it landed in Nano, it's not like I'm going to use it.

Quick comparison: