3 ms·

>uBlock Origin has over 10M installs and the author has stated publicly that they cannot effectively do what they do if this change goes ahead. With the new ch

>uBlock Origin has over 10M installs and the author has stated publicly that they cannot effectively do what they do if this change goes ahead. With the new changes to the spec outlined in this post, this may not be true anymore. Rules can now be updated with an extension update, network headers can be blocked, and the number of rules has been increased. I don't know exactly what other features may be needed, but I imagine this helps close the gap. We'd have to hear from gorhill to know more.

danShumway 7y ago
If you're curious, here's Gorhill's reaction immediately after Chrome announced they were planning to support dynamic rules. None of the updates seem to have changed his position that this would cripple Ublock Origin. https://github.com/uBlockOrigin/uBlock-issues/issues/338#issuecomment-464340152 https://github.com/uBlockOrigin/uBlock-issues/issues/338#iss... > I don't know exactly what other features may be needed I know this sounds like a dismissive, catch-22 answer, but the big thing missing is being able to run arbitrary code to decide whether or not a request should be blocked. And that is something the Chrome team has been pretty clear that they are not going to compromise on. Right now, people are compiling lists of different filter capabilities they want, but (at best) that is only going to close the gap some of the way to what ad blockers are currently doing. Ultimately this puts Chrome in the position where every time a developer comes up with an interesting strategy for blocking ads or filtering/redirecting web traffic, they'll need to go to Google and ask them for permission to do it. The fundamental functionality block is the thing Google wants to block -- arbitrary, developer-defined logic. This is not nearly as complicated of a situation as Google is making it out to be. Google is arguing that developers should not have the ability to arbitrarily block requests, and developers (particularly ad block developers) are arguing that they should. Gorhill's position is that matching algorithms are fundamentally not powerful enough to support a healthy ad blocking ecosystem.

danShumway 7y ago

If you're curious, here's Gorhill's reaction immediately after Chrome announced they were planning to support dynamic rules. None of the updates seem to have changed his position that this would cripple Ublock Origin. https://github.com/uBlockOrigin/uBlock-issues/issues/338#issuecomment-464340152 https://github.com/uBlockOrigin/uBlock-issues/issues/338#iss... > I don't know exactly what other features may be needed I know this sounds like a dismissive, catch-22 answer, but the big thing missing is being able to run arbitrary code to decide whether or not a request should be blocked. And that is something the Chrome team has been pretty clear that they are not going to compromise on. Right now, people are compiling lists of different filter capabilities they want, but (at best) that is only going to close the gap some of the way to what ad blockers are currently doing. Ultimately this puts Chrome in the position where every time a developer comes up with an interesting strategy for blocking ads or filtering/redirecting web traffic, they'll need to go to Google and ask them for permission to do it. The fundamental functionality block is the thing Google wants to block -- arbitrary, developer-defined logic. This is not nearly as complicated of a situation as Google is making it out to be. Google is arguing that developers should not have the ability to arbitrarily block requests, and developers (particularly ad block developers) are arguing that they should. Gorhill's position is that matching algorithms are fundamentally not powerful enough to support a healthy ad blocking ecosystem.