Closed migueldemoura closed 7 years ago
Feature creep. Declined. Requested before I will let you find the duplicate (it's time consuming): answer is best left to a specialized extension.
Was wondering how no one had ever made such request. I did search for the relevant keywords and found nothing relating to this exact feature.
The reason why I submitted this has to do with uBlock's philosophy, as read in the Readme.md:
uBlock₀'s main goal is to help users neutralize such privacy-invading apparatus
and the feature I suggested also technically falls under your usual requirement of being at the network or DOM level. Do you consider it feature creep for requiring a request redirection?
Would this make more sense to you if applied to uMatrix?
uMatrix already has a Spoof HTTP referrer string of third-party requests
, which aims at blocking similar behavior as the one I described (though obviously not in the same manner).
@migueldemoura https://addons.mozilla.org/firefox/addon/redirector/
@anewuser I know there are extensions that do this (I've just finished making one for chromium), but that isn't my point.
The point is that you don't understand the concept of feature creep.
@gorhill, what are your plans for the redirect flag?
It looks like he hasn't properly put in the documentation, but it was described in the release notes for uBlock Origin 1.4.0; there is related information related to redirect resources, as applied to inline script injection.
Thanks, that helped. As you said, he's going with uBO-vetted resources meaning that a) I can't specify an arbitrary url for the redirection and b) I can't use the matched url for selective substitutions in the query strings. I guess that leaves me with the my POC extension :smile:. Useful feature though.
I know it's possible to block requests with certain parameters in them, but given that most requests with such parameters are legit and afaik can't be blocked without breaking the whole page (I'm looking at you utm_*), I'd like to know whether you'd be willing to extend the syntax by adding a filter modifier that instead of blocking the request, strips the given parameters and casts the request afterwards.
Example1: https://www.example.com/?utm_source=source&utm_medium=website&utm_content=EN&utm_campaign=Campaign Example2: https://www.example.com/?ref=somewhere
Since that data can be processed server-side (and probably is), there's no way to block it without either blocking the request itself or removing the identifying bits.
I understand that this adds complexity, but I believe that there are enough wild cases to justify this.
Edit: Added examples.