Chrome's June 2019 statement about Manifest v3 in which they tell us all how much they really care about users and this totes isn't to weaken ad blocking(which directly affects their revenue - that's just a coincidence - pinky promise!):
Here's an interesting thought experiment: what would it take to convince you that this change really is being made for performance and security reasons, and not to hurt ad blocking?
Given the level of cynicism directed at Google by the HN community, is it even possible for Chrome to lock down extension permissions in a way which wouldn't be seen as some sort of aggressive move against ad blocking? Keep in mind that secure, user-friendly permissions systems do have to be somewhat restrictive in order to be effective (see Android, iOS, etc), and that ad blocking extensions will necessarily be impacted as a result.
#1: They would have to give a rationale for the change which actually makes sense. The privacy explanation does not make sense because the observational capabilities of the API are explicitly not being removed. Therefore there is no benefit to user's privacy as a result of the changes. The performance explanation also doesn't make sense if we look at the numbers that adblocker vendors have been publishing in response to these changes.
#2: In light of the backlash to the proposal they would have to actually consider not implementing the change or at least consider some alternative implementations. So far all they have done is say "we've heard your concerns, and we're just going to do it anyway". Many interesting ways have been proposed to achieve the same supposed benefits as what Google claims manifest v3 will provide. But they have not responded to any of those ideas and are blindly persisting with their proposed model with all its downsides. So why even act like this is some kind of open process which involves real developers?
#3: They would need to demonstrate that they are actually concerned about the ability of adblocker vendors to deliver good products. They could have created a transition window from the old API to the new API to see in practice how adblocker vendors choose to use it and what limitations they face. But they haven't done that, instead they announce they're killing the old API the same moment they introduce the new one. That to me demonstrates that they don't really care if it's sufficient for those vendors or not.
If the observational web request API was also deprecated, that wold be a strong indicator that Google's intentions were good.
If Gorhill (and other extension developers) endorsed the changes, that would be a strong indicator to me consider that they might be user-friendly, and that the concerns about them were overblown.
Google could also theoretically just convince me outright. They would need to convince me that extensions were currently hurting my privacy, security, and web experience more than ads. That would be very difficult, but theoretically possible. A blog post that solidly addressed critics point-by-point, rather than simply saying, "no that's wrong", would go a long way.
It's not helpful to Google now, but if the Chrome team built up a reputation for being more thoughtful, I also wouldn't be more likely to take them at their word in the future. I've written about this in the past, but Chrome has been handling developer criticism poorly for a pretty long while, and that pattern eventually reduces developer goodwill. When it comes to trust, everyone is a Bayesian.
That doesn't mean I don't try to consider their arguments, and it doesn't mean by default I assume the worst, but I'm only considering Google's arguments on their own merits. If the changes don't make sense to me, I'm not going to assume by default I should accept them anyway. They can't just say, "trust us, we've seen the numbers."
It doesn't lock down the ability of extensions to inspect and spy on all your traffic just block it. This in and of itself demonstrates the purpose.
Also lets be real there are only a handful of adblocking extensions that have most of the market share run by legit players they could trivially vet and whitelist a small number of extensions that are allowed this privilege.
It's not about security its clearly about ruining adblocking. A tiny blocklist that can only be updated with the extensions ensures that it is always trivial to work around blockers. One can simply ask which which version of the extension one has and load ads from a url/host created since.
> what would it take to convince you that this change really is being made for performance and security reasons, and not to hurt ad blocking?
Is there a security argument for this change? I must have overlooked it.
As for performance: users have a choice about what extensions they use. If Google sincerely believes that their proposed limited content blocking API is adequate, then they can expect that users will notice the performance advantage and move to a new ad blocker even if the old API remains present. That's the main mechanism by which uBlock Origin has largely replaced AdBlock Plus.
On the other hand, in the (fairly likely) case that we find out the new ad blocking API doesn't allow for very thorough blocking, and the ads that make it through slow things down more than our current generation of full-featured blockers, then the lower overhead of the new API really doesn't help end users in any meaningful way.
Divest Chrome to an independent foundation. There is nothing cynical in being suspicious of the dominant ad business on the internet misusing their position. There is nothing they can do to alleviate that mistrust short of giving up control (or being forced to in the pending antitrust action).
Maybe make this step after discussing & listening to the other browser makers who support extensions.
Maybe listen to the people who actually write the ad blockers.
>"I think they've been trying to give the impression that they’re working with the developer community, when in fact they’re pretty entrenched in what they want to do," says Jeremy Tillman, president of the privacy and security-focused ad blocker Ghostery."
https://blog.chromium.org/2019/06/web-request-and-declarativ...