Hacker News Reader

Follow the links in the first paragraph of the article, they go into details about the technical aspects of why Manifest V3 is harmful to users.

It's disappointing to see this sentiment again, as this has been Google's tactic in the past decade: feign innocence and initiate technical discussions, then move goalposts and start over until their opponents are exhausted.

When we first heard of Manifest V3, it took them months to find a ridiculous reason for no longer allowing proper control over requests in Chrome, and they kept jumping between performance, privacy and security, as researchers refuted all their technical arguments one by one.

By now there is nothing left to discuss, they'd just need to stop being malicious.

> as researchers refuted all their technical arguments one by one.

Heya, do you have any links for that? Haven't really been keeping up with this whole thing. I briefly looked at the Privacy Sandbox proposal page a while back in late 2020 to figure out what it was all about, but haven't really got anything on researchers refuting their technical arguments.

> There was controversy over changes to the WebRequest API but that was two years ago and, I believe, changes have been made. Are there still changes that break functionality? What changes were made over the past two years? Have things gotten better or worse?

The WebRequest API’s blocking functions, which are central to the functionality of uBlock, are still slated to be removed.

Blocked under the supposed reason of privacy, but extensions can still see every request, and inject whatever javascript they want, exfiltrate your data, etc. Meaning the reason is pretty clearly not privacy.

Can you back this up?

Seems like a pretty clear case of being two-faced, and a small page laying out the details would be super helpful.

That Google said it was about privacy? There's some quotes in this article: https://whotracks.me/blog/manifest_v3_privacy.html

Or that extensions can still inject javascript, observe and log requests, exfiltrate data? I mean the api docs will tell you that. Extensions can do all that because they couldn't do a whole lot without those capabilities...normally used for legit purposes, but the apis can't really glean intent.

See things like onBeforeRequest for observe. Injecting javascript is called a "content script" in chrome extension terms. Exfiltrating data could be done in many ways, given that you can inject a "content script".

Thank you. I hope the author of the article reads this thread and ads a proper summary of the problematic changes that Manifest V3 introduces to the article.

The article does not mention changes over the last two years because there haven't been any to mention. The new WebRequest API still does not support blocking requests (and still does support _recording_ requests), and the replacement for that functionality is still very limited.

> WebRequest API still does not support blocking requests (and still does support _recording_ requests)

The whole point is that there would be no reason to allow any ad blocking extension access to the WebRequest API anymore.

The replacement, declarativeNetRequest, does not require the user to give any permissions, so the days of granting ad blocking extensions full access to every page are gone.

If you think Google is doing this for their own gain, I guess you can simply ask if declarativeNetRequest will be able to block all Google ads, or if you really need a turing complete language for that.

> The replacement, declarativeNetRequest, does not require the user to give any permissions, so the days of granting ad blocking extensions full access to every page are gone.

From what I see, it also has some strict limits. My basic uBlock+ install has 82780 network filter rules. Chrome seems to "only" guarantee 30000 rules, and I don't know if these match 1-to-1.

And there don't seem to be dynamic replacements, which might be useful to trick adblock detection. Not sure how far in the cat-and-mouse game we are on that front, but I sure don't like the idea of giving the mice highly limited rulesets while the cats can do and do whatever they like.

The current global rule limit is 300k rules per profile. This is shared between all extensions, which is shared amongst all extensions. This limit comes after the 30k per extension minimum, so if your extension uses 40k rules only 10k count against the global limit.

So if we assume rules are 1-to-1 (and in fact fewer rules should be present in declarativeNetRequest because certain rules like element hiding do not factor into declarativeNetRequest, and would be handled directly by the extension), you could fit ~5 adblocking extensions the size of your basic ublock install, and most of a 6th.

Now there are some advanced capabilities of some adblockers that have no equivalent available, but for common multi-plugin rulesets like EasyList, declaritiveNetRequest will support pretty much everything contained therein, (except cosmetic rules, which the plugin must apply separately, since they are not blocking requests, but modifying the page, which is quite different).

> The replacement, declarativeNetRequest, does not require the user to give any permissions, so the days of granting ad blocking extensions full access to every page are gone.

Great, but I want to give my add blocker access to every web page. That's kind of it's purpose.

Sure it could be abused, but not if you used one of the community recommended blockers.

> If you think Google is doing this for their own gain, I guess you can simply ask if declarativeNetRequest will be able to block all Google ads, or if you really need a turing complete language for that.

I am not sure if it will be able to block all google ads. Pretty sure it wont be able to remove their ads from search results, since you wont be able to remove/hide parts of the site. Also it wont be able to remove annoying pop up adds (sure it might remove the content of the ad, but popup will remain - well depending how its implemented.)

Also it is only limited to 30k max urls in a blocker. Nowdays my blocker has 80k+ urls. So i guess I would have to pick an choose (If i continued to use chrome).

> Sure it could be abused, but not if you used one of the community recommended blockers.

Why not? What stops someone from buying (or stealing or co-opting) uBlock Origin and using the fact that it has access to every user's web browsing to do some serious damage?

> If you think Google is doing this for their own gain, I guess you can simply ask if declarativeNetRequest will be able to block all Google ads

The answer to that is "no". declarativeNetRequest is a more restrictive version of what Safari current supports, and Safari ad blockers don't do as good of a job of blocking Google ads as ublock origin does.

> The new WebRequest API still does not support blocking requests (and still does support _recording_ requests), and the replacement for that functionality is still very limited.

Thank you. What you wrote is information that needs to be in the article but is not mentioned anywhere. The closest thing is a quote from Mozilla regarding their extensions security review process.

Browser extensions have a higher trust level than internet sites. V3 simply dis restricts the former which gives the latter more wiggle room. Sure, there are hostile browser extensions, but at that point security and privacy is already compromised.

It will impact µBlock Origin negatively for example and I want this plugin to be able to access the page unrestricted.

I agree with you. The article is terrible. It's a collection of reactions and scare quotes from industry figures. I followed the first few links in the article and they're not much better. You'd hope that EFF, of all people, would be able to make a simple and compelling summary of the issue.