The problem at this point isn't whether chrome will disable it... It can be added back, probably fairly easily as google intents to keep it around for "enterprise" anyway, so it's probably just gonna end up changing/removing one if-statement. If not, then the code already exists and has to be merged back in.
The problem is distribution of the actual extensions, as Vivaldi kinda pointed out, as the other browsers mostly rely on the Chrome Extension store. If Google really decides to pull the plug here they could start rejecting extensions using the old, removed-from-Chrome APIs. And then what? Each browser such as Vivaldi, Brave, Opera has to implement their own app store just to host the old-API ad-blockers. And implementing such a store is a major feat. And the walled garden strikes again.
Vivaldi already indicated they might create a "limited" store, meaning not a real store open to the public, but one where they list hand-picked old-API extensions such as ublock origin. Of course, innovation is still stiffed as you in such a "chrome-store + limited vendor store" scenario cannot just develop new extensions using the old-API because you'd have no chance of getting listed in the chrome store, and essentially no chance in the hand-picked limited vendor ones.
Since Firefox support WebExtensions now (or will soon get it) which are very close to Chrome extensions, it wouldn't be unthinkable for all non-Chrome browsers to use Firefox store instead of the Chrome one. I think Mozilla could even be convinced to open it up as an "open web extensions" store or collaborate with others to build a new one. They certainly have the infrastructure and experience to run one.
Mozilla supports WebExtensions since 57+ afaik. Not sure about this if there are some differences in implementation and API's between Firefox's WebExt and Chrome's.
Uh, Firefox already supports WebExtensions and it is like common knowledge. Mozilla barely has the experience to run a sync service, and even that is a disaster.
Why wouldn't the other vendors band together and make a single, non-Google chromium extensions repository? If anyone from Microsoft is reading, this would be an excellent opportunity to give Edge a leg up on Chrome.
I suppose an extension is easier but as browsers can be told to go through proxies, an extension isn't necessary for adblocking. A 2nd process on the machine, a change to the browser (set localhost and a port) and you're done. Someone did something similar and called it Dan's Guardian IIRC, but that's all it was.
That's how I run mine, a local (and very ancient) version of squid blocks everything. It won't be as flexible but it works.
Usually proxying can work for https connections - by letting the proxy terminate ssl. But then you really need to trust the proxy's ssl implementation, and it probably also breaks standard security ui like viewing the cert.
The SSL implementation is the least of your problems. You’d need to have a private CA on your system that creates certificates on the fly. How do you secure that proper. You’d also have problems when reporting SSL errors between the site and the proxy to the browser because from the browsers PoV, the connection looks good.
If I'm wrong about the first point, please clarify. Web/HTTP is really not my area so maybe squid receives and passes stuff through entirely as a blob, if https is used.
Edit. What dgoldstein0 wrote suggests I do misunderstand.
This is an excellent opportunity for Microsoft to distinguish their Chromium-based Edge from Chrome. Leave the webRequest API intact, ensure that these adblocking extensions are available from their own store, and invite other Chromium-based browsers to use their store instead of Google's.
My gut feeling is that Google won't pull this stunt with chrome, this is some kind of scare mongering or a PR tactic, I dunno.
It doesn't make a logical sense because if they are banning the ad-blockers, it means they accept that chrome is largely used by power users who can install these blockers (otherwise, what's the need?). But they should realize that a power user who installs an addon can just as easily move to another browser like firefox/brave. And the PR repercussions will ensure that a lot of newbies will leave too (because they usually follow the power users on youtube) which will essentially kill the advertising income that they wanted in the first place?
I think its gotten to the point where power users go around to all their non-power-user friends and install ad blockers for them, at least I do in our office. The reason this is so successful is because it takes 5 seconds to go the the chrome store and add ublock origin. Convincing my non-power-user friends to move to firefox would be significantly harder. Google's goal is to remove the severity (and effectively the ease) of ad blocking for non-power-users.
This had been happening for a decade or more based on anecdotal evidence - so much so that I had to double-check then change my intranet app at a previous smaller company (2008).
The new thing is Google valuing their profits over the wishes of a large population of their users.
This is how big companies lose their way and get eaten by smaller companies. We all think Google is invincible because of their technological monopoly, but the problem of having to grow forever due to the way public markets work necessitates product evolution or squeezing blood from the stone. The real monopoly is philosophy, not technology, and it's so, so, so easy to lose the logos/pathos/eros high ground (and thus the philosophical war).
In Google's case, their innovation has never been able to eclipse their original sin: advertising. As long as your god is ads, you will make compromised product decisions that are not in alignment with your users. This is part of why I actually hope FB's currency takes off because maybe they can stop worshipping at the altar of click revenue.
Who am I kidding, it's just another revenue line-item on the 10K.
I tend to think of ethics as a subset of logic with a side of pathology, whereas love (eros) is a singular category.
I guess if I had to really sort it, I would only talk about love and power, in that order, but I think it's more addressable to speak in language people already kinda get.
GP wasn't saying Firefox is difficult. GP gave a specific example of how it's easy to install an ad blocker on a system that's already running Chrome for someone else; no need to convince them to change browser, no need to tell them to double-click a different icon.
> it means they accept that chrome is largely used by power users who can install these
You're making a very big assumption here. Last I checked people who blocked ads counted in the hundreds of millions and the number was growing rapidly.
Chrome isn't "largely used by power users", it's used by 60+% of all web users[1] which means it's largely used by nontechnical users. Power users will block ads somehow, whether by changing fork or changing browser or running a PiHole.
However, over 300 million users run adblockers[2][3] and it's probably a fair assumption that most of those users are relatively nontechnical and only run them because they're very easy to install.
I think this push is just to add a tiny bit of friction into the process so that 'casual' adblockers stop bothering.
Maybe think about it in a different way. Right now, there is a kill-switch within googles primary product that could essentially destroy their business model.
This is not about google wanting to harm the current power users. It is probably the idea that someone could come along and destroy their business.
If such an extensions goes mainstream that could seriously harm them.
They may also want to get rid of paying Adblock Plus money for their highway robbery.
Now that I think about it, getting rid of ABP may be the primary reason for this move. They have to basically pay a third party to get access to their own users.
Either way, the battle is not over the power user minority, but over the average user.
The idea is to make the API just powerful enough for the most annoying ads to disappear. Most users would probably be content with this. They will probably make it so they won't lose all of their power users. I think what they really want is increasing the amount of works it takes to have full adblocking functionality to the point where the average user has no access to it.
> getting rid of ABP may be the primary reason for this move
This makes no sense to me.
ABP is already publishing a version using a declarativeNetRequest-like API, it's in the Mac App Store[1], so clearly it's not going to "get rid of ABP".
Google benefits from ABP and AdBlock[2] being the most used content blockers, as they do not block Google ads by default, and do not block trackers/data miners out of the box.
If Google (rightly) deems content blockers as unavoidable, it sure would want people to install the ones which are not blocking its ads and trackers by default.
You are probably right, although a low number of rules will also affect them as their acceptable ads program is based on the fact that they block everything else. I still wonder if they can continue to offer that program with 30,000 rules only. My idea that they target ABP came from their arbitrary 30,000 rules limit.
As I have written elsewhere I consider ABP and AdBlock as "infiltrated" by Google, so they definitely want to see the rigorous blockers disappear first. Should have made that clearer in the comment.
The Safari version supports "Acceptable Ads". I counted ~17,000 rules[1] which includes exception rules. Also, keep in mind cosmetic exception filters are not implemented through the declarativeNetRequest API.
It's been my assumption that with a little bit of scripting, EasyList could be pruned to land within the 30K without too much trouble. As you have more experience in this fields though, do you have any thoughts on how viable this approach would be, and if the 30K limit will be a problem in the end?
Doesn't any finite length list that is only able to be updated when the addon is updated mean ad networks can use a random string with more combinations than the size of list to defeat all ad blocking?
This is API that ABP can use. But with the new API the rules list will be limited to 30 000 rules vs. for example 42 000 EasyList is using, and an update to the rules will require a full update of the plugin.
You do link the comments, so just to point out "will not be affected" isn't true for many reasons...not just the reduced ruleset. Details are in those comments. It will be a lesser product all around.
The idea is to make the API just powerful enough for the most annoying ads to disappear.
In other words, to block ads on third party networks but leave Google ads alone. That's a bold move these days, when antitrust regulators are putting big tech under the microscope.
well, anti-trust these days is just a buzzword, in a legal sense it is defined in a very strict way, and the cost for companies to anticipate an anti-trust ruling is way higher than just pushing their own interests.
With 66% market share and countless other browsers available, the only question for antitrust when it comes to browsers is if users have equal access to browsers, not whether google supports ad blocking.
I think they will make sure that the ad blocking capability does not explicicly favor google ads.
You know that's wrong. There's Chrome, Safari, and Firefox that support most things and which most people actually use; Internet Explorer is dead and Edge is becoming Chromium; and Brave, Midori, and Vivaldi are also Chromium.
There's also Lynx, Links, w3m, Dillo, and Netsurf, but very few people use those and ad-blocking isn't much of a concern there, because they don't enable JavaScript necessary.
>It doesn't make a logical sense because if they are banning the ad-blockers...
To be clear, you can still block ads under Manifest v3. I don't know where this idea that you suddenly won't be able to block ads came from, but somebody is being dishonest about it.
Ad blocking capabilities are limited and there's no API to implement advanced rules like media size limiting. For example manifest v3 has no way to implement the full EasyList.
That's true on both counts, but less of a concern than you might be thinking. EasyList can be slimmed down significantly without losing any blocking. Media size limiting is a more interesting use case, but probably not why most installed adblockers in the first place.
They do have their own store. However, Opera's add-on store is not a great experience. I'm not sure what's going on there, but I know of at least one company where they submitted a new extension to that store it took them around 6 months(!!!) to approve it.
It was easier to self-host the add-on for people who want it, so that they can download it from your website.
The problem you described actually happened with Firefox and Firefox forks not too long ago. Mozilla kicked out all traditional Firefox add-ons from their repository to "replace" them (note: they didn't actually replace the vast majority) with chrome style webextensions. Firefox forks were forced to implement and run their own add-on hosting system and API, and navigate the complex legal waters of re-hosting the add-ons if they wished to continue having access. One notable example of this is the Pale Moon browser. But it all turned out all right. The PM add-on "store" works great and is reliable.
It's not beyond the capabilities of efforts like Vivaldi or Brave to do the same as the Pale Moon team.
And how many add-ons are updated and maintained specifically for Pale Moon - especially compared to the number of add-ons for Firefox for which that is the case?
Because that is the danger for the Chromium forks too - that nobody will bother with their forked store.
Ironically Firefox killed their extension API to be compatible with Chrome's extensions. Now they probably don't want to be compatible with the new Chrome API.
As well as to expose a stable extension API (no more XUL extensions breaking randomly on every browser update) and to enforce any sort of security boundary/permissions system.
Its sad to lose DownThemAll and the plethora of othwr XUL extensions, but having performant multicore support is critical given the shift to having many cores (as single thread performance improvements become uncommon).
I recently used the webRequest API in Firefox and it is already more robust than the Chrome equivalent. For example, you can write stream filters to process request responses. No so in Chrome, where you have no such capability.
Each browser such as Vivaldi, Brave, Opera has to implement their own app store just to host the old-API ad-blockers. And implementing such a store is a major feat. And the walled garden strikes again.
They should team up for the good of all, and create a communally owned fork of Chromium that they all contribute to, and a marketplace. That way the ensure their ecosystem can thrive outside of Google's kingdom.
Isn’t one of Brave’s main selling points that it itself is an ad blocker and doesn’t require a third party extension? Something about removing ads from pages before they even make http requests.
Walled gardens for extensions is also a big problem. Maybe web browsers will finally be forced to give up that control because of all this. Personally I would like at least user freedom to choose extension stores for themselves.
Business-wise, I would love to own an app store, and exercise control, and (eventually) cut myself in as the middleperson on for-pay software sold through it, as well as paid placements and ads.
The reason that no browser does this is because that's the easiest way to go from "some sites are broken in this browser because no webdevs care to test with it" to "many sites are broken in this browser because webdevs deliberately go out of their way to break it". It's the nuclear option that a browser like Firefox would only go for (in the climate of the current web) if things got truly desperate for them. It's why, for example, Firefox didn't start blocking third-party cookies until Safari did it first: it gave them political cover to do so (and Safari can do whatever it wants because it's the only game in town on iOS).
I hadn't considered the ramifications to extension distribution. If Google's Chrome extension store chooses to not host extensions that use the webRequest API, other Chromium-based browsers will need to maintain their own extension stores or users will start installing unvetted extensions from shady third-party websites.
The problem is distribution of the actual extensions, as Vivaldi kinda pointed out, as the other browsers mostly rely on the Chrome Extension store. If Google really decides to pull the plug here they could start rejecting extensions using the old, removed-from-Chrome APIs. And then what? Each browser such as Vivaldi, Brave, Opera has to implement their own app store just to host the old-API ad-blockers. And implementing such a store is a major feat. And the walled garden strikes again.
Vivaldi already indicated they might create a "limited" store, meaning not a real store open to the public, but one where they list hand-picked old-API extensions such as ublock origin. Of course, innovation is still stiffed as you in such a "chrome-store + limited vendor store" scenario cannot just develop new extensions using the old-API because you'd have no chance of getting listed in the chrome store, and essentially no chance in the hand-picked limited vendor ones.