The design doc — the part quoted in the note linked here even — explicitly notes that it will probably be required to retain some degree of the existing functionality slated for eventually removal until the new API and other replacements cover all use cases; the response linked here appears to (not improperly, in the context of making a case for why much of the functionality is needed) ignoring that and treating the planned intent as removing all of the existing WebRequest API functionality that is not observational for a hard cutover to the new API which does not immediately supports large swath of currently used functionality.
I think the response is appropriate, energetic advocacy, but the HN headline is hyperbolic.
Google is an advertisement publishing company. All the things they do, they do to earn money, not to give people anything. When Chrome first appeared, I was wondering about the extremely huge cost of building the browser and how Google wants to earn from that. Then it started to be obvious: it's all to spy on people. Not from the beginning, but slowly... the google account integration... the forced logging into the account... adding custom adblock (which doesn't block most of the ads)... and now this: disabling adblockers.
To defend Google a bit, it looks like the change is being put in place so that users would have more privacy – by stopping extensions accessing all active URLs.
In essence they are copying what Apple did with Safari and their content blocking APIs. In this model, content blockers provide the browser with a set of blocking rules and the browser executes them against pages during render & load. Ad blocking can occur and privacy of what the user is viewing is retained.
Sure it's more restrictive and yes will likely break existing adblockers, but it's probably a better model for the future.
There will be arguments that you "can't do what is necessary" to create effective adblockers. That's incorrect.... I've created such an adblocker [1] using the Safari methods and its efficient, effective and high performance – including loading some sites 2x faster.
Using uBlock in Chrome is like asking a bank robber to guard an open vault. Sure, they’re smart enough not to steal anything, but they’ll case the joint the entire time and you’ll never sleep well again.
I highly suggest looking into Opera. It is also based on Chromium and therefore backwards compatible with extensions, bookmarks, etc. I switched around 6 months ago and haven't looked back since! They have built in VPN, adblocker, Turbo, screenshot, news, and more! Been really happy with it so far.
"In Manifest V3, we want activeTab-style host permissions to be the default, with a number of extra options. Instead of being granted access to all URLs on installation, extensions will be unable to request <all_urls>, and instead the user can choose to invoke the extension on certain websites, like they would with activeTab. Additional settings will be available to the user post-installation, to allow them to tweak behavior if they so desire."
--- https://docs.google.com/document/d/1nPu6Wy4LWR66EFLeYInl3Nzz...
Yikes! I'm one of the maintainers of the Remote Browser open source project [1]. It's a cross-browser compatible automation framework which heavily leverages the power of vanilla JavaScript and the Web Extensions API to offer features comparable to those of Selenium (without the legacy cruft). Removing the ability for extensions to interact with arbitrary pages would effectively break Remote Browser's compatibility with Chromium/Chrome overnight. I have a feeling that there are a staggering number of interesting extensions that will break due to the various V3 manifest changes. Hopefully the outrage over uBlock Origin will push Google to reevaluate this decision.
I don't understand the technical details of this - could someone explain it to an idiot?
- Is the change specifically to block ad blockers, or uBlock specifically? Or is it just a new extension API?
- Could ad blockers adapt to the new version to work again?
I am reminded of the new version of (Mac) Safari, which features a new extensions API. It took a while for them to appear but there are now good ad blocking extensions again, like AdGuard for Safari.
From what I understand, there are currently events which gave you the ability to inspect, and also cancel a request if you want. This allows you to do things like cancel a request if it's trying to download a big video file.
But Google wants to remove the ability to cancel a request through the events, and they want to replace that with declarativeNetRequest[1]. If you look at the link, in the Rules section, it seems to be simple, kinda hardcoded (but configurable) filters.
You can also see there's a limit of only 30,000 rules[2], which is not enough for EasyList[3] (example used in the tracker), which seems to have ~74,000 rules.
This is not targeted to ad blockers specifically. It's a change that makes blocking requests less flexible. For example, uBlock and uMatrix rules can be overridden by more specific rules, something that declarativeNetRequest can't do.
I would defer to someone more knowledgeable, but here's my take:
1. Google is proposing to limit the API uBlock Origin uses, and replace it with a less capable one.
2. Google also plans to put artificial limits on the new API (30,000 rules or something), which will make it even more difficult to make an effective ad blocker. That's not even enough to implement current blocklists.
3. The new API is inflexible, so it will be difficult to impossible to create innovative ad blockers in the future.
ghacks does a great job of explaining this (saw it first here).
Paraphrasing the article: Basically, they are limiting filters (used by ad-blockers) to 30k. Lots of blocking lists use more than 30k.
This is part of (possible) removal of blocking options from the webRequest API and the (possible) move to declarativeNetRequest to handle blocking requests.
The problem is with the limit on the number of filters. On desktop Firefox I have ~120,000 network filters active on uBlock. Safari on iOS limits the number of filters an adblocker can have active to 50,000 and Google are proposing limiting it to 30,000 on Chrome.
Used to love google, for many many years. Slowly starting to despise them, though.
It's different for everyone, but for me it started with this gmail redesign that made the product so slow it's almost worthless to me. And worst of all is I feel like there isn't even a good competing service to switch to.
I think for most people, their image of Google was formed when gmail was released. Most mail providers offered mailboxes 10MB in size and Google upends all of that offering "free" mailboxes 1000MB. Respect for their command of technology formed with every product.
Then people started to realize Google only introduces products that collect data in a new way from its other products. If it can't survive that test then it doesn't exist. Ugh.
I blame the CEO. Is it a coincidence that all the best Google products peaked in 2012-2016?
They literally removed the don't be evil motto as the reason for their conduct.
People will say that they still have, but that's just a stupid line at the end. They used to have a whole preface dedicated to it and have the code of conduct based around it.
I switched to protonmail a few months back, and have been very happy with the service. They focus on privacy and security as a core value. They have a limited free account (limited in terms of storage space and message volume), so not a direct replacement for gmail. I use the paid service for more storage and a custom domain.
The comments in the linked thread don't really go into why this change was made, but I think Google deserves the benefit of the doubt that the proposal was made in an effort to improve other aspects of the browser (speed or maintainability, for example)
So we have a browser with nearly 70% market share, made by an advertising company that's arguably the most powerful business on the internet, interfering with ad blocking. And of course there is no regulatory body that is able or willing to step in.
Google has shown some Chutzpah to sell their own ad blocker when they are the #1 advertising vendor.
If feel they have enough impunity to get away with that, then it is no surprise that they will try to put other ad blockers out of business too.
Other ad networks might be big enough to bring an antitrust lawsuit against Google (although they probably won't last long enough) but Ad Blocking is such a niche market that they couldn't possibly sue.
Ouch, I understand why they want to not have a blocking webRequest API but I consider uBlock Origin to be a must-have extension. Hopefully this is relaxed somehow.
I personally still use Firefox at home despite recent issues, but I honestly would prefer having both as an option, plus I always recommend uBlock Origin to everyone.
(Disclaimer: I work at Google but not on Chrome, opinions are mine and not my employer's.)
Why would Google be given any benefit of a doubt in the case of ad/resource blocking?
They are a behemoth ad-based corporation that is becoming a monopoly in many areas of computing. In yet more areas, they are becoming an effective monopoly through size: they may not be the only company offering a type of service, but they are the only one able to offer it at scale and/or with a certain level of sophistication, given their resources are orders of magnitude larger than almost any other company's.
All this taken into account, it's obvious how much is at stake for them. Why wouldn't they try crippling blockers? Their revenue depends on it and the only counter-incentive is that there may be a massive exodus of users to Firefox, while it still exists. Do it slowly enough, though...
I don't think I can go back to the internet without uBO+uMatrix.
On a related note, why doesn't Chrome for Android have extensions? I get the sense it's because it was more strategic to ban extensions entirely than to allow ad blocking on mobile.
It is funny to think that company that makes money by showing you ads based on information that it harvests by various mechanisms would let you browse the web without watching ads.
The current webRequest API allows extensions to intercept network requests in order to modify, redirect, or block them. It is frequently used by content blockers. Currently, with the webRequest permission, an extension can delay a request for an arbitrary amount of time, since Chrome needs to wait for the result from the extension in order to continue processing the request. The basic flow is that when a network request begins, Chrome sends information about it to interested extensions, and the extensions respond with which action to take. This begins in the browser process, involves a process hop to the extension's renderer process, where the extension then performs arbitrary (and potentially very slow) JavaScript, and returns the result back to the browser process. This can have a significant effect on every single network request, even those that are not modified, redirected, or blocked by the extension (since Chrome needs to dispatch the event to the extension to determine the result).
Google has noticed (as have I) that a typical chrome instance is significantly slowed down by things like adblock plus, because it turns out running every URL through a million regex's uses a massive amount of CPU and really slows down loading. As web pages get bigger and have more resources, it isn't going to scale.
This has been going on a long time, and there are totally ways to improve performance, but typically ad-blocker authors don't have a commercial incentive to make their software super performant, so as far as I know, none have even implemented basic performance features like prefix trees, bloom filters or hashed lookups.
I started using uMatrix full-time about a year ago. At first, I was shocked by how much traffic it would block - sometimes dozens of tracking domains. I didn't understand the sheer scale of the tracking industry.
Losing the full efficacy of uBlock and uMatrix is a deal-breaker - not just for Chrome, but many other Google services. That such a proposal is even being considered is stunning and causes me to reconsider Google's reputation.
[+] [-] dragonwriter|7 years ago|reply
I think the response is appropriate, energetic advocacy, but the HN headline is hyperbolic.
[+] [-] pleasecalllater|7 years ago|reply
I'm glad that I stopped using it.
[+] [-] metalliqaz|7 years ago|reply
[+] [-] happybuy|7 years ago|reply
In essence they are copying what Apple did with Safari and their content blocking APIs. In this model, content blockers provide the browser with a set of blocking rules and the browser executes them against pages during render & load. Ad blocking can occur and privacy of what the user is viewing is retained.
Sure it's more restrictive and yes will likely break existing adblockers, but it's probably a better model for the future.
There will be arguments that you "can't do what is necessary" to create effective adblockers. That's incorrect.... I've created such an adblocker [1] using the Safari methods and its efficient, effective and high performance – including loading some sites 2x faster.
[1] https://www.magiclasso.co/
[+] [-] lettergram|7 years ago|reply
It bothers me that iOS doesn’t support addons to Firefox mobile. But on Android you can even install ublock origin
[+] [-] cheez|7 years ago|reply
[+] [-] driverdan|7 years ago|reply
[+] [-] jaxn|7 years ago|reply
[+] [-] Chris_Chambers|7 years ago|reply
[deleted]
[+] [-] floatingatoll|7 years ago|reply
EDIT: The bank robber is Chrome.
[+] [-] mrawesome8|7 years ago|reply
[+] [-] swypych|7 years ago|reply
"In Manifest V3, we want activeTab-style host permissions to be the default, with a number of extra options. Instead of being granted access to all URLs on installation, extensions will be unable to request <all_urls>, and instead the user can choose to invoke the extension on certain websites, like they would with activeTab. Additional settings will be available to the user post-installation, to allow them to tweak behavior if they so desire." --- https://docs.google.com/document/d/1nPu6Wy4LWR66EFLeYInl3Nzz...
yup it looks bad.
[+] [-] foob|7 years ago|reply
[1] - https://github.com/intoli/remote-browser/
[+] [-] metalliqaz|7 years ago|reply
[+] [-] LeoPanthera|7 years ago|reply
- Is the change specifically to block ad blockers, or uBlock specifically? Or is it just a new extension API?
- Could ad blockers adapt to the new version to work again?
I am reminded of the new version of (Mac) Safari, which features a new extensions API. It took a while for them to appear but there are now good ad blocking extensions again, like AdGuard for Safari.
[+] [-] kevindqc|7 years ago|reply
But Google wants to remove the ability to cancel a request through the events, and they want to replace that with declarativeNetRequest[1]. If you look at the link, in the Rules section, it seems to be simple, kinda hardcoded (but configurable) filters.
You can also see there's a limit of only 30,000 rules[2], which is not enough for EasyList[3] (example used in the tracker), which seems to have ~74,000 rules.
This is not targeted to ad blockers specifically. It's a change that makes blocking requests less flexible. For example, uBlock and uMatrix rules can be overridden by more specific rules, something that declarativeNetRequest can't do.
1. https://developers.chrome.com/extensions/declarativeNetReque...
2. https://developers.chrome.com/extensions/declarativeNetReque...
3. https://easylist.to/
[+] [-] tivert|7 years ago|reply
1. Google is proposing to limit the API uBlock Origin uses, and replace it with a less capable one.
2. Google also plans to put artificial limits on the new API (30,000 rules or something), which will make it even more difficult to make an effective ad blocker. That's not even enough to implement current blocklists.
3. The new API is inflexible, so it will be difficult to impossible to create innovative ad blockers in the future.
[+] [-] O1111OOO|7 years ago|reply
ghacks does a great job of explaining this (saw it first here).
Paraphrasing the article: Basically, they are limiting filters (used by ad-blockers) to 30k. Lots of blocking lists use more than 30k.
This is part of (possible) removal of blocking options from the webRequest API and the (possible) move to declarativeNetRequest to handle blocking requests.
[+] [-] GraemeL|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] rasz|7 years ago|reply
[+] [-] aerovistae|7 years ago|reply
It's different for everyone, but for me it started with this gmail redesign that made the product so slow it's almost worthless to me. And worst of all is I feel like there isn't even a good competing service to switch to.
And now Chrome...
[+] [-] sixothree|7 years ago|reply
Then people started to realize Google only introduces products that collect data in a new way from its other products. If it can't survive that test then it doesn't exist. Ugh.
[+] [-] shamalinga|7 years ago|reply
They literally removed the don't be evil motto as the reason for their conduct.
People will say that they still have, but that's just a stupid line at the end. They used to have a whole preface dedicated to it and have the code of conduct based around it.
[+] [-] aaronscott|7 years ago|reply
[+] [-] metalliqaz|7 years ago|reply
[+] [-] kowdermeister|7 years ago|reply
[+] [-] antisthenes|7 years ago|reply
[+] [-] sstangl|7 years ago|reply
[+] [-] darkpuma|7 years ago|reply
Great.
[+] [-] jf|7 years ago|reply
[+] [-] PaulHoule|7 years ago|reply
If feel they have enough impunity to get away with that, then it is no surprise that they will try to put other ad blockers out of business too.
Other ad networks might be big enough to bring an antitrust lawsuit against Google (although they probably won't last long enough) but Ad Blocking is such a niche market that they couldn't possibly sue.
[+] [-] jchw|7 years ago|reply
I personally still use Firefox at home despite recent issues, but I honestly would prefer having both as an option, plus I always recommend uBlock Origin to everyone.
(Disclaimer: I work at Google but not on Chrome, opinions are mine and not my employer's.)
[+] [-] feanaro|7 years ago|reply
They are a behemoth ad-based corporation that is becoming a monopoly in many areas of computing. In yet more areas, they are becoming an effective monopoly through size: they may not be the only company offering a type of service, but they are the only one able to offer it at scale and/or with a certain level of sophistication, given their resources are orders of magnitude larger than almost any other company's.
All this taken into account, it's obvious how much is at stake for them. Why wouldn't they try crippling blockers? Their revenue depends on it and the only counter-incentive is that there may be a massive exodus of users to Firefox, while it still exists. Do it slowly enough, though...
[+] [-] londons_explore|7 years ago|reply
This is simply an engineer spotting a performance bottleneck in Chrome and posting a design to resolve it.
There is zero chance that Google's top brass told the engineer to deliberately cripple ublock.
[+] [-] xkapastel|7 years ago|reply
On a related note, why doesn't Chrome for Android have extensions? I get the sense it's because it was more strategic to ban extensions entirely than to allow ad blocking on mobile.
[+] [-] deprave|7 years ago|reply
[+] [-] WrtCdEvrydy|7 years ago|reply
I think we're at Stage 3.
[+] [-] 0xmohit|7 years ago|reply
Interesting changes to Chrome seem to have become more often. A recent one was the forced login policy. https://blog.cryptographyengineering.com/2018/09/23/why-im-l...
[+] [-] londons_explore|7 years ago|reply
The current webRequest API allows extensions to intercept network requests in order to modify, redirect, or block them. It is frequently used by content blockers. Currently, with the webRequest permission, an extension can delay a request for an arbitrary amount of time, since Chrome needs to wait for the result from the extension in order to continue processing the request. The basic flow is that when a network request begins, Chrome sends information about it to interested extensions, and the extensions respond with which action to take. This begins in the browser process, involves a process hop to the extension's renderer process, where the extension then performs arbitrary (and potentially very slow) JavaScript, and returns the result back to the browser process. This can have a significant effect on every single network request, even those that are not modified, redirected, or blocked by the extension (since Chrome needs to dispatch the event to the extension to determine the result).
Google has noticed (as have I) that a typical chrome instance is significantly slowed down by things like adblock plus, because it turns out running every URL through a million regex's uses a massive amount of CPU and really slows down loading. As web pages get bigger and have more resources, it isn't going to scale.
This has been going on a long time, and there are totally ways to improve performance, but typically ad-blocker authors don't have a commercial incentive to make their software super performant, so as far as I know, none have even implemented basic performance features like prefix trees, bloom filters or hashed lookups.
[+] [-] coolspot|7 years ago|reply
[1] - https://opensource.com/article/17/9/intro-ebpf
[+] [-] kabes|7 years ago|reply
[+] [-] Zarath|7 years ago|reply
[+] [-] abtinf|7 years ago|reply
Losing the full efficacy of uBlock and uMatrix is a deal-breaker - not just for Chrome, but many other Google services. That such a proposal is even being considered is stunning and causes me to reconsider Google's reputation.