I'm really happy that Gorhill has listened to feedback on the branding and explanation of this, and added back in the ability to "opt in" to extended permissions on individual sites. Thank you for your work, and I'm sorry if my comments in the preview HN thread came off as overly hostile, because given the original comments you made about MV3, I couldn't imagine this sort of outcome. I hope that you or someone else still works to release an MV3-compatible "Full site permissions" version of uBlock as well, since I think there are a lot of potential options for improvement by using declarativeNetRequestFeedback, and it's certainly more convenient to not have to opt-in. And I'm still worried that without an MV3-compatible version of full uBlock Origin, users are still going to assume that "MV3 means that ad blockers are broken".
> I'm still worried that without an MV3-compatible version of full uBlock Origin, users are still going to assume that "MV3 means that ad blockers are broken".
They currently are when compared to their MV2 counterpart.
The AdGuard MV3 version which came out earlier this month[1] shows this. Though it does its best to deal with the technical challenges which comes with MV3, the end result is poor efficiency- and reliability-wise compared to its MV2 counterpart.
This is easy for anyone to see: open the browser's own Task Manager (Esc-Shift works) and notice how the service worker associated to AdGuard MV3 is regularly (every few seconds) evicted and respawn.
When it re-spawns, the process's CPU and memory usage peaks, with memory usage shooting up to between 100-200MB. This happens repeatedly every few seconds or whenever you navigate to a new webpage.
CPU/memory efficiency has always been a primary feature of uBO, and I can't release an MV3 version suffering such efficiency setback (this on top of matching algorithm not being fully compatible with that of uBO).
However I am willing to work on an MV3 version which does not suffer no CPU/memory efficiency issues, hence uBO Lite, which takes advantage of new possibilities in MV3 to be fully declarative, at the cost of sacrificing some capabilities.
I think most people would agree that it's important to add the ability to evict unused extension code from memory, which is what the fundamental move to a stateless ServiceWorker architecture is designed to support (since the previous stateful architecture required all extension background pages to be loaded regardless of whether they were actually doing anything). Being able to do that for the vast majority of extensions that that helps, without requiring extension authors to "opt in" to that change, is a very important goal.
But I agree that the heuristics for when to evict certain extensions (especially those with broad all-page access permissions) definitely remains tricky, and I hear you that Chrome's are currently too severe for this type of extension to be practical. I don't think that's a fundamental problem with the service worker model though—it seems easy to add a heuristic to cover this case like "If the extension has a async network request event registered and there's an active tab open that that extension has permissions to view, be very cautious in evicting it". In that case Chrome could still want to evict the service worker i.e. if the tab/browser is in the background and paused[1], so that it wouldn't be handling event loop / network requests anyway.
"And I'm still worried that without an MV3-compatible version of full uBlock Origin, users are still going to assume that "MV3 means that ad blockers are broken"
I mean, they are hobbled. If you think of it like a malware scanner, it's the equivalent of taking away all heuristics and relying solely on big lists of payload checksums or "bad words".
But even worse than that, because you have a limit on how big that list can be.
Otoh, with full permissions it can still do things like hide ads that aren't blocked by the declaritive rules. But, to continue the analogy, that's like killing a process after it's doing malicious stuff instead of preventing it from running in the first place.
I have 3 extensions and each one has multiple feature-breaking changes that will take hundreds of hours to implement less than ideal work arounds. I guess I'll focus on SnipCSS (https://www.snipcss.com) because that's the only one I have paying customers.
For people who do manage the upgrade, at least we can look forward to less competition in the Chrome Web Store?
Took us about a quarter heads down to do the conversion which involved quite a bit of rewriting. We had been prepping and planning for the work pretty much since they first teased MV3 in 2018.
Now we are figuring out the right way to flip the switch. You get stuck in the long review queue every time you flip manifest versions, cuz your permissions list has likely changed.
Google's rollout has been the absolute worst; but hey, as you say, everyone who can't eat a bowl of shit and keep on smiling will simply disappear from the competitive landscape.
Yeah, I find it funny that most of the conversations were always focused on ad-blockers, but honestly it seems like for 99% of people who don't use the power user features, it'll be a no-op on that end. It's other extensions that are much more in trouble.
Partly cloud with a chance of thunder. I have 2 extensions and we've gotten one in sight of the finish line (after months of work), and the other appears to be dependent upon some as-yet unfixed third-party code.
We are really hoping Google doesn't force this through on their originally-announced timeline. This is the third massive Google-induced change that we've stomached in the last couple years. We spend more time keeping our head above water than we do adding new features...
I guess the biggest issue I have with V3 is I don't really "get it".
The idea was initially that extensions have too many privileges and that malware can leverage those privileges for harm. I'd love data here! This is such a good area to share information on, as someone in security I'd really value that.
I'd like to see case studies on malware, or even broad things like "malware uses these permissions X% of the time".
But back to the point, assuming that this is true, how does V3 help? Specifically, what can malware not do with V3 that it could do before? Given the data, how will this impact the threat landscape?
I can think of some obvious things, like that you can't have dynamic scripts - cool, makes sense, I bet malware loves that and removing it seems like it'd be a huge win.
But WebRequests? I'm sure malware was using it, I guess, but what in V3 makes the malware use case for it harder? It seems like we're getting something that can be used maliciously just like before, but it's somewhat weaker in ways that malware won't care about? Again, data here would be great. I'd love to see "X% of malware used it this way, we removed that way".
Communication has seemingly been pretty bad around the motivations, which has led to a lot of people being pretty upset and confused about the changes.
Google, please share the data and reasoning!
edit: With regards to uBlock Lite specifically, I'm looking forward to seeing it evolve. I do like the idea of having a permissionless blocker that works decently and can then have the opt-in approach. I don't honestly consider it a massive security win though.
The reason you don't get it is that taking away the functional part of onBeforeRequest() doesn't really help with privacy. Because extensions can, for example, still inject arbitrary javascript if those permissions are in the manifest.
What it really does is ensure that adblockers can't do heuristics, and instead have to rely solely on semi-static lists of urls. That's a nice outcome if you're a company that makes most of their money from ads.
There's not really a nice way to say that aloud though, so trying to make it sound it's a way of ensuring extensions honor privacy and security sounds better.
Yeah, I said this in another comment, I don't really believe that to be the case. I'm not saying that a conflict of interest doesn't exist, I just don't believe that this move is part of an overall plan to have Google start bypassing adblockers.
It's not really unprecedented for them to offer up (often attractive and plausible) trojan horse reasons for why they do things that aren't the real reason. AMP, to me, is one good example. There are others.
I don't know what else they would really gain, or why else onBeforeRequest() was the most important thing to take away when extensions have so many other ways they can do harm.
Perhaps another way to look at it is not Google actively defeating adblockers, but giving a gift to their customers that pay for ads...making it easier for those customers to deal with the rising tide of adblockers, paywall end-arounds, etc.
> Perhaps another way to look at it is not Google actively defeating adblockers, but giving a gift to their customers that pay for ads...making it easier for those customers to deal with the rising tide of adblockers, paywall end-arounds, etc.
This assumes that Google's ads will start to bypass the V3 adblockers. V3 in and of itself does nothing, Google's ads are still blocked by the updated adblockers.
> I don't know what else they would really gain
Well that's what I'm asking haha I'd like to hear from them on this. Even if some people at Google are nefariously implementing V3 for some future plan to bypass adblockers, surely some people at Google believe that there are benefits to the work.
"Google's ads" is a broad category. I imagine there's many already defeating ad blockers. They wouldn't start with adsense or their ads on google search.
Ah, there's lots. What used to be "DoubleClick" still exists under a different name, a sort of more publisher controlled private-ish instance of Adsense/Adwords. Then ad-like things..embedded google shopping results, local search, google flights, travel/hotel widgets, etc. Ads inside products like Maps, etc.
Most bad extensions I've come across when trying to vet what I'm installing fall into two categories: those that are passively malicious: inserting redirections to affiliate links (or sometimes randomly spawning ad), and those that are "actively malicious" by scanning for browsing history and then sending that over to be sold off.
I guess the general idea of manifest v3 is to limit the page/extension boundary to being declarative in nature. I haven't looked into this too much to know how restrictive it is in practice, but at least one such thing is that webRequest is neutered so extensions can't run their own logic for request pre/post processing (where they might try to obfuscate/disguise the target redirect), instead they have to declare the list of redirect targets upfront, where presumably they can be scanned by trivial static analysis.
While I think there is indeed a problem of malicious extensions, I don't believe that manifest v3 is the solution. Switch to a more granular but still non-declarative permission model might be useful to gain a stronger signal on malicious extensions, or maybe requiring web store extensions to be declarative but allowing "power-users" to still manually install non-declarative extensions.
I don't think so. That gets repeated a lot but I think people are just unaware of the fact that Google ads are particularly uninvasive and easy to block. If ad blockers are less capable that will only help Google's competitors, not Google. Another comment the other day confirmed that Google's ads continue to be blockable with V3.
This could change - AdSense ads could start implementing bypasses. I think that's unlikely because Google would likely end up with a few lawsuits, questions about browser monopolies, and a congressional hearing. Certainly the EU would be on their asses. One day that may change, but I don't see this move as being part of any specific plans to improve AdSense revenue.
> That gets repeated a lot but I think people are just unaware of the fact that Google ads are particularly uninvasive and easy to block.
Not true in my experience, i have encountered adsensw that pretty invasive to my 2012 laptop's cpu core i3 gen3 (i know its pretty old), i dont think any ads should be that way.
You are right about requiring more case studies. In the same context, MV3 extensions are being moved away from persistent background pages to ephemeral service workers. There's a thread and several very popular crbugs for how the web-based service workers don't work well for extensions (https://github.com/w3c/webextensions/issues/72). Given all this, the Chrome team continues with the change citing increased performance when using service workers. However, even when extension developers continue to come out with claims of decreasing performance, the Chrome team - as in the malware case - has not provided any case studies on how it is so sure about the increased performance (or efficiency, memory use, etc.) of SWs.
I'm really really really hoping that the non-crippled version, which works in Firefox, doesn't die the way uMatrix did (loved it, still miss it). That said, huge thanks to gorhill and all the others working on this project!
Note: uMatrix is not dead, it's just no longer updated. It's still available from the Chrome web store and Firefox add-ons sites. I am using it in Firefox right now, it still works as well as it always has.
Firefox still seems to be quite bloated, although there has been improvements in performance. We need more competition vs a company that’s entirely reliant on Google’s $ to stay in business
> Isn't the biggest problem with MV3 the 5000 rule limit?
Not really, the bigger problems come from the removal without alternative of a number of useful primitives that uBlock Origin used for blocking. See https://github.com/uBlockOrigin/uBlock-issues/issues/338 for a detailed accounting of the changes and their impacts.
Unbounded lists rarely seems like a thoughtful way to start out.
But there are probably some DX and UX improvements over unbounded lists. e.g. recompilation takes time, so you set up developers for better UX when their dynamic lists are shorter and separate from their static lists, and they can compile multiple lists at once. (A 50k rule list took seconds on my old Macbook Air). Also encourages breaking lists into logical sublists which is better UX (e.g. regional lists)
Also might discourage append-only accumulation where there’s no real incentive to prune the list (i.e. see EasyList). Some limit can help here.
Kind of like deciding on a queue size vs unbounded: makes sense to set a limit, see who hits it, and cross that bridge as needed. In Apples case, they 3x’d the limit after a real world product made a real world case.
Just some thoughts having built my own Safari content blocker.
If no one were building an adblocker for Chrome I'd just build it myself. I'm sure I'd do a worse job than the people doing it today but it'd be better than nothing.
Also, there are other adblockers on Chrome. They just aren’t as good and are sketchier. By pulling the extension you just enrich worse actors at the expense of innocent users.
It just won't work that well. Recently in the past few months I've been noticing more and more ads with safari style content blockers, while ublock style continue to work fine. I fear this style of 'adblock' will have similar issues.
Brave is a Chromium clone with their own built-in adblocker. Orion is a Safari / Webkit clone re-engineered to work with Ublock Origin (which is currently the best ad blocker). So on a mac or ios, Orion will be slightly better.
"Side note about the experimental uBO Minus MV3 extension: I did not pick the Minus part out of spite, it's to make clear that this is not uBO proper and I want to be sure there is no expectation that this will be the case. I picked Minus for the same reason that the Plus in Adblock Plus was to highlight that this was an improvement over the previous Adblock version.
Now the fact that uBO Minus does not require broad read/modify data on all websites can be seen as an improvement over uBO proper by many people who are uncomfortable with granting such broad permissions to an extension. In that case, if you have a better qualifier than Minus, I welcome suggestions."
You just need build infrastructure. As far as I know, you need XCode to generate the "app" that contains the extension (all extensions need to be provided by an "app" even if it doesn't have any logic in it), then code sign and upload to the App Store. There are open, third-party implementations of the code signing tools so it can be done without a Mac but it just requires effort.
I did this earlier today. The background stuff (I forget the name of what crashed at present) crashes on a vanilla conversion. It did block some ads, but wasn't full-featured.
It'll create an xcode project and you can run the mac app from there. Safari will need the "Allow Unsigned Extensions" from the Develop menu set before it'll show up in the prefs page. No idea how it all works if you want it on iOS.
i love the idea of uBlock Origin Lite. i am willing to trade some efficiency if i don't have to give it the "has access to everything i do in the browser" permissions.
CNAME cloaking is one of the more significant differences. It's typically used for tracking (and is becoming increasingly common), but also works for advertising. Instead of linking images/scripts/etc. to ads.advertisingcompany.com you can simply set up a CNAME under your TLD that points to the advertising company. Now the domain no longer appears in the blocklist, so all the requests (uploading tracking data, or downloading adverts/scripts) work just fine.
With MV2, uBlock is able to inspect the DNS record while it is vetting the request, thwarting this workaround.
That limitation has nothing to do with MV3. Adguard does not suffer from this problem. Making it opt-in is a specific design consideration that gorhill took with this version of uBlock to reduce its permission scope.
I wish people were not so quick to share misinformation like this.
The amount of misinformation in these comments is absolutely wild.
For some reason people are just itching to spread FUD about this topic and Google in general. I don't understand where it comes from or why it happens but it's really annoying.
From the blog post on how adguard built their v3 extension the ads themselves are blocked but aren't removed from the page if the cosmetic filters aren't run
> Without the preset lists of filters, this extension is nothing. So if ever you really do want to contribute something, think about the people working hard to maintain the filter lists you are using, which were made available to use by all for free.
I know it is gorhill that wrote that, but I completely disagree that uBO is nothing without the filter lists. I use it the way I used to use uMatrix (rip) to default deny bits and bobs across the web, unblocking as necessary. It’s everything that NoScript should be!
Note that you cannot manage your recurring IA donation for any reason without manually contacting them. For this reason I have not moved my IA donation to my newer credit card nor increased my donation since it was set up. I do not know if this is a dark pattern or just an oddly limited system, but the only officially recommended solution is to use PayPal. So I'd recommend that. https://help.archive.org/help/how-do-i-update-or-change-my-r...
I've worked on several large recurring payments platforms. It isn't rocket science, but let me tell you it is generally a pain in the ass to to manage recurring payments - in most of the systems I've worked in its easiest to just cancel and start a new one. The schemas are generally awful and make a lot of assumptions in the worst of ways. I wouldn't be shocked if the IA just finds it easier to manage manually than put in the large amounts of money for a refactor. One org I was with it took a Staff engineer nearly two years to rework the very odd weekly recurring feature to make it something that would be later made into something you could edit (of note, it was entirely separate in logic than the monthly recurring...)
I've worked on several platforms with recurring billing, including a marketplace prior to Stripe Connect existing, so I get that it can be pretty challenging.
That said:
- IA doesn't even offer cancelling. That's... not a particularly technically challenging feature. I have a strong feeling that they in fact have a cancel button somewhere in their backend anyways.
- While some of this can be annoying, it's kinda table stakes these days. If you can't handle basic subscription functionality, god help you for things like 3-D Secure.
Could not find what happened, but if it's the forum known for enabling harassment, and if IA did something bad to this site owner, then I find no problem. Those kind of people deserve what they do to others.
A person who shops on amazon can shop using smile.amazon.com and have a percentage of their purchase payments go towards charities or other organizations. The Internet Archive is one of them.
There are fast-growing sections of their budget slated for political-like causes, not technical ones that keep the website online and accessible. They call it the Thriving Movement and it's largely based around DEI-type initiatives.
"The Thriving Movement budget has increased from $14.3 million last fiscal year to $36.7 million in this budget which represents an increase of $22.4 million or 157%. It has also grown from being 13.2% of the Foundation’s overall budget to 24.5%."
Not only is more money going into it, a larger share of their budget is being allocated to it, so a larger share of each donation goes into DEI initiatives. If you're the kind of person that does not think this is a valuable investment of your money, you might not be inclined to donate anymore (or to donate less than before).
I personally believe a 24.5% share of the budget for what are largely DEI initiatives is not something I'd prefer to support with increasing donations, so I have scaled back my donations to them (as well as Mozilla/Firefox for the same reasons). I am sure many people agree with DEI initiatives and donate more. That's fine. We all vote with our wallet.
As someone who never heard of "Thriving Movement" nor "DEI-type initiaives" before, it seems to be around making the workplace (Wikimedia Foundation) more diverse, equal and inclusive. At a glance, those seems like good things to introduce to global organizations (especially foundations) that is supposed to be represented by the whole world. But I can agree that it seems like a large part of the budget, for being what it is.
But if I understand what you're saying correctly, you're saying it's a negative for them to put such a focus on it?
I'm not morally judging them. If they think it's a good idea, good for them.
I'm just not interested in funding those initiatives at that percentage of budget and would rather send the money to other essential Internet companies who have lesser investments in those ideas. I still give some to Wikimedia, just not as much.
Thank you for explaining your position! Which internet companies do you currently donate to that also publishes exactly what they spend their money on, so you can make sure they don't spend similar amount on similar initiatives?
In my experience, the Wikimedia Foundation seems to be the one who is most transparent about where funds go, while organizations like Internet Archive doesn't make a lot of data public, at least via their own website.
The road to Hell is paved with good intentions. If I were a cynical man I might speculate that it's not because things that look good don't get scrutinised as much but that anyone wanting less scrutiny might try painting their aims as "good" and those who object as therefore "bad". But I digress. Wikimedia's mission is[1]:
> to empower and engage people around the world to collect and develop educational content under a free license or in the public domain, and to disseminate it effectively and globally
What does DEI at their workplace have to do with that?
If you've ever seen how topics are treated in a Wikipedia discussion thread you'd feel like the whole website has zero credibility. There's a reason academics don't let you use it.
The reason is that it is not a direct source of course because the authors cannot be validated. Never met a college professor that said don’t use Wikipedia (if anything it was encouraged) as long as you’re pulling from the citations. I had plenty of high school teachers talk about how awful it is though and I think it was because they just didn’t understand it
I'll take this a step further to say that my graduate algorithms professor assigned Wikipedia articles as reading. The parent blanket statements are just that: overgeneralizations.
I had a similar experience. My cryptography professor regularly linked to Wikipedia articles in his assignments as the reading to go with the assignment. Honestly, the last time I had a teacher really say something against using Wikipedia was in high school.
My undergrad physics professors didn't exactly assign wikipedia articles, but they did tell us that some articles were useful resources for understanding certain topics. In my experience, the more technical a topic, the more likely the wikipedia article is to be reliable. Probably because there isn't much incentive for someone who isn't an expert to edit it.
Haha. This reminds me of a Redditor's story. Despite having no money to afford professional hardware, he still managed to take good astronomy photos using his phone. In one of his posts, his photos impressed a "kind stranger" so much that they gifted him one of the most expensive Reddit awards, whose value can buy him a third of his desired gear.
(For context: Reddit awards don't give the recipient anything except the ability to browse Reddit without any banner ads, and access to a special forum. If you make a big Reddit donation to someone, you're actually donating to Conde Nast, Spez, etc)
pretty sure the most expensive reddit award is worth $120, which isn't a down-payment on an equatorial drive. It might pay for 1/3 of an IR conversion on an existing DSLR camera, maybe.
professional astronomy photos is an activity where the low end starts very expensive. Basic setups are in the thousands of dollars.
"Lite" is such a bad name, it's often a positive signifier that describes low resource usage/costs. It should have a more negative name, like uBlock Origin Reduced.
The problem is that something pejorative on the surface is only meaningful to an end-user that is intimately familiar with the limitations of ManifestV3.
If you titled an adblocker "uBlock Crippled Edition", you might be protesting Google, but the unfamiliar end-user is just going to see it and think, "Well I certainly don't want a crippled adblocker! Let me just grab one of these numerous others from the appstore that claims it's 100% effective."
> The problem is that something pejorative on the surface is only meaningful to an end-user that is intimately familiar with the limitations of ManifestV3.
You don't need to be "intimately familiar" with the limitations of ManifestV3, a casual understanding, from perhaps an explanatory note in the description of the extension, is sufficient to understand such a name.
Your average user has no interest in Google politics, nor would they bother to read through the explanation. Most people install an adblock to block ads. The politics of internet browsers and privacy only matter to power users.
>... it's often a positive signifier that describes low resource usage/costs
Third sentence:
>This means that uBOL itself does not consume CPU/memory resources while content blocking is ongoing -- uBOL's service worker process is required only when you interact with the popup panel or the option pages.
Adding support for a less-resource intensive API to filter is fine. The problem people have is the destruction of the more powerful APIs to permit the fine control that UBO requires, to do the job proper. There was no need for that, there was no trade-off¹ being made.
It has the connotation of being "Lite" since they're low-mass particles. And it sounds vaguely like "neutered", which is what MV3 attempts to do to ad-blockers.
(That being said, this description from gorhill looks great.)
I would call it "uBO Reduced". Reduced resources, reduced permissions, reduced capabilities, reduced effectiveness in actually blocking ads, trackers and content.
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.
> 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.
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).
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.
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.
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.
> 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.
