When Apple says "We're designing this API in a way that allows you to block ads without having full visibility to monitor everything that any user does every web page they visit" it's totally believable because it's in line with the last 10+ years of their product direction.
Yeah, it makes ad blockers less powerful. It also makes them less of an enormous security risk in that all of your web traffic is redirected through them, and a compromised extension could do whatever it wanted with that.
People are more skeptical of Google's motives because nearly all of their money comes from selling ads and for all we know they're more concerned about their very very very large piles of cash than they are about browser extension security. That's not a motivation that Apple would have for their Content Blocker limitations.
Adblockers don't redirect all traffic though them. If you think about it for a moment you will see how absurd that idea is. This would incur one of the most massive bandwidth bills on the internet for negligible financial gain.
Current ublock origin.
Your adblocker frequently updates lists of patterns to block via any of many user configurable lists.
When you load a site ON YOUR COMPUTER it consults all those lists including custom ones you create yourself for annoying elements on particular sites before loading content. It NEVER sends said content to the adblocker or leaks your information.
Ublock origin provides both the adblocking engine and the lists and can innovate on the former and iterate on the latter as fast as you please.
New chrome restrictions.
Google provides an adblocking engine substantially inferior to ublock. Extensions are able to provide only a list much smaller than current lists and can only update that list when the extension itself is updated. They cannot innovate on the adblocking engine as they are stuck with the crummy one an ad company provides. This basically ensures that ad providers win the arms race with adblockers.
Safari
Shares the same inherent flaw with chrome that Apple will be providing the adblocking engine with the possible benefit that apple isn't directly making money off ads and has less incentive to directly break adblocking.
I don't mean that it sends the actual web traffic through some uBlock server, I mean that the uBlock browser extension sees all of the requests to load a webpage and decides what to do. It can decide to block them or not. It could also decide to scoop up all of your personal information and do bad things with it.
If someone were able to compromise the developer account and get a malicious version distributed through the Chrome browser gallery, that would be a huge problem. The kind of thing that has been making headlines with compromised npm modules recently.
Google has reviews in place to prevent malicious extensions from being distributed, but they can't be perfect. We've seen that repeatedly with both Chrome extensions and Android apps.
Every extension with permissions set for "This can read and change site data on all sites" has a huge target on it, and the fewer things using that level of access the better. Ad blocking extensions are an obvious place to look for improvement because they're so popular.
I hope that Google can put a blocking system together that will be able to perform as well as existing solutions without adding any huge security risks, but I also agree that it's problematic that their incentives are to do the exact opposite.
The latest version of Chrome allows for "read on a write site data" on a per-site basis. Not so useful for ad-blocking extensions, but a boon to any extensions I don't really want to give full access to.
Nah. If they feel inclined to do something more powerful than the Content Blocker API then they should build the ad blocker themselves into Safari. It can be off by default and configurable by users.
It'd make the Content Blocker API kind of pointless but that'd be safer than letting third parties in.
Thank you for clearly elucidating the difference between what we had and what we're going to have moving forward.
I'm so tired of this trend where folk keep pitching significant reductions of technical capability as some kind of "win" for the consumers and developers of a platform.
This is about exploiting platform owner privilege, no more and no less.
As you say it makes ad blockers less powerful. Ad companies are scummy, and will most definitely exploit this, making it either painful or impossible to block their ads using the API. And then the API will be playing catch-up forever.
And trusting a company based almost exclusively on ad revenue to build an ad blocking API is just bonkers. No, the only way to effectively block ads for the foreseeable future is to give ad blockers all the information. Unfortunately.
> Yeah, it makes ad blockers less powerful. It also makes them less of an enormous security risk in that all of your web traffic is redirected through them, and a compromised extension could do whatever it wanted with that.
This presumes I trust Apple significantly more than authors of any conceivable blocking plugin — by large enough margin that it would be worthwhile to lose functionality over it. That isn't really the case — I only trust Apple marginally more and, if anything, making such decisions on my behalf erodes that trust.
"Trust" isn't something binary. I trust them to do something and not something else; they may just be the ones I distrust the least as well. And assuming I _distrust_ someone just because I trusted someone is obnoxious.
No, it's not. Chrome says its for privacy but still allows plugins to snoop on all network traffic (just not midy the requests). So it doesn't improve privacy.
That's why everybody is hating on google - it's a reduction in functionality without an increase of privacy even though that's "why" they did it.
My understanding is that Manifest v3 pushes ad blockers from chrome.webRequest to chrome.declarativeNetRequest, and they do not have the ability to see what requests are made with declarativeNetRequest. They can define rules to block or modify requests, and the browser executes them without letting the extension see any specific requests. Is that not correct?
The complaints from blocker developers have been that Google isn't allowing enough rules (Google has agreed to increase that), and that their existing blocking lists are defined in a way that needs more logic than declarativeNetRequest's matching system.
The point I was making is that chrome.webRequest is still around (as I understand it - if I'm wrong, please correct, because that's my whole point!), it's just for observation only now. Plugins can still request that permission... which means plugins can capture just as much data as before this change.
That doesn't seem like a good trade off, given the two complaints you listed.
Yes, but those plugins will now require more expansive permissions requests when enabling them, correct? It used to be that when you installed an ad blocker, you'd have to agree to allow the plugin to "view and modify all content from all pages" (can't remember the exact wording), now, you don't.
> Yes, but those plugins will now require more expansive permissions requests when enabling them, correct?
If history has taught us anything it's that forcing users to agree to allow access in order to get what they want doesn't stop them from doing it. Especially when programs apps and extensions are required to ask for broad access to accomplish even the smallest tasks that the warnings become meaningless noise. If I want ads blocked and I trust a company enough to install their blocker I'm not going to uninstall it just because it needs access to the content I want it to check over for the presence of ads. No matter how many warnings I get or how scary they sound I still want ads blocked.
webRequest is still around for now, but Manifest v2 as a whole will be deprecated sooner or later and I think webRequest goes away with it. I don't know if Google has specified dates for this, but for historical context here's the timeline from Manifest v1:
Deprecated in March 2012, stopped accepting updates to Manifest v1 extensions in March 2013, and existing extensions stopped working in January 2014.
EDIT: Google's blog post talks a lot about removing the "blocking version of webRequest", so perhaps the monitoring one still exists? But their goal would be to make these into separate permissions - the very popular blocking extensions can work blindly, while monitoring extensions can still function? It's not very explicit about it, but that's how I'm reading it https://blog.chromium.org/2018/10/trustworthy-chrome-extensi...
Not "everybody" hates Google for it. People who don't understand the security implications inherent in allowing browser extensions that have nearly-unrestricted access to the user's behavior -- even if well-intended -- may hate the Chrome team for it.
But there are those of us who understand why the Chrome team made the decision it did, and are sympathetic. And we're happy that the Chrome team and Apple are of the same mind about this.
> People who don't understand the security implications inherent in allowing browser extensions that have nearly-unrestricted access to the user's behavior -- even if well-intended -- may hate the Chrome team for it.
> But there are those of us who understand why the Chrome team made the decision it did, and are sympathetic. And we're happy that the Chrome team and Apple are of the same mind about this.
Hey, you probably didn't mean it this way, but your comment kinda sounds like you're saying everyone who opposes Google's decision is a simpleton who doesn't understand the security implications of browser extensions. That's not true, and more importantly, not especially charitable.
> People who don't understand the security implications inherent in allowing browser extensions that have nearly-unrestricted access to the user's behavior
You can say the exact same thing about any code we run on our devices. We accept that risk or we wouldn't run any software at all. Google isn't worried about our privacy. They take our privacy. They are worried about their profits because that's all any corporation cares about.
We definitely do not represent the vast majority of users.
Many have no idea these risks even exist, or mostly wrong notions about them.
Pretty sure my parents and grand parents don't even want to know their (probably randomly picked) ad blocker could pick up their credit card number every time they type it in their browser.
How could we hold it against them? Computers to them merely are (sometimes cumbersome and annoying) tools.
If your parents are consistently using ad-blockers they're doing better than most of my family. My mother wouldn't know what a browser extension was let alone how to begin installing one. The totally computer illiterate are at least protected in that sense.
The question is, whom do you trust, and who bears the greatest consequence of failure? I'll bet my money on Apple over some third-party extension vendor to protect my privacy.
Besides, in the end, it's all about minimization of threats. The existence of one threat is better than the existence of two. Don't let perfection be the enemy of the "good enough."
> The question is, whom do you trust, and who bears the greatest consequence of failure?
I'm going to trust uBlock Origin because it is free open source software and I can see everything they are doing with my data. Apple on the other hand forbids reverse engineering safari (trying to understand what it does and how it works).
Once you're a part of the apple eco-system apple could theoretically (and to be clear we're talking about purely theoretical privacy risks in all cases) access your browsing history and also tie that directly to your name, address, credit card/bank account, GPS coordinates, etc.
Putting your privacy in the hands of a company that has so much of your data already is naturally more risky than compartmentalizing. If hackers somehow compromise my browser extension they get access to my browsing history on one device until I notice and correct the problem. If a hacker somehow compromises Apple they could get access to much much more. For all their care and resources Apple is not immune from attacks either. Safari has had a ton of vulnerabilities exposed just this year so far.
It's not uBlock Origin they're concerned about, though - it's all the other random extensions out there that could use the same capabilities for evil instead of good.
Ultimately the freedom to decide what code a person runs on their own hardware has to be left up to the user. The users who install every random extension they see are the same ones who download every app and click on every link in the spam they get. You can't protect users from themselves, but you can empower them to better protect themselves.
Downloading a sketchy browser extension takes deliberate action on the part of the user. Just loading CNN.com can (and has) caused computers to become infected automatically because of ads. Limiting the ability to block ads is not protecting anyone.
> Not "everybody" hates Google for it. People who don't understand the security implications inherent in allowing browser extensions that have nearly-unrestricted access to the user's behavior -- even if well-intended -- may hate the Chrome team for it.
...this is a fantastic argument for disallowing installation of custom browsers. I do hope y'all like IE and/or Safari.
Sounds like Google hasn't communicated these technical changes nor their intentions very clearly at all. Just judging how there's multiple people saying different things in this thread for both.
It's clickbait fodder. Construing the manifest privacy changes as Google is blocking ad blockers is better clickbait than saying Apple safari is doing the same thing.
It's similar to when the internet blew up about Google's project dragonfly, which was cancelled, while Apple quietly did the same thing by sharing iCloud user data with the Chinese government.
Apple blocks not only the content, but the ability to even monitor as well. So there is a little extra with the Apple way.
You'd hope google would follow suit, but given their business model it's understandable if they don't. (Not that I'm a supporter of Google's business model, just that I understand why the ability to monitor is still there.)
Chrome has not proposed any change that would prevent extensions from monitoring all traffic. You are ascribing a good motivation to Google, but Google’s actions are inconsistent with your hypothetical motivation.
Specifically, Google proposes to continue allowing extensions to observe all requests, but extensions can’t block requests based on these observations.
* Rules that prevent a request from getting blocked by negating any matching blocked rules.
* Rules that redirect a network request.
* Rules that remove headers from a network request."
> Google proposes to continue allowing extensions to observe all requests
Their expressed intention is to disallow such behavior in the future:
"The declarativeNetRequest API is an alternative to the webRequest API. At its core, this API allows extensions to tell Chrome what to do with a given request, rather than have Chrome forward the request to the extension. Thus, instead of the above flow where Chrome receives the request, asks the extension, and then eventually gets the result, the flow is that the extension tells Chrome how to handle a request and Chrome can handle it synchronously. This allows us to ensure efficiency since a) we have control over the algorithm determining the result and b) we can prevent or disable inefficient rules. This is also better for user privacy, as the details of the network request are never exposed to the extension."
Quoting from the same page, one paragraph up from your big quote:
> In Manifest V3, this API will be discouraged (and likely limited) in its blocking form. The non-blocking implementation of the webRequest API, which allows extensions to observe network requests, but not modify, redirect, or block them (and thus doesn't prevent Chrome from continuing to process the request) will not be discouraged.
Well, yes. There’s a transition in progress. I would expect the older API to be deprecated or removed in a future version, probably within a couple of years.
AFAIK, Safari supports longer lists than Chrome to the point that you can produce an usable ad-blocker for Safari but not for Chrome because you will hit the limit too quickly.
Safari allows 50k per list, Chrome is planning to move from 30k per extension (!= list) to 150k global max per your links. That's quite a difference. On iOS, some blocks use multiple lists -- AdGuard has six and 1Blocker X has seven, for example.
An ad blocker that would be limited to 30k rules, as originally suggested by the Chromium folks, would be severely neutered. And even with the 150k max, I currently have ~240k rules in uBlock Origin. That's way above Chrome's planned max. But easy enough to implement with Safari's model, even if it requires using at least five lists.
Why are you happy for having to pay for an inferior product? If you believe 1Blocker is superior or extensions shouldn't use the now disallowed API, why didn't you use it before? Or if you don't care about this at all, why are you even commenting about this thing which people express their feelings about? Your apathy doesn't make their arguments invalid.
And you've illustrated another problem with online discussions, particularly since the ubiquity of social media. You assumed that my call to moderation in this debate is because of apathy, and presumed to read my mind. I'm hardly apathetic, or happy about it. 1Blocker doesn't work at all on Youtube, so I'm using Firefox for that now, where I can still use uBlock Origin. I'm disappointed, to be sure, but no amount of whinging, no matter how vociferous, is going to change this, so I'm pragmatic about it.
> You assumed that my call to moderation in this debate is because of
Did you read the same comment I did? They're baffled and they asked you about several different possibilities to figure you out. That's the opposite of assuming. "Your apathy" was conditional, based on the previous question.
> I'm disappointed, to be sure, but no amount of whinging, no matter how vociferous, is going to change this, so I'm pragmatic about it.
Losing money and being disappointed doesn't sound 'great' to me!
It's also good for performance. The blocking can happen immediately in the browser/network process, instead of waiting for the extension code to run in its own process and tell the network service what to do.
In principle yes. But in practice, we are talking about nanoseconds; and I would very much like to see benchmarks/measurements showing anything that can be perceived by users. Also, this blocking cost is still orders of magnitude lower than network latency and blocking requests (even with a slow adblocker) will result in a noticeable performance boost while browsing the web.
This comparison is only apples to apples if exact same content can be filtered. If you lose some filtering due to the added restrictions on blockers, the page may load more resources (in particular, javascript), easily negating any CPU performance benefit.
The situation with Chrome is actually even more misconstrued than that, since ad-blocking performance isn't the only, or even the most important, issue Chromium is dealing with in Manifest v3. Chrome extension security has become one of the biggest time sucks in corpsec/IT security, and that team had been planning for years to address it. But people have a rooting interest in uBO, so none of that gets out.
Google are between a rock and hard place, for sure!
As someone who isn't a corpsec/IT practitioner, though, breaking uBO is literally the most important impact of Chrome's Manifest v3 for me.
I wouldn't mind if Google incorporated uBO as a first-party component in Chromium while applying the restricted policy to all other extensions! Most purported adblockers are crap, if not malware. Pick the best one and restrict the rest.
Unfortunately, I doubt an advertising company is going to incorporate uBO in the browser they provide for free.
I totally buy that breaking uBO isn't Google's goal for Manifest v3! It just happens as a beneficial side effect.
The actual right fix here is for Google to give a blanket exemption to uBO and to nothing else. That's what security people want them to do. Because the underappreciated problem here is that while uBO is fine, ad blockers in general are security tire fires.
Totally agree that's the right engineering fix! I just don't see it happening for dollar and cent reasons:
> The moral dilemma here seems to be that Google is unwilling to privilege a good-citizen adblocker like uBO over other extensions; they're an ad company and any explicit step towards promoting an adblocker probably is hard to explain at shareholder meetings
It might not be the most important issue in the whole Manifest v3, but it's the only issue mentioned for deprecating the particular API that uBO uses to block requests.
Like many things in technology, there are few write ups explaining this, including the pros and cons, in simple terms that most people can understand. So, people are not well informed.
When they are not well informed they will tend to make decisions based on other things, like their business model. We know that Google makes money displaying ads and has generally soaked up information on people to use for their benefit. Apple has been advocating privacy and makes money selling hardware and services.
If there was an "explain it to me like I'm 5" write up on how the changes to Safari and proposed changes to Chrome would work I could imagine it would help people see something other than the business model.
This isn't a double standard. It's people making judgements on something other than the technology.
Chrome was going to allow only a very small list - that's what people were complaining about. The idea of having a built-in way to specify blocks is fine, it's more efficient anyway.
Safari is by far the best browser on Mac IMO, I’m glad Edge is coming but it has its work cut out to beat Safari on performance, energy efficiency and integration.
Exactly. The whole point of this HN post is that people are annoyed and upset about Safari doing this. Ultimately this and Chrome's potential upcoming changes have driven me back to using Firefox almost exclusively.
Mozilla's statement regarding Manifest V3 hints that Mozilla is likely to follow the same path at a later date. They face the same security and privacy issues surrounding plugins that have driven Apple and Google to make the changes they have.
> We have no immediate plans to remove blocking webRequest and are working with add-on developers to gain a better understanding of how they use the APIs in question to help determine how to best support them.
I don't take from that they will apply it in the future, just they don't want to rule anything out.
