Skip to content
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

Documentation for interaction between important and redirect filters #1224

Closed
8 tasks done
antonok-edm opened this issue Aug 26, 2020 · 6 comments
Closed
8 tasks done
Labels
fixed issue has been addressed wiki related to wiki

Comments

@antonok-edm
Copy link

antonok-edm commented Aug 26, 2020

Prerequisites

  • I verified that this is not a filter issue
  • This is not a support issue or a question
  • I performed a cursory search of the issue tracker to avoid opening a duplicate issue
    • Your issue may already be reported.
  • I tried to reproduce the issue when...
    • uBlock Origin is the only extension
    • uBlock Origin with default lists/settings
    • using a new, unmodified browser profile
  • I am running the latest version of uBlock Origin
  • I checked the documentation to understand that the issue I report is not a normal behavior

Description

From the static filter syntax documentation it's not clear what the interaction between important and redirect rules should be, for instance, with these two rules from the uBlock Privacy filters:

||addthis.com^$important,3p,domain=~missingkids.com|~missingkids.org|~sainsburys.jobs|~sitecore.com|~amd.com
||addthis.com/*/addthis_widget.js$script,redirect=addthis.com/addthis_widget.js

Given the current documentation, I would assume that the important non-redirect filter would override the behavior of the redirect filter and block all network requests to addthis.com from domains other than missingkids.com, missingkids.org, etc. with an error response.

However, it appears the current behavior in uBO is to load the redirected version anyways, e.g. on the URL below.

A specific URL where the issue occurs

https://www.rhmodern.com/catalog/product/product.jsp?productId=prod14970086&categoryId=cat7150028

Steps to Reproduce

  1. Read through the static filter syntax documentation, in particular the important and redirect sections.

Expected behavior:

It would be ideal to have a description of how these two filter options interact.

Actual behavior:

There is no description and it's unclear how the options interact.

Your environment

  • uBlock Origin version: v1.29.2
  • Browser Name and version: Brave 1.12.114 (yes, shields down)
  • Operating System and version: Arch Linux
@uBlock-user
Copy link
Contributor

@gwarser

@okiehsch
Copy link

Given the current documentation, I would assume that the important non-redirect filter would override the behavior of the redirect filter

Why?
https://github.com/gorhill/uBlock/wiki/Static-filter-syntax#important
"The filter option important means to ignore all exception filters (those prefixed with @@)."

A redirect filter is a blocking filter, so the important filter will have no impact.

@gorhill
Copy link
Member

gorhill commented Aug 28, 2020

A filter using the redirect= option is really just a convenient way of creating both a blocking filter and a redirect directive at once:

||addthis.com/*/addthis_widget.js$script,redirect=addthis.com/addthis_widget.js

Is internally translated into:

||addthis.com/*/addthis_widget.js$script
||addthis.com/*/addthis_widget.js$script,redirect-rule=addthis.com/addthis_widget.js

Redirect directives (redirect-rule=) do not understand and interpret important, so it makes no difference whether that keyword is used in a redirect directive. Redirect directives are looked up whenever a network request is blocked, regardless of how it was blocked.

@uBlock-user uBlock-user added fixed issue has been addressed and removed something to address something to address labels Aug 29, 2020
@antonok-edm
Copy link
Author

@gorhill just a heads up, I noticed you added a link to the AdGuard filter documentation to the wiki recently - their redirect behavior appears to be different from uBlock Origin's:

$redirect rules' priority is higher than the regular basic blocking rules' priority. This means that if there's a basic blocking rule (even with $important modifier), $redirect rule will prevail over it. If there's a whitelist (@@) rule matching the same URL, it will disable redirecting as well (unless the $redirect rule is also marked as $important).

Also, I noticed there are a decent number of filters which have both the important and redirect options together, e.g. ||google-analytics.com/analytics.js$important,script,redirect=google-analytics.com/analytics.js,domain=support.amd.com. Am I correct to assume that this is equivalent to the following?

||google-analytics.com/analytics.js$important,script,domain=support.amd.com
||google-analytics.com/analytics.js$script,redirect-rule=google-analytics.com/analytics.js,domain=support.amd.com

@gorhill
Copy link
Member

gorhill commented Sep 12, 2020

Am I correct to assume that this is equivalent to the following?

Yes, that is correct. One is a block filter, the other one is a redirect directive, looked up only when a network request is blocked (however it is blocked, including via dynamic filtering). The AdGuard documentation regarding redirect does not really apply to uBO -- there is no competition between block filters/rules and redirect directives in uBO, they are different things.

@keczuppp
Copy link

keczuppp commented Dec 8, 2020

Because can't write this HERE because the whole old repo is locked and and limited, I'll put it here:

We, PL devs, want to announce we've found a WEBSITE where redirect=click2load.html functionality has been proven to be useful ! And the filters have been added to our filter lists: MajkiIT/polish-ads-filter@94f4eeb + FiltersHeroes/PolishSocialCookiesFiltersDev@f006215

The aforementioned website orionblues.pinger.pl is a kind of a blog website on which the owner stupidly added terrifying amount of youtube frame embeded videos (he probably not being a tech-savy guy...), turning the whole webpage into a resource abuse kind webpage, what causes the following issues on the webpage:

  • the webpage takes very long time to load - almost a minute
  • the webpage abuses a cpu core with 100% usage until the whole webpage completes to load
  • the webpage interferes with polish addon Polish Cookie Consent which (the addon) tries to hide (accept / click) GPDR message on the webapge, in the result the GDPR message is not being hidden

The addition of redirect=click2load.html filters have solved all the issues !

It would be worth to mention redirect=click2load.html in the WIKI documentation as well,
because as for now it was only mentioned in the RELEASE which may soon drown in the depths of the releases ocean.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
fixed issue has been addressed wiki related to wiki
Projects
None yet
Development

No branches or pull requests

5 participants