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.
Got it.
NO, your product is not a good replacement. You do not have custom rules, you can not block annoying elements, no it is not faster than Ublock and no, it is not even close to the feature set of Umatrix. And you can not do these things, because your product basically ships an ad-blocking list, and is not a fully featured ad blocker that gives control to the user over what to block.
You have just added white lists of websites. As Beta. For Pro subscribers. That doesn't even remotely compare to the permission feature set - in the hand of the USER - of UMatrix or Ublock. Your Adblocker would not even be functional for someone visiting non-English pages.
YOUR extension will be caught by anti-adblocking scripts all the time.
Please stop. Every time this comes up you post the same thing. Stop deceiving people.
You CAN NOT build an equivalent product with the Apple API, and you have certainly not done. No Matter how often you claim this!
By the way, Ublock, a product vastly superior to yours, is free.
> In Manifest V3, we will strive to limit the blocking version
> of webRequest, potentially removing blocking options from most
> events (**making them observational only**)This change is clearly targeting aggressive ad-blockers that are too dangerous, too capable to circumvent via anti-adblocking technologies.
And Safari's content blocking is a piece of shit that's too limited and that's easily circumvented. It's in fact the weakest adblocking capability around and doesn't pose a threat to publishers.
Running an extension is running code I trust (mostly). Visiting a website is running code I (inherently) don't trust. Many websites even have no idea which code they run on my machine (advertizing networks).
If you are planning on providing the functionality in the future please refrain from deprecating the existing mechanism until your replacement is fully complete.
Early access may fly on Steam but in the real world your careless management of the refactoring process is wasting the time of your peers.
A good example why "secure system" is, in a longer run, a system with low usability, and little control by the user/owner.
Right now we have ability to block URLs according to any rules, without being limited to whatever the browser author conceived. Perhaps we want to block some URLs based on context, or on content of previous communication, or whatever. Or perhaps pseudo-randomly, to emulate certain problems with the network.
Switching to "more secure" approach limits us to "one true way", and precludes any smart hack we may come up in the future.
It doesn't help that the change feels like attempt to squeeze out grassroots adblockers, and force people to, at best, use the ABP, which allows ad publishers to buy their way around blocks, and onto users' screens.
If uBlock becomes ineffective, I fully expect ABP to be even more aggressive with monetizing access to users' screens.
How on Earth does "Comorbidities Associated with Plaque Psoriasis | Dermatology Times" on page 10 have a higher PageRank and relevance for the search query "uBlock Origin" than https://addons.mozilla.org/en-US/firefox/addon/ublock-origin... ?
Power users won't stand for this sort of thing and will switch to Firefox. Firefox, in turn, will gain greater development mindshare.
In aggregate, these privacy and "ads above all" stories will continue to taint the Google brand. Many of my layperson friends are starting to worry about their privacy when using Google products--it's a good thing!
I recall this is what I had to do for Safari since there wasn’t a supported extension for the new browser yet.
This would lessen our dependency on a browser for ad blocking in this ongoing browser war.
Great.
there is no regulatory body that is able or willing to step in
We've already seen far greater market share from a browser. That browser lost it's market share when it stopped serving consumers. It lost it so thoroughly that decades and billions later it still can't recoup it.
Why would you want the government to hurt Firefox and the other competitors who would be happy to compete with Google on this front?
On basis of what exactly? What is google doing wrong?
I am curious to hear. Don't downvote me.
We can only hope.
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...
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.
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 think the response is appropriate, energetic advocacy, but the HN headline is hyperbolic.
The title isn't at all hyperbolic. You don't deprecate such important functionality without laying out a full plan for replacement.
Unless there is no such plan and in reality you want to screw uBlock Origin, which I might say is the most aggressive ad blocker available, and isn't owned by a company in bed with the ads industry, like AdBlock Plus.
The fact that the plan ends with extensions still able to see all web requests, record all web requests, forward a log of all web requests to any arbitrary endpoint, etc...means the "privacy" angle is pure bullshit. I suppose the "performance" angle is somewhat true, but the net performance gain of NOT downloading all the ads makes up for any performance loss of processing/filtering requests. Sites with ads are faster when you load an adblocker.
The only thing being taken away is the ability to dynamically observe a web request and cancel it. Who uses that functionality outside of ad-blockers? Not many. There's no hyperbole in the headline.
[1] https://developers.chrome.com/extensions/declarativeNetReque...
The design document says "potentially removing blocking options from most events". There is one mention that the blocking ability of webRequest.onAuthRequired may still be required.
From this I deduce that the plan is to remove the blocking ability of the three remaining listeners with blocking ability
uBlock Origin uses two of these remaining blocking listeners, uMatrix uses three of them.
This is because Chrome extensions can use the 'debugger' API to send remote debugging protocol commands to a page, to intercept and filter / block all requests.
There is no need to use the provided Chrome extension APIs for blocking. Google can remove all of them, I think, without effect.
This is because there are multiple ways to do the same thing. Authors/engineers complaining that now they are impeded, are in fact mistaken.
Disclosure: I know this because I have actually re-implemented the blocking from AdBlock Fast using CRDP Network domain.
I'm glad that I stopped using it.
Many web commentators continually sound the alarm on Google's increasing leverage and control over a variety of "components" or "intrastructure" essential to the www.
But controlling the browser is, I think, the ultimate control over the web as users know it. Browsers seem to fall outside the purview of www standards. Are there RFCs that tell people what browsers must or should do? More likely, there are standards that focus on servers and seek to accomodate whatever browsers are doing at the time.
The browser can override anything. It can easily modify user intent in subtle, "hidden" ways. It can rewrite "default behaviour" overnight.
To give an example, users probably think little of something like the feature known as "Omnibox", if they even know what that is, but this sort of browser "feature" is of enormous value to a company trying to gather information on what users are looking for.
Imagine the number of DNS queries this bypasses, redirecting what is typed by the user to a default search engine, conveniently preset to point to a Google server.
https://en.wikipedia.org/wiki/Usage_share_of_web_browsers#/m...
IE was stagnating, slow, and extremely vulnerable to malicious behaviors. The net result was that the web became a very hostile place, while Microsoft was pitching various "post web" strategies like WPF. Google had been a big financial supporter of Firefox but not to a degree where they could direct the project or push their own agenda. At the time many viewed Firefox as slow and bloated.
So Google made their own thing, and it worked admirably and we might be in a very different world if they didn't. They dramatically improved the state of the art for JavaScript, added intrinsic hostile activity and site blocking, started dramatically accelerating the adoption of technology improvements (by implementing very early proposals, often to much consternation), etc.
The web was less dangerous. Google's cash cow was protected because there was less of a draw to go to alternative platforms.
That, I think, was their primary intention and it was aligned interests with users. Everyone is happy with the web.
And honestly I do think this ad blocking thing is a bit of "fake news" (e.g. it is being grossly misreported). Google is proposing a solution that offers more privacy from the extension, and it seems very similar to what Safari has done (and which is very widely viewed as a great design).
Chrome was originally based on WebKit and many other open source libraries, and some parts still are. The only major initial investment was V8.
It bothers me that iOS doesn’t support addons to Firefox mobile. But on Android you can even install ublock origin
- 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.
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...
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.
EDIT: The bank robber is Chrome.
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.
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.
"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.
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.)
then they'd be able to sell their browser as having ad blocking when chrome doesn't
the market would take care of the rest
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...
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.
I think we're at Stage 3.
Even in the most skeptical reading of the situation, Google never "embraced" adblockers, they allowed them. You'll note there's no extensions on Chrome for Android for example.
Sounds like Google devs to me!
You see? Power corrupts.
Suggested title: Chromium Extension Manifest v3 change would break uMatrix/uBlock
Mods?
The essential quote from the linked comment is this: "If this ...[change to chromium is implemented]... [it] essentially means that two content blockers I have maintained for years, uBlock Origin ("uBO") and uMatrix, can no longer exist."
"can no longer exist" is much closer to "disable" than "break".
For the few extra ad clicks they'll gain, it's just not worth the upset.
So in light of that, I see no reason to not assume malice in this case too.
From what I can gather from the chrome.webRequest and chrome.declarativeNetRequest documentation, it looks like this change would make it difficult to have long lists of blocked hosts, or perhaps to update such lists automatically. Obviously there is a conflict of interest here for Google, but it looks like there are at least a few non-bogus justifications for the proposed change.
See also (especially the section "Comparison with the webRequest API): https://developers.chrome.com/extensions/declarativeNetReque...
* There's a limit of 30k blocked rules, which isn't enough to fully block every ad (for example, EasyList alone is 87k filters right now).
* The declarativeNetRequest API only supports a limited set of filter options. Currently, uBlock supports a bunch of additional options that give you more fine-grained control over what is blocked [0]; most of that wouldn't be possible in the new API.
* AFAICT, the ruleset can't be updated dynamically, which would prevent uBlock's dynamic filtering [1] mode from working.
Google's argument is that doing this improves performance (because it doesn't require communicating with the extension), and that it improves privacy. The privacy issue does have some merit - uBlock's author seems to be trustworthy, but other extensions might not be - but the performance argument in particular seems really shaky. uBlock's benchmarks [2] show that it takes around 0.1ms to decide whether to allow a network request. The only way it could noticeably impact performance is if the overhead of communicating with the extension process is really high, and that sounds like something Google should fix rather than eliminating it.
[0] https://github.com/gorhill/uBlock/wiki/Static-filter-syntax [1] https://github.com/gorhill/uBlock/wiki/Dynamic-filtering [2] https://github.com/gorhill/uBlock/wiki/uBlock-vs.-ABP:-effic...
now I live between the two browsers. For the most, there is no real difference and for both browsers, holes can be plugged with plugins. ( One nice thing I like out of the box for FF is that it supports column selection which makes my life easier on some web pages I have to use regularly )
I like the web development tools on firefox, and usually use them over chromes
The only few things I've really had an issue with is a particular wiki page in my works confluence system that seems to go incredibly slowly on firefox and I end up using chrome to edit that page. The other is sometimes firefox doesn't open a new tab in a new tab if the tab bar has a lot of tabs if I'm using the UI ( I use vimium on both chrome and FF and it can open tabs no matter what )
Other than that, I have this very subjective "feeling" that chrome feels just a wee bit nicer than FF.
Installing Firefox on mobile today. Time to prep.
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.
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...
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.
epic burn
> the blocking of media element which are larger than a set size, the disabling of JavaScript execution through the injection of CSP directives, the removal of outgoing Cookie headers, etc.
Seems like pretty fundamental stuff for any user-side content filtering, especially for the use of bandwidth and privacy considerations, ad-blocking aside.
So glad I’m not a google user. How much more does google have to do before people stop seeing them as the freedom option?
Companies can change their browsers anytime and for whatever reasons they want. As far as I can tell, users have little control over the organizations/companies that write browsers, not to mention that the most popular browsers are written by companies that benefit from sale of the online ads. This make the ad-blocking browser extension brittle.
I also find it peculiar that the preferred approach to ad blocking has been blacklisting rather than whitelisting. In other words, users prefer to let a third party pick a list of servers to block. Everything else is allowed by default.
Besides issues of delegation and having to trust a third a party, this of course is a very large, constantly growing list that includes many, many servers most users will never, ever encounter in their entire lifetime online. Though it may be unnoticeable for now, an enormous block list is inefficient.
The alternative, which I have found easier to manage, is for users to determine what servers they need to access, "whitelist" them (e.g. by placing them in localhost authoritative DNS or /etc/hosts), and then block everything else by default. This is similar to a firewall ruleset.
The number of servers any user will use in their lifetime is relatively small compared to the total number of ad server addresses in existence now or in the future. It is manageable.
If you are a non-technical Chrome user, and you have no idea of what servers you are actually using repeatedly day-to-day, there is a built-in feature that can help you make your own "whitelist".
Here's the URL:
.png){kind=link}
chrome://site-engagementhttps://www.reddit.com/r/ublock/comments/32mos6/ublock_vs_ub...
* Pi-hole®: A black hole for Internet advertisements – curl -sSL https://install.pi-hole.net | bash || https://pi-hole.net/
* GitHub - StevenBlack/hosts: Extending and consolidating hosts files from several well-curated sources like adaway.org, mvps.org, malwaredomainlist.com, someonewhocares.org, and potentially others. You can optionally invoke extensions to block additional sites by category. || https://github.com/StevenBlack/hosts
Someone will make money selling an ad blocker device that's just a configured Raspberry Pi with a consumer-friendly way to install it on a home network.
[1]: https://bugs.chromium.org/p/chromium/issues/list?q=label:Hot...
This is also incredibly important.
It's my HTML, don't restrict me. Let me mangle the web pages I request.
curl -sSL https://install.pi-hole.net | bash
Was no one but me outraged about them turning the 'stop autoplay' of video feature off within Chrome on desktop? This happened in the last year or two - I don't remember since I switched to Firefox.
Chrome I only use for business / G-Suite purposes and for dumbo sites that only work in Chrome. Admittedly I'll use IE before I use Chrome.
It would actually go hand in hand with "hide but load element"
https://robert.ocallahan.org/2014/08/choose-firefox-now-or-l...
It's actually Google wants to rule by blocking other platforms that provide Ads.
Oh well, they'll just give me a reason to accelerate my full migration to Safari and Firefox and to only touch Chrome when testing a website.
The GDPR situation and this week's 'fine' for Google certainly suggests that the current model of surreptitiously harvesting outrageous amounts of data from unsuspecting service-users is untenable (as well it should be), so I'll be fascinated to observe the next stages of the data collection vs privacy skirmish.
[0] - https://marketingland.com/survey-shows-us-ad-blocking-usage-...
> the 30,000 limit is not sufficient to enforce the famous EasyList alone).
Chrome extensions have access to the 'debugger' API.
Debugger API provides access to remote debugging protocol.
Remote debugging protocol provides commands to intercept, filter and block requests.
Please see: https://chromedevtools.github.io/devtools-protocol/ and specifically the "Network" domain.
Is there any rationale why?
The attempt to force users into a system they don't want when there are other options available results in a loss of users.
I will focus on Firefox for compatibility, if it works on chrome that's great but I will consider it ie6, I don't care about crippled browsers.
Depending on the project and leeway I might even block it outright. I did that with ie6 on one system.
Now Microsoft has a choice for Edge:
A. Fork here and pay the maintenance price and extension compat issues, with potentially unlimited downside of technical debt in reconciling the two.
B. Adopt these changes and kill ad blocking in Edge, preventing them from differentiating themselves from Chrome and reinforcing Google's position as an advertising giant.
Both are bad. What would have been less bad is if Microsoft switched Edge to say, Gecko, or maintained EdgeHTML and continued to support a multi-platform, multi-implementation web.