[Feature request] Add RegEx for dynamic filterrules

[j-lakeman]

Prerequisites

• I verified that this is not a filter issue (MUST be reported at filter issue tracker)
• This is not a support issue or a question
• I performed a cursory search of the issue tracker to avoid opening a duplicate issue
• The issue is not present after wholly disabling uBlock Origin ("uBO") in the browser
• I checked the documentation to understand that the issue I report is not a normal behavior

I tried to reproduce the issue when...

• uBO is the only extension
• uBO with default lists/settings
• using a new, unmodified browser profile

Description

I have JavaScript blocking enabled, but wish to be able to deactivate it for a range of webpages, e. g. all with the string "git" in them. I really appreciate the regex function in the exception rules section and would like to have something comparable for the dynamic rules section.

A specific URL where the issue occurs

https://github.com/

Steps to Reproduce

lorem ipsum

Expected behavior

Being able to use regex like no-scripting: /^.git./ false

Actual behavior

no-scripting: github.com false
no-scripting: gitlab.com false

uBlock Origin version

1.44.0

Browser name and version

Firefox 104.0.1 (64-Bit)

Operating System and version

macOS Big Sur 11.6.8

[Yuki2718]

I tend to wish if it supported entity filter i.e. * www.example.* * noop. This will save lots of adjustment for rapidly changing movie sites. The regex in dynamic rule, however, will be in most cases not tokenizable as in the example, and also it's kinda against the spirit of the feature - the suggested rule allows githiimamalwaresite .com too.

[j-lakeman]

Yeah sounds fair

[gorhill]

There is no tokenization taking place in dynamic filtering rules, it's all lookup tables using hostnames as keys, hence why it's fast compared to static filtering -- and using lookup tables means no possibility of regex or wildcard. I do not intend to change this.

[j-lakeman]

Aight thx for clarifying

[Yuki2718]

Forgive me for thought experiment. Will this be too much code change to add a user-editable variable, say, ? (whatever simbol but to distinguish from wildcard).

1. User defines what TLDs he wants to include into ? e.g. ?-means: app,buzz,com
2. Whenever user create a rule with ? manually via dynamic rules pane, uBO internally translates to rules of all these TLDs i.e.

* * www.example.app * noop
* * www.example.buzz * noop
* * www.example.com * noop

but in the pane it shows as * www.example.? * noop Too many use of this will cause high RAM usage as the actual numbers of rules diverge (particularly example1.? example2.? * noop) but those who use this are expected to be sensible. It's impossible to incorporate all the public suffix but those TLDs used by rapid-changing sites are limited. Once you have defined most of TLDs actually used, it frees up the needs for regular adjustment to some extent.

[gorhill]

Will this be too much code change to add a user-editable variable

Yes.

The purpose of dynamic filtering is not to converge toward static filtering capabilities; the purpose is to be a point-and-click way to add/remove hostname-based firewall-like rules. Any sort of syntax for which there are no point-and-click user interface is not a good fit for dynamic filtering, that falls into static filtering realm. Beside, proposing complications like this should always, always come with real world cases to support such propositions. When you start to look at real world cases, I highly doubt they will prove to be valid use cases.

[Yuki2718]

I highly doubt they will prove to be valid use cases.

I meant e.g. kisscartoon.*, kissanime.*, and all similar sites which regularly change TLDs but okay, thx for taking time.

[gorhill]

I meant e.g. kisscartoon.*, kissanime.*

People visit specific ones, so they will point-and-click for the one they end up visiting. An actual use case would go in details to show why it's really tedious for dynamic filtering users to point-and-click on the kisscartoon sites they happen to visit. I highly doubt someone would complain that they need the feature because they visited 10 kisscartoon sites and had to set the same set of rules, and if so, I would advise them that since they are willing to manually create rules, might as well use static filtering with a filter such as ...$domain=kisscartoon.*,denyallow=.... There is just no convincing actual and detailed use cases being made to justify the amount of work requested from others.

I gather that if people who request such features would have to do the actual work themselves to implement it while also able to apprehend the sprawling complications to the point-and-click user interface, the performance implications, and the future workload of merely maintaining all that new code, they would realize the task of managing a few dynamic rules with the current implementation is completely trivial in comparison.

[gwarser]

Duplicate of #439