Comment by vntok | Hacker News Reader

Comment by vntok | Hacker News Reader

Can't wait for the Chromium team to land the new permissions GUI so that all that whining around how MV3 is the end of uBlock Origin can stop. Many here will look silly overnight when that happens.

See here: https://bugs.chromium.org/p/chromium/issues/detail?id=113549...

> We have always intended to provide support for this functionality in Manifest V3 (for both user-installed and force-installed extensions), and have been iterating on different possible approaches. Our tentative plan (which is not yet finalized) is that the Manifest V3 version of this capability will require extensions to request a new permission scoped to intercepting authentication requests, but will otherwise allow extensions to handle these requests in a similar manner to how they do in Manifest V2.

> The permission string and end user facing warning string have not been finalized yet. Also, we have not yet finalized how this new permission will interact with other permission grants, but extensions that currently have the webRequest permission and broad host permissions will likely not require an additional grant for this permission.

The MV3/UBO issues are not really at all related to this ticket or GUI. The thing people take issue with is the removal of a number of mechanisms for intercepting and blocking traffic that uBlock Origin uses.

https://github.com/uBlockOrigin/uBlock-issues/issues/338 has a more detailed list of issues.

If you have a look at the bottom of the discussion in that link:

> The redirect-rule= filter option is also not compatible with DNR redirect action due to differing matching algorithm. In uBO, redirect filters do not compete with block/allow filters, as the redirect directives are looked up only after a network request has been matched to a block filter, whichever that is. This works differently in the DNR matching algorithm, redirect rules compete with other block and allow rules.

> The no-large-media-elements feature can't be implemented as this requires to inspect response headers on the fly.

> There is no concept of exception modifier filters in DNR, i.e. csp=/removeparam= exceptions cannot be accurately translated to DNR rules. For a specific example, all the removeparam= filter exceptions from AdGuard URL Tracking Protection, meant to override the main $removeparam=utm_source filter, can't be converted to DNR. At best, those exception filters maybe could be less accurately be excepted using the excludedRequestDomains property of the main $removeparam=utm_source filter.

These issues are all fixable by acting as proxy and inspecting/modifying/replacing requests on the fly (in sync/blocking mode).

> These issues are all fixable by acting as proxy and inspecting/modifying/replacing requests on the fly (in sync/blocking mode).

That is not possible in MV3, and is the center of the entire problem.

Which is why when the Chrome team finishes fixing these edge case tickets related to MV3 proxy features, there won't be major issues with uBO anymore.

Note that per its author himself, uBO Lite on MV3 already does the vast majority of the work uBO was doing on MV2, largely enough for regular non-power-users people.

Why even pretend like MV3 isn't meant to cripple adblockers so Google can extract more revenue from their advertisement business?

Do we have any evidence to support these claims?

If Google actually wanted to cripple adblockers, why wouldn't just ban them outright and remove addons used for adblocking purposes from the Chrome extension store, or completely remove APIs that allow for content blocking? Why would they develop a new extension API that still allows you to block ads at all?

Why isn't it possible that the new APIs might have actual benefits and exist for legitimate reasons?

I understand that companies suck and exist solely to serve themselves, and I fully support being skeptical, but I think users here are way too quick to jump on the hate train and start slinging FUD. Maybe you are right and Google is trying to cripple adblockers, but I'm not so sure yet and would like to see others at least consider an alternative perspective.

> If Google actually wanted to cripple adblockers, why wouldn't just ban them outright and remove addons used for adblocking purposes from the Chrome extension store, or completely remove APIs that allow for content blocking? Why would they develop a new extension API that still allows you to block ads at all?

They already did all this on the most popular version of Chrome. It seems very reasonable to assume their desired state is to match that version across all platforms.

Outright killing adblocking will reduce Chrome's market share significantly. Enough that Chrome may lose its position as the top browser. Its a terrible business decision that can kill Chrome or atleast give a chance for someone else to take their position. Why would they do that?

Crippling enough that most people won't notice is a viable business decision. Introducing a security benefit, inserting a self interest(crippling adblocks while providing vastly inferior alternative) which won't be noticed by most people but they are being secretly compromised behind the scenes since less ads are blocked and are being tracked more effectively is a profitable business tactic. Bringing a benefit along with a profit tactic compromising customers and pretending the said compromise is as big of a detriment to the consumer, which it is not, is whats going on. Is this so hard to see? Its not a FUD but the profiting parties trying to sway the opinions.

> Outright killing adblocking will reduce Chrome's market share significantly.

I doubt it from market share of Android Chrome https://gs.statcounter.com/browser-market-share/mobile/unite...

Isn’t that unrelated as it’s about the proxy issue and not the adblocking issue?

Reply on news.ycombinator.com