> <i>There’s been a lot of confusion and misconception around both the motivations and implications of this change</i><p>Oh, heck off. This is Google's fallback whenever people call them out on anything -- "you just don't understand the entire picture." It's just their way of gaslighting critics.<p>People understand the change perfectly.<p>a) The privacy arguments are untrue because the Observational capabilities of the WebRequest API aren't being deprecated. There are no privacy benefits unless an extension voluntarily ignores that part of the API -- which no one will do because, as Google says:<p>> <i>when extension developers are given the choice between capability and security, the vast majority of developers choose capability.</i><p>Google makes the argument that 42% of malicious extensions use this API. Well, guess what they'll still be able to do under Manifest V3?<p>b) The vast majority of data suggests that ad blocker performance is not a serious issue on the web right now. Ad blockers pretty much universally help more than they hurt, so it's not clear why performance is such a big concern.<p>c) The declarative model is a less powerful alternative, which is the exact reason why Google is deprecating the blocking capabilities in the first place -- if they didn't force it, no one would switch (again, see their "why not both?" argument).<p>So what don't consumers and developers understand about this? It's an objectively less powerful API that does very little to improve privacy for the sake of performance improvements that aren't necessary.
They've addressed a number of complaints about limitations of the new API:<p>><i>Since the original announcement of the Declarative Net Request API, we have added significant functionality to the API as a result of these discussions. The Declarative Net Request API now allows for the registration and removal of dynamic rules - specified at runtime rather than statically in the manifest. We’ve also added the capability to remove common tracking headers, such as Referer, Cookie, and Set-Cookie.</i><p>><i>We are actively exploring other ways to expand this API, including adding methods to get feedback about matched rules, and support for richer redirects leveraging URL manipulation and regular expressions. Additionally, we are currently planning to change the rule limit from maximum of 30k rules per extension to a global maximum of 150k rules.</i><p>They posted a simpler post to the Security blog also addressing these issues.<p><a href="https://security.googleblog.com/2019/06/improving-security-and-privacy-for.html" rel="nofollow">https://security.googleblog.com/2019/06/improving-security-a...</a><p>They lead with the point that most-seemed to get lost in translation, even on technical sites like HN.<p>><i>No, Chrome isn’t killing ad blockers</i>
This seems like massive spin. Their primary argument doesn’t wash. As far as I understand it the web request API will still exist and still allow extension developers to view all request data. They just won’t be able to block the request and change it (I.e block content from loading)
> In addition to these safety concerns, there are also significant performance costs. In most cases, these costs are not from the evaluation of the extension script processing events, but rather from everything else coordinating the script. That overall performance impact can be very large, even for an extension written as performantly as possible where the JavaScript execution time is negligible.<p>Cannot they just instrument the code that intercept the requests and tell the user when performances are affected? Something like "It seems that extension xyz is slowing down Chrome. Do you want to disable it? Yes No [] Do not ask anymore"
No. It is incredibly hard to be cordial when you're trying to ruin the web and say that you're actually helping. I am livid. Because of content blockers the speed of web browsing has increased substantially. Because of content blockers users' security is vastly improved. ublock Origin has been doing the right thing and now you're going to make it harder. With the limits imposed by the declarative net requests at 150k developers and extensions that are safeguarding us are being hamstrung.<p>In addition, because of the Chrome extension team's obsession with using js workers instead of persistent processes we're going to have to deal with finding work-arounds for holding important and unencrypted things in memory. Someone brought up the issue that some extensions will have to create a newly pinned tab to the top left of the browser because of these inane bullshit rules removing the background page. Imagine a stack of pinned tabs just so your extensions can do their jobs. Does that sound dumb enough yet? Sometimes it's necessary to hold a lot of information in memory because the user actually wants the extension to do a certain task in a reasonable amount of time. They are making our jobs harder because they're too stubborn to understand that extension developers are the ones who create the magic. This is central governance at its finest.<p>These rules are stupid as hell.