3 ms·
> if they were suddenly deprived of good adblocking on Chrome. Ok - but that won't happen (at least not yet, given the m3 api available, who knows what google
by horsawlarway 4y ago
> if they were suddenly deprived of good adblocking on Chrome.
Ok - but that won't happen (at least not yet, given the m3 api available, who knows what google will do long term).
The majority of users won't genuinely notice any difference between an adblocker running on m3 vs m2, and plenty of companies are going to make them.
My point is that despite the push back from the UBO dev (and I sort of agree - this does limit some capabilities, although not nearly as much as he claims) M3 is absolutely not going to kill the adblocker extensions available in chrome.
It just makes them... slightly minus. Which is why I think the name is a good call. I don't approve of the direction google is going, but this is not the deal breaker for any sort of public audience - it's just a talking point among the tech literate.
- tyingq 4y ago"The majority of users won't genuinely notice any difference between an adblocker running on m3 vs m2" I think that'll be true for a short time. But once the advertisers figure out that ad blockers have been crippled on the most popular browser... They'll figure out how to take advantage of that. Once Chrome takes away the ability to do live heuristics, and leaves you with just a static-ish blacklist, it's pretty easy to get around the ad blocker.
- horsawlarway 4y agoBut you can already work around adblockers by just serving ads directly from your own servers. Frankly - you can also move to a service that implements adblocking at a different layer (I've seen an explosion of dns based adblockers as a service, likely inspired by the likes of pi-hole). Those services are using roughly the same feature set that's still available in m3. The big dealbreaker (imo) was the inability to configure rules at runtime, and the requirement that they be declared in the manifest - and that never actually happened (you can dynamically configure them with https://developer.chrome.com/docs/extensions/reference/declarativeNetRequest/#dynamic-and-session-scoped-rules https://developer.chrome.com/docs/extensions/reference/decla...)
- tyingq 4y ago>But you can already work around adblockers by just serving ads directly from your own servers The available heuristics in UBO can block those with many different techniques today, especially for a short list of very popular sites. I assume many of them stop working with MV3. I'm aware of the DNS based adblockers, what I'm saying is that the advertisers might take action on all of them once the best option is hobbled. Then it's worth doing something that will break almost all the adblockers. One effort that puts everything to rest.
- BuckRogers 4y agoYour idea results in a glorious day for Mozilla Firefox indeed. But I think you have to look even further down the line, assuming your future does play out as you described. And then all you have to look at is what we have today with Brave. Building in their own ad blockers that don’t rely on MV3 at all. Chromium-based browsers like it will have a market of their own.
- horsawlarway 4y ago> I assume many of them stop working with MV3. Most of them will not. The only real limitation in m3 is the lack of blocking a network request on its way out to inspect it (you absolutely can block it - and the second time it's made you can block it after inspecting the first instance, but you can't inspect then block). To be clear - that's still a loss, but it's just not on the same scale as the type of loss that was originally worried about when Google first announced m3 without a way to update blocklists dynamically. At the time - they were intending blocked URLs to be placed into the manifest file directly, which can't be updated without a full update to the extension in the webstores (2 to 3 days for chrome, couple of minutes for Firefox after first review). That's a real pain, since you couldn't do something like heuristically determine that a request was serving an ad and then block it the next time it comes around. But you can, now (and again - it's not as nice as it was, but it's still there). There are still some limitations that are a pain to juggle (max size of the blocklist, max number of dynamic rules) that do make life a bit harder, but those I can genuinely see compelling reasons for adding - every comparison the browser is making against a blocklist for each outbound url is adding overhead on TTFB for the user - I think their caps are too low still, but at least I have a technically compelling reason to understand why the limitation was added (something other than - Google wants to unblock ads). Basically - I'm telling you, as a subject matter expert in this space: Most users will not notice a difference. Some very discerning users, and some technical users might, but a lot of those folks are already off the Chrome train anyways. > what I'm saying is that the advertisers might take action on all of them once the best option is hobbled. Then it's worth doing something that will break almost all the adblockers. One effort that puts everything to rest. What? What power do you think advertisers have here that will suddenly undo the foundational hierarchy of the internet? DNS ad blockers literally aren't going anywhere anytime soon, and I agree with the general thrust of "If Google destroys ad blockers - users will leave", I just don't think they've done that with m3.
- fomine3 4y agoSince adblocking on Safari (both Mac and iOS) is mostly done by Content Blocker API that's like manifestV3. Many mobile users already in such situation. People still fine with current adblockers on iOS.
- tyingq 4y agoYes. But soon, all adblockers will have roughly the same abilities or lack thereof. That's when it's worth the effort to render them all useless. Risk/reward and all.