-
Notifications
You must be signed in to change notification settings - Fork 77
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
ABP's $rewrite filter option #46
Comments
Why not:
|
So |
Allow only to delete parts of the url? |
Copy/pasting here a comment I made yesterday in Teams after I pondered this for a while: gorhill May 22, 2018, 10:19 AM EDT I won't implementing this filter option, I see too many issues with it. I am however open to implement a different filter option with similar purpose, but which would not suffer the issues I see with how My concerns: Security: testing same origin for redirect URL is not enough: both Security: even with strictly same origin, a malicious filter list author could add bad stuff to a network request. Performance: the Given these concerns, I see a better way to implement similar option but with a more focused purpose: to remove specific query parameters from a URL:
Where the Sticking to remove query parameters takes care of the ownership and malicious filter list author issue for the most part -- the filter removes query parameters, it can never rewrite them into something else. The performance concern no longer exist with such filter, since it does not have to be a regex. The value of the Now this does not remove some other concerns I see with One is that it is designed as a block filter. What if I really want to block using My current thinking is that a Anyway, as said I still need more than just one case to be an argument for such filter -- the last thing I want is to add technical debt to uBO for little tangible benefits overall. Note that a site could simply convert their |
Also ABP code can handle
👍 and other cases (utm_*) can be handled by specialized URL redirecting extensions. |
Yea, Also I don't see how the new ABP build can get pass AMO review since it allow injection of arbitrary script. (Or I'm missed something?)
The background script of uBO-Extra can be made configurable (unlike the content script), so we can include a switch to enable / disable part of its URL rewriting rules. |
How to make this exception-only option? Request can be blocked by one filter, and then repaired by |
Exception filters also obey the first-match rule. You could end up with another exception filter such that the A scriptlet for that specific purpose seems to be the right approach (an XMLHttpRequest wrapper to remove query parameters), it's injected only on sites where it's needed, can be excepted, and adds no global overhead to network request handling. |
No it doesn't inject arbitrary scripts. |
@hfiguiere What mechanism it has to prevent #46 (comment) from happening? |
The example in #46 (comment) change the origin, so the rewrite doesn't happen in that case, and the original query is let through. |
@hfiguiere OK, so what about rewriting an URL from RawGit? You can control the content served from RawGit pretty easily, and all files served from RawGit are under |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Will be implemented in Brave brave/adblock-rust#184 https://www.reddit.com/r/uBlockOrigin/comments/poy9us/interest_in_redirecturl_filter_option/ |
Since this was marked as duplicate elsewhere, I'll mention it here: What if the syntax to rewrite a URL only functioned in My Filters, and was not parsed anywhere else? This would protect users from malicious list maintainers while still allowing people to do this. An example I have for a use case is redirecting requests to |
uBO is mature software at this point, and my focus is to do work on code which help filter list maintainers. What you ask can already be accomplish by specialized extensions out there. |
That's fair, really Request Control is the right extension for this, but unfortunately uBO has a habit of breaking literally any other network filtering extension I install no matter what order they're installed in. In this case, if I block the Google API request and allow the Cloudflare one, uBO blocks the whole request before Request Control can rewrite it, and if I allow both calls uBO inexplicably forwards the request to Google without letting Request Control interact with it, at least as far as the logger says. |
Blocking has precedence over redirecting, regardless of extension order of processing. Just don't block network requests you want to be redirected to a different server.
uBO doesn't "forward" requests, it merely do not block them. Requests which are not blocked by one extension can be freely redirected by another one. If it's not working, you need to investigate your other extension as to why it's not working. |
That's new information to me, thank you, but when I allow it in uBO for Request Control to redirect my log seems to show a request to Google and then a request to Cloudflare, which suggests to me that the request is not being redirected but repeated. This behavior is not caused by Request Control, as when uBO is off it does not happen, as far as I am able to tell. Is there something I'm overlooking? EDIT: I'll try logging the network requests at the OS level to see if maybe it's just an issue with how the browser is reporting them. |
What is that "log"? If it's uBO logger, then it's normal it's showing you a network request to Google not being blocked (if that is the one you want to be redirected), because everything shown in the uBO's own logger is from the point of view of uBO, and if the request is not blocked by uBO, then the logger will show it as not being blocked. Use the browser dev tools to see the final outcome of which network requests are blocked/redirected/allowed. |
I initially used the uBO logger and saw that, and then checked the network tab in DevTools and was getting inconsistent results. Like I said, I'll try to examine it better. |
|
|
I'm just saying a lot of features have been added without that much community input. Ublock Origin is not mainly and should not be mainly something like a user script extension. Sure, userResourcesLocation exists, but Ublock Origin had the benefit of getting filterlists from absolutely any source (with the exception of userResourcesLocation) without worrying about some potentially dangerous script execution (Don't understand this wrong, I'm not arguing against adding actual useful features which are necessary) |
So what should filter list maintainers do when a large website with large users target uBO specifically and change scripts everyday and quick fix list cannot keep up? Then hundreds of users come to uBO reddit and github to complain every day? Can you help us managing those users? Can you help us update the filter lists when the website updates while it's 1AM-3AM and filter lists maintainers cannot stay up that late? |
Like Yuki said,
Which is better, feature creep and increased attack surface, or having to update filter lists more frequently
Are they all in the same timezone? If we must do this to defeat anti blockers, we need to think carefully, mitigating the attack surface. The adding of trusted scriptlets to UbO must be done carefully. I'm talking about the attack exposure. |
The community is pressuring the maintainers for quickly defeating anti blockers, but I still believe we need to justify new trusted filters and as I previously said, we must not trade security for functionality. See #2229 (comment) |
As opposed to |
Hi, gorhill. Sorry for the rant, but I never expected anti blockers to force us to add fully custom filters Edit: (I mean trusted scriptlets). See #2229 (comment) |
Then the best way for gorhill is to abandon the project and let whoever can take those ideas do whatever they want. I'll support that decision with both hands and I could be able not to waste my time dealing with filter lists and users any more. If you have any ideas to both develop the way you think it's better and to counter with the codes website changes everyday, just develop and PR it. Talking sarcastically and literaturely without any actions to contribute just wastes time on both sides. If that's difficult, you can voluntarily help us update the filter lists and talk with users out there. Is it ok? |
You must be new here then. As new tricks and ways appear, uBO continues to develop new features too. This has been ongoing for last 5 yrs and beyond... |
I don't understand what that means. Can you clarify? |
In case you don't know, in the last uBO stable release, uBO survived that large website anti blockers solely due to 1 of the trusted scriptlets for weeks before new release could come out while there was litetally no other ways to counter with other scriptlets. |
Do not misunderstand! I have known for years scriptlets have been essential to uBO. I'm talking about the trusted scriptlets. By "fully custom filters" I mean filters that can now do pretty much the same things a user script can do. It's now clear that the evidence for usage of trusted filters has been growing. See also #2229 (comment) |
Necessity is the mother of invention. There came a time when we cannot limit ourselves, hence the concept of trusted sources came. Also this concept arrived in AdGuard first fyi. As for "filters that can now do pretty much the same things a user script can do", it's been like this even before trusted sources came with the help of advanced setting called |
I know, I myself use medium mode and am an "Advanced User". I just don't use a userResourcesLocation (not an argument) |
The userScript point of yours has nothing to do trusted sources concept which you were attributing the reason. That's my point. Once |
Yes, I still remember when the subreddit was once filled with advice on how to bypass Twitch ads. |
This is not "feature creep", what is being done is necessary to fulfilled user expectations from their content blockers given how websites evolved. "Feature creep" would be warranted if uBO become large inefficient piece of software, but that is not the case, I am confident that it's still the most efficient content blocker by a good margin given it's capabilities. The added features are for the most part not visible to users, i.e. we are not adding buttons and widgets in the user interface, we are adding filtering capabilities in order to improve content blocking in way that is seamless to users, and a testament to this is that vast majority of people out there (before Youtube crackdown anyways) have no idea that the "seamless" aspect is due to filter list maintainers constantly working behind the scene, with the capabilities offered by the filtering engines in uBO. It seems at this point you are arguing against evolving uBO to keep up with websites, arguing for stagnation which will lead to irrelevancy. If you have better solutions to the issues we are facing, best to suggest something actionable and concrete, so far you are not proposing anything actionable beside what is essentially "stop working on uBO". |
I'm not arguing against Ublock Origin's performance, I just had this (unlikely, but potentially (in the very, very long term, actionable) worry here). I'm not arguing for stagnation in any way, shape or form. |
see
https://issues.adblockplus.org/ticket/6592
https://issues.adblockplus.org/ticket/6622
related:
https://issues.adblockplus.org/ticket/6242
The text was updated successfully, but these errors were encountered: