Add wildcard support for TLD in $domain filters #1008
Comments
uBlock-user
changed the title
Which AdGuard list contains this filter? |
|
That is just example, we do not have this rule) |
|
So I am being asked to support something for which there is no current use case? I always need a use case, actually many use cases when it involves adding complexity to the filtering engine. |
|
AdGuard has AdGuard doc: https://kb.adguard.com/en/general/how-to-create-your-own-ad-filters#wildcard-for-tld Also tons of examples in this guy filters https://github.com/kano1/I but I'm not sure he know what he is doing. |
|
DandelionSprout/adfilt#63 (comment)
|
|
https://gitlab.com/eyeo/adblockplus/adblockpluscore/-/issues/123 claims that ABP also supports wildcards in That being said, it doesn't seem to work in ABP 3.8.4 to the degree I've been able to test it in the span of 5 minutes. |
|
As for an actual current use example, I'd have loved to be able to distill e.g. |
Neither did I, I asked about this years ago, but gorhill told that ABP syntax doesn't support this, so it never went ahead after that, |
|
It's not supported by ABP, what they fixed is to reject those filters when encountered. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
Related: gorhill/uBlock#2133. |
|
The only reason that I didn't declined this request outright is because of that one small part:
Now it turned out the provided filter did not really exist, I couldn't find it. I invested my own time to try to figure in which AdGuard filter list is located the mentioned filter. Other people invested their own time to finally find what @ediowar should have been taking the time to minimally detail as the requester: that there is a single instance of such filter in AdGuard list, specifically And furthermore, there is a need to detail what this filter solves. Is what it solve already solved in another way in uBO? If so what is the real benefit of asking someone else to spend time and effort implementing this in uBO if there is no current benefit to a majority of end users? So from now on, here is how this will work for request to add filtering feature to static filtering: If you are not a filter list maintainer with a reasonable enough track record of maintaining good quality filter list(s) in broad use, or if you are not making a convincing case that a specific static filtering feature is of benefit to a majority of end users, the issue will be declined without further comment -- i.e. issues equivalent to "do this kthxbye" are not accepted. I call these issues drive-by feature requests, i.e. non-long time contributors with little to no time invested to make the case of why someone else than them should invest more time and efforts in adding code and complexity, also taking into account future maintenance work of that code and complexity. The people who have my utmost attention when it comes to adding static filtering feature are those who actually have a track record of maintaining filter lists used by uBO -- they are the one who I want to help make their life easier whenever I can do so, as technically feasible as possible. As an example, the sole reason of why I agreed to add the The other people who have my attention are those who care enough to spend their own time making a convincing case of why a specific static filtering feature request is of benefit to a majority of users. Here is an example of such issue. Now regarding the specific issue of supporting entity syntax in Is this a must-have feature that you would start using regularly immediately or is it something that won't make a big difference to the workload in the big picture whether it's supported or not? (or any stance in between.) |
|
It would be useful in cases like this: to have the same thing to use in both places Even more, there are lot of sites often changing their TLD (but keeping the same js code / tricks) and the |
|
If it helps on the matter, I've now asked Andrey Meshkov and his pals on Slack about whether they plan to use If they were to say yes to my inquiry, it could lead to e.g. |
We can cc him in case he wants to answer here directly: cc @ameshkov |
|
Hey everyone, yeah, we're going to, but later, when it's properly supported by all AG versions. edit: which will happen in a couple of months from now. I wish I could be more precise:( |
It is a feature that would be useful in the cases that mapx- described and I would use it if available, |
From their discussion thread, it does not look like they want to support this. It seems their key argument is worries about false positives but I consider this a secondary argument regarding whether to support the option or not -- the same could be said of many other currently existing filtering options, what matters in the end is that filter list maintainers should be trusted to make the right calls when it comes to use whatever filtering options is at their disposal. For me the primary arguments is whether this will be used often enough and whether it makes the task of maintaining filter lists easier. So given the comments above, I decided I will support the syntax -- I don't see any issue to implement this code-wise. |
If already talking about distilling: The longest:From uBlock Unbreak L3441-L3442 (44) x 2 = 88:
From uBlock filters L8679-L8680 (9) x 2 = 18: From uBlock filters L8684-L8685 (8) x 2 = 16: From uBlock Unbreak L2148-L2149 (6) x 2 = 12: From uBlock filters L8447 (12): From uBlock Annoyance L788 (9): Apart from talking about distilling, I also provide a full list of all uBlock filters containing at least 2 domains which differ only by TLD, so you can check whether they will or not, benefit from implementing the wildcard feature: The Full List:uBlock filters: uBlock Unbreak: uBlock Resource Abuse: uBlock Annoyance: uBlock Privacy: Ok, I spent already 5 hours to collect and format the data, enought as for now |
|
I would like to make a plea for wildcard entity-like wildcard support for TLD's in domain. I use it in Adguard User Filters and it is really handy to cover all variants of country specific websites. |
|
Seems that ABP is going to add wildcards as well now: https://gitlab.com/eyeo/adblockplus/adblockpluscore/-/issues/123#note_339550064 |
|
https://gitlab.com/eyeo/adblockplus/adblockpluscore/-/merge_requests/334 seems to imply it is indeed underway, even if the technical details behind it elude me. |
Related issue: - uBlockOrigin/uBlock-issues#1008 This commit adds support entity-matching in the filter option `domain=`. Example: pattern$domain=google.* The `*` above is meant to match any suffix from the Public Suffix List. The semantic is exactly the same as the already existing entity-matching support in static extended filtering: - https://github.com/gorhill/uBlock/wiki/Static-filter-syntax#entity Additionally, in this commit: Fix cases where "just-origin" filters of the form `|http*://` were erroneously normalized to `|http://`. The proper normalization of `|http*://` is `*`. Add support to store hostname strings into the character buffer of a hntrie container. As of commit time, there are 5,544 instances of FilterOriginHit, and 732 instances of FilterOriginMiss, which filters require storing/matching a single hostname string. Those strings are now stored in the character buffer of the already existing origin-related hntrie container. (The same approach is used for plain patterns which are not part of a bidi-trie.)
|
Entity support wasn't added for |
This commit moves the parsing, compiling and enforcement of the `redirect=` and `redirect-rule=` network filter options into the static network filtering engine as modifier options -- just like `csp=` and `queryprune=`. This solves the two following issues: - #3590 - uBlockOrigin/uBlock-issues#1008 (comment) Additionally, `redirect=` option is not longer afflicted by static network filtering syntax quirks, `redirect=` filters can be used with any other static filtering modifier options, can be excepted using `@@` and can be badfilter-ed. Since more than one `redirect=` directives could be found to apply to a single network request, the concept of redirect priority is introduced. By default, `redirect=` directives have an implicit priority of 0. Filter authors can declare an explicit priority by appending `:[integer]` to the token of the `redirect=` option, for example: ||example.com/*.js$1p,script,redirect=noopjs:100 The priority dictates which redirect token out of many will be ultimately used. Cases of multiple `redirect=` directives applying to a single blocked network request are expected to be rather unlikely. Explicit redirect priority should be used if and only if there is a case of redirect ambiguity to solve.
This comment was marked as spam.
This comment was marked as spam.
Prerequisites
Description
[Description of the bug or feature]
AdGuarg rule example
||block.domain^$all,domain=google.*A specific URL where the issue occurs
[A specific URL is MANDATORY for issue happening on a web page, even if it happens "everywhere"]
Steps to Reproduce
Expected behavior:
[What you expected to happen]
Actual behavior:
[What actually happened]
Your environment
The text was updated successfully, but these errors were encountered: