-
Notifications
You must be signed in to change notification settings - Fork 81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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.
$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 |
Related feedback: - uBlockOrigin/uBlock-issues#760 (comment) This is a quick fix, some refactoring necessary for a more comprehensive fix to all such issues.
Today I found $removeparam=param is case-sensitive even without regex. Maybe this should be documented in Wiki. |
It was not in the beginning, Ctrl+F for "case" above. I'm not even sure it's not a bug. Aligning to AdGuard spec shuffled spec around. |
Yep, found
|
@gorhill #760 (comment) |
AFAIK no, no word boundary. It will be possible with a @gorhill ?
What exactly? For plain strings, no pipe anymore in new syntax, and only one parameter per filter. |
Not sure why you are asking this, but see @gwarser. In that case, |
Wanted to know which one is better: |
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 |
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 |
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: