Anyone remember "DOS ain't done until Lotus won't run"? Now it's "Chrome ain't done until uBlock won't run".
If it's not Manifest V3 that makes the Internet safe for advertising, it'll be a "browser integrity" token or some other kind of DRM-by-another-name. Google has made it clear with YouTube that the arms race is on, and sooner or later they'll go nuclear.
Agree, that's why I always sticked to FF even when Chrome had superior performance and/or functionality. Giving such leverage to a company that lives of pushing ads into your face is insanity.
You can’t really fork chrome; it would be unsustainable as an open source project. Unless you plan to keep integrating upstream changes - but then you’re still following whatever Google wants to do, you can merely delay it.
It’s probably successful in that it’s a well known project within the tech community. And 0.05% of the global browser market is a lot of users and probably a decent business. (Are they profitable?)
But outside of HN type audiences, no one has heard of it.
> followed by Google's automatic (and mandatory) "privacy protecting VPN" built right into chrome!
Hmm...
My workplace banned the use of Brave a number of weeks back because Brave started including a VPN with it. They were concerned about people using the VPN to bypass corporate security mechanisms.
If Chrome did the same, I wonder if they'd ban that as well?
Actually looking a bit more at how the xhr filtering is implemented, uBO seems to do it not at the webRequest level but instead by shimming the javascript fetch() method itself. So maybe this approach would still work in a MV3 world, I don't know what restrictions are imposed on content scripts.
I already have firefox installed on all my machines slowly transitioning over. Chromes new UI updates are really pushing me over to firefox faster. Now when I set up nee computers for friends I install firefox for them, when they ask me why not chrome I tell them chrome is old news and not to be trusted which they happily accept and use firefox. Slowly the tide is turning.
I've been Chrome-less for several years and I am "Google-free" with regards to email, phone, services, etc.
However, going without any Youtube is difficult. There's a lot of interesting content out there. Do you use an alternative way to access it, or go without it entirely?
If I'm really motivated I either just download the content (yt-dlp) or use duckduckgo search interface. It's actually not bad.
I started hosting Viewtube app hoping I'll catch up, but while it's quite amazing (surprisingly light and emulates subscriptions behavior for you), I had issues with it... So as for now I remain mostly cut off.
There is a lot of great dev and ops related content (conferences) that I come back for, but not for subscriptions I used to love.
> If it's not Manifest V3 that makes the Internet safe for advertising, it'll be a "browser integrity" token or some other kind of DRM-by-another-name.
There are already plenty of banking sites and such that will turn you away for not having a standard-issue Chrome user agent header. Also, crank your browser's privacy settings too high, and any website with twitchy Cloudflare settings will give you the sisyphean "I'm not a bot" check box until you give up and go away (or come back with a Chrome that's hungry for cookies).
So no, on our present course, Firefox will not save us. And even if every HN reader used it, that wouldn't even come close to pushing its usage share out of the single digits.
>There are already plenty of banking sites and such that will turn you away for not having a standard-issue Chrome user agent header
There are countless banks out there. I have bank accounts with several different institutions in two different countries and they all work fine with Firefox + uBO. If yours doesn't, why are you supporting them?
>Also, crank your browser's privacy settings too high, and any website with twitchy Cloudflare settings will give you the sisyphean "I'm not a bot" check box until you give up and go away (or come back with a Chrome that's hungry for cookies).
I haven't seen this. If a website is too much of a PITA to use, I just won't use it, and I suggest you do the same.
> There are already plenty of banking sites and such that will turn you away for not having a standard-issue Chrome user agent header.
Don't use that bank.
> Also, crank your browser's privacy settings too high, and any website with twitchy Cloudflare settings will give you the sisyphean "I'm not a bot" check box
Don't use that website.
It's certainly true that you have no agency or self respect if you embrace a defeatist and submissive outlook.
Do you think the situation will improve while Firefox has 3% market share, down ~2% from 2 years ago, and with <1% share on mobile?
You're nitpicking, there are lots of corporate sites that only test against Chrome/Safari these days. I'd love it if Firefox would regain popularity, and Chrome would lose its stranglehold, but let's not stick our heads in the sand about the way things are going.
If a website is useless to me because I'm using the "wrong" browser, my solution is to not use that website. Easy peasy.
Even if it's my bank -- there are other methods of doing business with most banks, after all. And if my bank, for whatever reason, can only be dealt with through their website then I'd change banks in a heartbeat.
Are you failing to respond to the point about the web environment integrity digital rights management proposals because you don't understand it, or because you somehow just don't think it is relevant? Like, in a world where Google gets that deployed and websites start to rely on it, what, exactly, do you think your ad block extension is even going to do?
How exactly is YouTube going to implement this new stuff on millions of embedded clients, namely smart TVs and other such devices that have YouTube clients built-in, and which never get updated? If YT tried to implement some kind of DRM like this, they'll instantly lose a large portion of their userbase.
They can afford to play the long game and roll it out over a decade or so if it means complete control of the web. By then old devices can be "reasonably" dropped from support for some BS Security excuse or another.
Edit: an example is Windows 11 requiring new enough processors for security reasons even though it would run on older PCs.
I will not use those sites simple as. If there is media I want I can get it from the high seas, for free and have a better view experience. The corps have more too lose in this game. If they want more piracy and this is how you get more piracy.
The nuclear option will eventually be to just ban Google accounts for using any ad blocking.
The question is whether that atmosphere would simply cause people to quit Google services vs. turn off Adblock altogether to continue using them. I would wager that the latter would be far more likely and common for the average person.
I agree with your intuition on the latter being more likely. And Google won't care about the minority of power users they lose. They've been outwardly hostile toward power users with Android for years.
True, but getting an iPhone to tinker with is kind of like buying a book to rearrange the words into your own story. They crafted a beautiful walled garden for you, and the walls are a feature - which is definitely not for everyone.
That said, I have fond memories of installing Linux on my iPod Mini so I understand the joy of making devices do things they were never intended to do.
> The nuclear option will eventually be to just ban Google accounts for using any ad blocking.
The collateral damage from that would probably lead to the mother and father of all class-action lawsuits, literal Acts of Congress, and EU fines that Google would have to get a second job in order to pay if they don't try to break them up outright.
Firefox only survives because Google props it up. I don’t think Google can stop completely without incurring antitrust wrath, but they could probably start attaching strings and conditions to the funding.
Alternatively, the more users Firefox has, the more incentive Google has to twist Mozilla's arm. I doubt that ultimately defeats forks that are maintained by volunteers (https://librewolf.net/), and I don't want to discourage Firefox adoption, but it's not quite so cut-and-dry as "use Firefox". There will likely come a time that it's "use this community fork of old-Firefox-before-it-got-Googled".
Still not a case against Firefox; just pointing out there's more to the picture.
In the past, when FF was stronger, they took search deals with other engines (yahoo, bing). If their numbers go back up, it could be a viable strategy again.
Maybe I'm old, but doing the right thing on the internet has always been harder than just going with the flow. Using Linux in 2000 was very hard, using Firefox in 2001 was no walk in the park - but one gotta do what one gotta do, if one has some principles.
In other words, if Firefox becomes popular enough, there's a chance that Google will deliver a nail to Mozilla's coffin in pulling their search deal and other funding which is the backbone of their business in a financial level.
Another example is that Mozilla has a LOT to lose if the DOJ wins in the US v. Google antitrust trial just for those deals.
> Improving content filtering support by providing more generous limits in the declarativeNetRequest API for static rulesets and dynamic rules
Anyone here know more about this?
From the article linked in that quote:
> We determined that some filter rules, such as those with an action of block or allow, are much safer and are less likely to be abused. They also happen to make up the large majority of ad block filter rules. Based on this, I drafted and shared a proposal in the Web Extensions Community Group to define a set of rules that we consider lower risk and allow up to 30,000 of these.
From what I remember of the discourse at the time Manifest v3 was first announced, the most major complaint from developers who were otherwise open to the idea of static filters was that the number of filters allowed was way too small for the modern web.
Google's proposed changes seem to address that, maybe? I don't know how effective they are in practice.
DNR is better than at launch, but still full of feature gaps. How do you match a redirect response? How do you robustly rewrite URLs based on query parameters?[1]
The fundamental problem is that DNR is not an adequate replacement for webRequest. From something I wrote[2] a couple of years ago:
> [R]emoving blocking webRequest won’t stop abusive extensions, but will harm privacy and security extensions. If Manifest V3 is merely a step on the way towards a more "safe" (i.e., limited) extensions experience, what will Manifest V4 look like? If the answer is fewer, less-powerful APIs in service of “safety”, users will ultimately suffer. The universe of possible extensions will be limited to what Google explicitly chooses to allow, and creative developers will find they lack the tools to innovate. Meanwhile, extensions that defend user privacy and safety against various threats on the Web will be stuck in the past, unable to adapt as the threats evolve.
For the most part I agree with your quote save for the “stuck in the past, unable to adapt” part, I’d replace with “lag behind”.
If the things continue to develop the way they are now, the new features will be eventually incorporated into DNR (in somewhat different form, but anyways). Basically, the “innovation” should be requested via the W3C group from the browsers and only then (after quite some time) it can be used as a part of DNR.
Is it worse than what we had before? Absolutely, adding anything to DNR is now a many-months process.
Do we get anything in return? We actually do, the changes and improvements that are being made to the extensions platform are significant.
I’d say that the situation changed from “MV3 is bad, DNR is unusable” to “MV3 is good, DNR is useable-but-limited”.
> Do we get anything in return? We actually do, the changes and improvements that are being made to the extensions platform are significant.
Honest question, what kind of significant improvements do you actually see in MV3? I see a lot of more restriced, more complex APIs but few new features.
I would argue that new APIs are better thought through and cover the use cases that the extensions actually need.
Let me name a few examples.
1. chrome.scripting API and the concept of "isolated worlds" is easier to use and understand than what we had before.
2. Dynamic content scripts registration that everyone has waited for so long.
3. userScripts API is also a welcome addition. It does not provide everything and it needs to be improved, but it is already a good step forward. Finally the existence of userscript managers was recognized by Chrome and they're trying to make life easier for them.
Also, the bug fixes. Before the expansion of the extensions platform team there were major bugs that could be open for many years, and now I see them closing one by one. To an outside observer it may look ridiculous that there was such a problem from the start, but that's how underinvestment looks like and I am happy that the situation improves.
Even DNR is not a bad API by itself, the problem that was never addressed is that in MV3 there is no blocking webRequest anymore and DNR cannot fully replace it.
> the concept of "isolated worlds" is easier to use and understand than what we had before.
Isn't this basically the same concept they already used with ordinary content scripts for years? It's indeed useful, but also something that could have been relatively easily emulated with dynamic execution inside a content script before, I believe.
> 2. Dynamic content scripts registration that everyone has waited for so long.
3. userScripts API is also a welcome addition.
Yes, but those too are just an improvement compared to the previous state of MV3. In MV2 none of those APIs would even be necessary because an extension could easily implement this stuff itself. So it's an "improvement" in the sense that it now only removes 30% of the functionality instead of the 50% it did before.
> Also, the bug fixes.
That's orthogonal to MV3 though. And it again sounds like "we're now slightly less shitty to extension devs than we were before".
> Even DNR is not a bad API by itself, the problem that was never addressed is that in MV3 there is no blocking webRequest anymore and DNR cannot fully replace it.
It's indeed not a bad API and there are many use cases in which it's clearly the better choice than the blocking version. However, the removal of the blocking variant and the removal of various usecases is Google's entire point here - otherwise, they wouldn't be so cagey with setting the limits of the number of rules. Firefox shows that it's no technical problem at all to implement both APIs at the same time.
> Isn't this basically the same concept they already used with ordinary content scripts for years?
It was implicit, now it's explicit and it gives more control and better understanding. It also allows introducing more levels of isolation, like a separate "USER_SCRIPTS" world or "MAIN", before that you had to mess with evals and adding script tags.
> Yes, but those too are just an improvement compared to the previous state of MV3
Yes, that's why I listed these as improvements.
> And it again sounds like "we're now slightly less shitty to extension devs than we were before".
They went from "1 person that tries to make things not crumble" to a large team of developers, it's a big step forward. What signal do we send them if we always say "everything you're doing is bad" even when it's factually not true?
> Firefox shows that it's no technical problem at all to implement both APIs at the same time.
At first we all thought that DNR is there for them to limit content blockers. With time they proved us wrong when they worked hard on improving it and covering more and more use cases.
Now I tend to think that this is an engineering decision that's driven by the other change - the shift from persistent background pages to service workers.
Is there a better solution that could save the blocking webRequest and achieving their goals at the same time? Most likely there is, but how hard would it be to implement it instead or what if it requires an architectural change? Anyways, these are speculations, I am with you here and I don't support blocking webRequest removal.
Good comment. I guess it’s a matter of hope :) I really want to believe that the extensions platform will continue to develop with at least the same pace, and eventually comes to Android. Maybe I am over optimistic though, we’ll see, but otherwise I just don’t understand what was all that about and what justifies such a significant investment in the extensions team.
Some, but not all of the problem, can be mitigated by pointing your DNS to mullvad (the no-ads one; DNS doesn't need a subscription unlike the full VPN product).
Ironically, this might be a market opportunity for MS to get a few users back to chrome's poor cousin Edge, if they allow proper extensions again.
> Despite losing a small part of their functionality, ad blockers will still be able to offer nearly the same quality of filtering that they demonstrated with Manifest V2.
If some mechanism or capability is no longer possible or is made infeasible for adblockers to control, then ads will simply switch to using that mechanism. It's a pretty obvious outcome. You cannot simply give just an inch with adtech.
I would be interested to see a list of capabilities and features lost in MV3. For example, do we lose CNAME filtering or strict-blocking? It's not clear what we are losing.
The last time I check a couple of months ago these was the list of things that we lose (Things might have changed so I welcome correction from any kind)
- Now any block filter list will have be updated with a plugin update. So no fetching lists from links directly.
- strict blocking ability [1]
- No dynamic filtering [2]
- No Custom lists (own or third party by the user)
Google is an advertising company. Chrome extensions already experienced a lost decade, where nothing much happened until the Manifest V3 "proposal". It's not a good idea to let Google hold the keys to anti-tracking tech.
[1] I stand corrected, DNS lookups are not part of webRequest in MV2 Chrome either. This doesn't change my larger point.
That approach doesn't work well given Firefox's established track record of just imitating Chrome, and then getting rid of the prior (and better) way of doing things.
XUL extension developers are well aware of this problem, for example.
We've seen it happen repeatedly with Firefox's UI, too.
> That approach doesn't work well given Firefox's established track record of just imitating Chrome
Established track record? What?
> and then getting rid of the prior (and better) way of doing things.
Do you mean how they did the complete opposite by keeping Manifest v2 around for much longer than Google wanted to? Then by making their own Manifest v3 that didn't gimp ad blockers like google has been trying to for years?
> XUL extension developers are well aware of this problem, for example.
XUL was super useful... for it's time.
But it became a drag on performance as Firefox became more optimised for multi-core CPUs. And it became a drag for developers trying to support an older standard. Sure the new extension standard became more difficult to get started, but it did push the workers standards forwards which is ultimately what the web needed.
> We've seen it happen repeatedly with Firefox's UI, too.
Firefox's UI goes up and down in quality all the time. Thinking nothing is improving at all is an observational bias.
Firefox has removed a lot of features, but they view ad blocking as a core selling point for the Firefox product. They've published a handful of blog posts endorsing specific ad blockers, including AdNauseum, an extension that Google considers to be malware because its purpose is to facilitate the user DoSing Google ad servers. So Mozilla will very likely never leave their implementation of the extensions API deficient for ad blockers. They've laid out exactly what they promise to continue providing in the API, in no uncertain terms.
Many of the changes to FF over the last several years have been, in my opinion, just plain bad.
That said, it's not like there's a large amount of choice in the browser space. Today's Firefox can be worse (in ways that are important to you & I) than yesterday's but still be the best of the options available to us today.
My opinion, and the reason I switched back to FF, is that FF is the "least bad" option we have.
They have to, since big silicon valley companies just copy things and sell it as their own, like everyone exists to wipe their arses. Essentially they are stealing whatever they can find. If you copy and coexist with them they can't steal shit, and since they can't innovate, because they lack the brainspace for it, they'll slowly die. Maybe this is one of the reasons Firefox acts like a braindead monkey.
You should not be using Chrome anyway but if you still do, its time to switch and advocate for different browsers. Brave has a uBlock Origin based adblocker build in, written in Rust. Firefox is the best browser for uBlock Origin.
Brave's adblocker is written in Rust [0] and compiled to native code; it's not affected by the Mv3 transition because it doesn't use extension APIs. Brave also publicly committed [1] to continuing support for Mv2 through patches.
Why make claims you have no clue about? As someone said above Brave is NOT affected, their adblocker is a the very core of the browser and a basic chromium extension.
I am also wondering if there is or will be a Chromium fork that just keeps the old code and not enforces v3 but just support both v2 and v3 and then also default to accept some alternative extension store that also has v2 extensions.
I don't use chrome but if I did why is this a good or bad thing? Is this just a part of Google's push to force users to give up all their data under the pretense of security?
It's making content blocking extensions work the way they do in Safari. The benefit is security, as it allows for a massive reduction in the amount of extensions with unlimited powers to steal authentication cookies, MITM ostensibly secure connections, etc. The downside is a loss of flexibility in what ad blockers can do (though Safari ad blockers seem to get by well enough). It's unclear whether it's an improvement or reduction in power efficiency.
In typical internet mob fashion Apple doing this is considered doubleplusgood, Google doing it is them being evil and trying to kill the Internet.
> In typical internet mob fashion Apple doing this is considered doubleplusgood, Google doing it is them being evil and trying to kill the Internet.
It wasn't actually considered good that Apple killed the safariextz format. There were a ton of complaints among Safari users.
But of course Safari for Mac has a small marketshare, given its nonexistence on Windows (since Safari for Windows was discontinued in 2012), so it can't kill the Internet. On the other hand, plenty of people think that Apple's browser engine restrictions on iOS are killing the Internet.
The difference is that Google is an ad company, as in the vast majority of their revenue comes from ads. Apple is not an ad company. As such, Apple gets the benefit of doubt in these situations because their bottom line doesn’t rely upon misleading users into sharing more data or viewing more ads.
Apple and Google have drastically different profit incentives.
While ads are not the main driver of revenue at Apple they did develop a ad service at the same time they implemented the new "privacy" features on iOS.
I recall many complaints about it when Apple started doing it. Google is just making sure they inflict as much bad PR on themselves as possible by dragging the change out as slowly as they, can which makes it seem like there's a double standard.
There isn't though. Safari is one of the most complained about pieces of software on here. Actually I wouldn't be surprised if it was the most complained about.
Thanks for the example, that's a great demonstration!
The context is that an entity that does not give a crap about making ad blocking hard (Apple) believes that this is the best design for content blocking extensions. They have no ulterior motive, it's just obviously the right technical design.
Setting aside the question of motives, Safari engineers designed their content blocking system (1) without any actual experience in developing ad blocking extensions and (2) without consulting the developers who do have such experience.
Moreover, ad blocking extension developers are practically unanimous in saying that Safari content blockers are inferior and not obviously the right technical design.
Part of the reason Safari doesn't have the market share is because it sucks at such things. No one is actually saying Apple doing it is doubleplusgood. Someone has an "internet mob" persecution fetish.
> though Safari ad blockers seem to get by well enough
I have yet to find an ad blocker that manages to block anywhere close to as many ads as ublock origin. AdGuard is certainly better than nothing at all, but I still see an awful lot of ads while using it.
How's the situation with debugging tools & userscripting extensions (grease monkey, violetmonkey, tamper monkey)?
Outlawing dynamic code (use of eval for example) is a huge locking down of the system, one I have some sympathy for but also think deeply narrows the type of extensions that can be built, in a chilling way.
Which evidently you need to be in some "developer mode" to have work??
I use this all the time just to improve websites I visit, change colors or adjust workflows to make them less jank. My work jira is reskinned with violet monkey.
They're called userscripts. Making folks have to enter a dev mode to use them feels abominable.
Also seems like this narrowly targets just userscripting cases, while ignoring any other use cases where we might want to have dynamic behavior. It still doesn't allow me to write an extension that lets me ship up code & run it. I get this is by design, to improve security, but it feels so much less like my user agent when I'm outlawed from running whole categories of code in the browser.
My best hope is that many of the dynamic code practices are enforced chiefly by the web store. And that we can sideload whatever we want.
I've got maybe 4 extensions that are manifest V2 that just purely don't seem worth upgrading/fixing up (my largest with 5-10k installs) due to the time/5+ year old code that has been working fine on the old apis... Has chrome done some outreach to the popular extensions, or maybe just gone past a point where they're happy to kill off the old and move onto the new? Or is this purely about ublock etc?
Do you control your browser? Manifest V2 you can write a plugin to modify the page in pretty much any way. This is used by adblockers but philisophically important because this is no longer possible in V3 in the name of security. Instead chrome mitigated the adblock concern in-particular.
But manifest v2 isn't actually disappearing, it's a chrome web store policy. You can still manually install the crx.
It does say they’ll be automatically disability, but it seems strategically ambiguous to me. What would be the point of saying “you can’t install from the Chrome webstore” if they’re permanently disabling them and not allowing sideloading?
My read was that they’ll disable existing installs (which may be manually re-enable-able by the user), and they definitely won’t let users install them from the Chrome webstore. But it isn’t clear whether these can be sideloaded. My guess is that it will depend on how the rollout goes, and what the antitrust landscape looks like.
It's not strategically ambiguous, just unintentionally ambiguous. Google's earlier announcement was clearer, before the long delay occcured: "The Chrome browser will no longer run Manifest V2 extensions." https://developer.chrome.com/blog/mv2-transition/
> What would be the point of saying “you can’t install from the Chrome webstore” if they’re permanently disabling them and not allowing sideloading?
It's a gradual rollout:
"We will begin disabling Manifest V2 extensions in pre-stable versions of Chrome (Dev, Canary, and Beta) as early as June 2024, in Chrome 127 and later. Users impacted by the rollout will see Manifest V2 extensions automatically disabled in their browser and will no longer be able to install Manifest V2 extensions from the Chrome Web Store. Also in June 2024, Manifest V2 extensions will lose their Featured badge in the Chrome Web Store if they currently have one.
We will gradually roll out this change, gathering user feedback and collecting data to make sure Chrome users understand the change and what actions they can take to find alternative, up-to-date extensions."
MV2 extensions will remain in the Chrome Web Store for some time. The rollout starts in the pre-release Chrome channels and eventually moves to the stable channel. So Chrome canary users will start seeing MV2 disabled even while Chrome stable users can continue to install and use MV2 extensions. Even the stable release will be a gradual rollout.
Let me ask you the reverse question: What would be the point of toggling off MV2 extensions if users could just immediately open the Extensions window and toggle them right back on? That would be a pointless, silly waste of time and effort. Google is not that dumb.
> What would be the point of toggling off MV2 extensions if users could just immediately open the Extensions window and toggle them right back on?
The point would be to get people off MV2 by default, but giving themselves more cover on the antitrust front by technically still allowing people to use these extensions.
Given the ways in which the story has changed about this rollout, my default is to assume that nothing that is projected is set in stone. This is certainly the case for things that have been left unsaid, like the possibility of sideloading.
> giving themselves more cover on the antitrust front
There's no antitrust front on the MV2 to MV3 transition. You're imagining something that doesn't exist.
> Given the ways in which the story has changed about this rollout, my default is to assume that nothing that is projected is set in stone.
That's fine, and Google itself said in the announcement that they're doing a slow rollout in order to collect data and see the effects, but it has nothing to do with antitrust. The MV2 deprecation was delayed because Chrome extension developers complained that MV3 still had serious shortcomings that prevented them from migrating their extensions from MV2, so Google paused to address many of those issues.
> There's no antitrust front on the MV2 to MV3 transition. You're imagining something that doesn't exist.
My understanding is that there is a widespread perception that the transition is largely being executed to neuter adblockers since Google makes so much money on ads. Given how aggressive the federal antitrust authorities have been in pursuing novel claims, I could easily see them going after Google if they prevent users from accessing MV2 extensions at all.
> Like I said, you're imagining something that doesn't exist.
My point is that this is Lina Khan's specialty. Everyone knows it, and Google is undoubtedly calibrating many of their business decisions to make sure that they don't attract scrutiny. This would be especially true where the product involved has over 60% market share globally.
So what? I've already explained in detail why there's no case here. I would hope that Khan isn't dumb enough to start a futile, unwinnable fight.
Google has plenty of antitrust problems, for example, paying Apple $billions per year to be the default search engine on iOS. But the desktop Chrome extension API is not one of those problems.
> Google is undoubtedly calibrating many of their business decisions to make sure that they don't attract scrutiny.
The word "undoubtedly" is incorrect. I'm explicitly doubting you. Not to mention that if Google was actually worried, they wouldn't be doing this extension transition in the first place.
TBH, it gives me pause to be in protracted disagreement with someone whose comments I often find insightful. But I guess what it comes down to is I don't think we can accurately predict the path of the transition, especially because it has already changed several times. If you have an inside scoop on how this is unfolding inside Google, or have worked there in the past, then you'd be in a better position to know.
> But I guess what it comes down to is I don't think we can accurately predict the path of the transition, especially because it has already changed several times.
The schedule was pushed back. That's the only change. Could the schedule be pushed back again? Perhaps. But speculations about various other unspecified changes are entirely imagined and not based on the evidence.
> If you have an inside scoop on how this is unfolding inside Google, or have worked there in the past, then you'd be in a better position to know.
I'm a professional browser extension developer and have been watching this closely for quite some time, for obvious reasons.
Yes. The change is to the extension APIs used by Chromium, and thus Chrome, Edge etc.
Browser makers like Brave build the adblocker directly into the browser, so they don't have to care what extensions are and are not allowed to do on Chromium.
Every adblocker that contains the letters: "ad" has.
Ublock Origin has been the best for almost a decade running and is most powerful when running on Firefox.
Raymond "Gorhill" Hill is the BDFL of Ublock Origin and has never accepted any money from ad companies and has never added/removed any feature that weakens the adblocking.
If it's not Manifest V3 that makes the Internet safe for advertising, it'll be a "browser integrity" token or some other kind of DRM-by-another-name. Google has made it clear with YouTube that the arms race is on, and sooner or later they'll go nuclear.