Implement $queryprune parameter
#760
Comments
|
I also said:
I still do not see cases being brought up to justify the feature. |
Plus Aliexpress stm marketing parameters, and some others. Yes, of course, there are some specialized URL redirecting extensions that can truncate the URL parameters. But, they are all lack subscription feature. If you want to set up blocking those trash parameters from URL on a new device, you have to install a separate extension and after then manual enter all the parameters. And after time, then you discover a new trash parameter and want to get rid of it, you have to add it on EVERY device, even those which have parents, relatives and friends. This is a way of hell to explain to inexperienced users which buttons should be clicked and which values added. Instead of adding all that to neatly autoupdated filterlist. |
|
There are at least two cases in which the implementation of How Case 1: videos on ABC-owned TV station websites (
|
|
@llacb47 Is there an extension to rewrite URLs which you can use to confirm that removing the query parameters does really remove the ads? |
|
Yes, you can use You can import the rules I used to test: I just found that removing parameters also gets rid of SSAI on Discovery Networks sites as well. Test with these URLs: and this rule for redirector: |
|
Any update? |
|
It's not trivial to implement with as little impact as possible on performance, so this will have to take the time it takes to implement it. |
Related issue: - uBlockOrigin/uBlock-issues#760 The purpose of this new network filter option is to remove query parameters form the URL of network requests. The name `queryprune` has been picked over `querystrip` since the purpose of the option is to remove some parameters from the URL rather than all parameters. `queryprune` is a modifier option (like `csp`) in that it does not cause a network request to be blocked but rather modified before being emitted. `queryprune` must be assigned a value, which value will determine which parameters from a query string will be removed. The syntax for the value is that of regular expression *except* for the following rules: - do not wrap the regex directive between `/` - do not use regex special values `^` and `$` - do not use literal comma character in the value, though you can use hex-encoded version, `\x2c` - to match the start of a query parameter, prepend `|` - to match the end of a query parameter, append `|` `queryprune` regex-like values will be tested against each key-value parameter pair as `[key]=[value]` string. This way you can prune according to either the key, the value, or both. This commit introduces the concept of modifier filter options, which as of now are: - `csp=` - `queryprune=` They both work in similar way when used with `important` option or when used in exception filters. Modifier options can apply to any network requests, hence the logger reports the type of the network requests, and no longer use the modifier as the type, i.e. `csp` filters are no longer reported as requests of type `csp`. Though modifier options can apply to any network requests, for the time being the `csp=` modifier option still apply only to top or embedded (frame) documents, just as before. In some future we may want to apply `csp=` directives to network requests of type script, to control the behavior of service workers for example. A new built-in filter expression has been added to the logger: "modified", which allow to see all the network requests which were modified before being emitted. The translation work for this new option will be available in a future commit.
gorhill
changed the title
$queryprune parameter
|
It's in the latest dev build. See commit message for usage -- I do not want to provide details in release notes yet, I prefer filter list authors to experiment with usage to find out if fine tuning is necessary. |
|
Usage example - |
|
Avoiding This way uBO will scan the query parameters only when the URL is found to match the targeted query parameters. Mind performance when crafting filters. Your proposed filters forces uBO to scan every URL matching Additionally, prepending |
|
This comparision table from ClearURLs Wiki might be useful as well. |
|
To be clear, the purpose of |
Reported internally. Regression from: - 1e2eb03 Related issue: - uBlockOrigin/uBlock-issues#760
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.
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.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Hosts & pDNSF rules - Add multiple `Adjust` tracking domains, in pDNSF will use wildcard instead. uBO Test list - Add query prune experiment for enhance privacy (a little bit?) * Note: Query prune tests is require install dev build of uBO version 1.30.9b1 or above, more info can be found at uBlockOrigin/uBlock-issues#760
|
Does it make sense to use separator placeholder ( And how about using WARNING! Using |
|
Filters: Address: Result:
1.30.9b3 WARNING! Using |
|
Makes no difference, uBO can extract a token in either case. 1st = |
|
Okay, so doesn't matter as long as at least one good token can be extracted. Thx! |
|
Some |
|
Wait, is |
|
|
|
That's essentially what I've asked. @gorhill Maybe the old comment could be edited to prevent confusion as |
Hmm... unexpectedly... |
|
One more caveat The rule "$removeparam=/word/" will remove any parameter which value contains "word" - for instance, clears google etc. query with that word. Turned out, this is described in the wiki, but still looks weird. https://github.com/gorhill/uBlock/wiki/Static-filter-syntax#removeparam : |
|
If the link contains Example: uBlock Origin development build 1.50.1rc3 + RU AdList + Counters Screenshot(s)
|
|
That's because everything after the # is no longer part of the query string: https://developer.mozilla.org/en-US/docs/Web/API/Location/hash |
|
If you have tracking stuff after I suppose we could have a scriptlet to deal with this. |
|
I noticed that ClearURLs solves this problem, so I had an idea to improve the removeparam. |
|
Interia started mask tracking https://www.interia.pl/#utm_source=Wydarzenia&utm_medium=logo&utm_campaign=powrot_z_wew&iwa_source=logo
https://wydarzenia.interia.pl/#iwa_source=logo
https://poczta.interia.pl/#iwa_source=sg_ikona
https://www.pomponik.pl/#iwa_source=sg_ikona
https://programtv.interia.pl/#iwa_source=side_menu |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
|
How to remove
And |
|
@D4niloMR example ? |
|
Add And visit |
|
Related feedback: uBlockOrigin/uBlock-issues#760 (comment) Using quotes in filter option values is meant to remove ambiguity when the value contains special characters. This was not working when the value started with `$`. For example, fixes usage of quotes in: $removeparam='$deep_link' Also, fixed logger output for scriptlets using empty parameters in quotes.
|
I wanted to suggest using quotes, but turns out this didn't work as I expected: Fixed with gorhill/uBlock@8ba71f0. |
|
It works, but |
|
But you are right anyways, it doesn't handle all cases: I can probably improve but I have to be very careful to not cause regression in the parser for all existing filters, and I have to ensure that the fix doesn't introduce a more costly overhead to parsing. At least for the time being one can always use the regex workaround: |
regex will still work |
|
@gorhill what do you think about supporting escaping |
|
Forcing maintainers to escape |
Prerequisites
Description
In #46 about $rewrite parameter author said:
Will the $querystrip parameter be realized?
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: