> One advantage this technique provides over ad blocking is that there's no data to be phoned back home. […] But from a privacy perspective, I personally much prefer this technique.

Are you suggesting uBO is sending data “back home”? It doesn't, and this comment is borderline FUD.

If only everyone used uBlock instead of the countless other scammy adblockers with millions of active users, which do not take privacy nearly as seriously. OP also never mentioned uBlock specifically, so I wouldn't be so quick to call it FUD.

Whether or not this is a sufficient solution is one thing, but there are some legitimate problems with the current state of adblocking. Being able to provide a similar solution in a far more limited fashion would be a good thing for users.

Nah, uBO is fantastic. The problem is nearly all other purported adblockers. Some of them are ok/mediocre; most (like most browser extensions) are just outright crap or malware.

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, even if the engineers want to.

They never suggested anything of the sort. That being said, for every uBO that doesn't send that data back home, there are 1000s of "ad-blockers" that do exactly that.

What are you saying is the privacy advantage exactly? Regular adblockers also block requests before they happen - there's no "phoning home."

Browser extensions are executable JS. That is a huge vector for security and privacy issues (you should be extremely selective about which browser extensions you install). This new method is basically a list of regexs that Safari itself runs against the contents of the page. No 3rd party code is executed, so it's not possible for an extension to, for instance, report back on your browsing habits or steal your login credentials.

Poor justification when just about any other extension API is still a gigantic gaping hole.

What "other extension API" is Apple still allowing, making this a poor justification? You might be thinking of Google, which is allowing other gigantic gaping hole APIs while nerfing their content blocking, but Apple is being pretty consistent and doesn't also derive most of their income from advertising.

You are correct, however until Apple relaxes the rule that “[a]pps that browse the web must use the iOS WebKit framework and WebKit Javascript”, they should be held to a higher standard.

Hang on a second, since when are we this paranoid about installing software? I'm capable of deciding whether I trust a browser extension with the privileges I'm giving it, just the same as I'm capable of trusting any of the daemons running as root which could just as easily steal my personal data.

Sure, if all else were equal I guess I would trust Apple slightly more than an open-source extension developer, but all else is not equal - Apple is taking away the flexibility of arbitrary code and dictating that if you want to block ads in the browser then you have to use their regex-based declarative adblock API. I'm surprised to see such a warm reception on HN to a classic Apple "we're taking this away for your own good" kind of move that has historically not been very popular with enthusiasts.

This is a really long-standing battle between user accessibility and user freedom. Any time a software system or platform or OS allows for people to do whatever they want without restriction, you end up with thousands of compromised systems out there. The alternative, in the past, has been to lock everything down unless users go into some kind of "Advanced" mode or "Developer" mode but then users just get tricked into turning that mode on anyways or more advanced users hand wave those restrictions away for less savvy users without explaining any of the implications.

This is the same pattern that happened with IE where users would install all kinds of toolbars accidentally and then get tons of data stolen or when the first iPhone was jailbroken and everyone wanted all the cool jailbreak features. People would jailbreak the phones of their parents, siblings, relatives, friends, etc. without really every explaining what was happening and what the potential pitfalls of that are.

Now, unfortunately, we're at the same impasse with browser extensions. They're super convenient for most people and are widely used but there's another vector of attack for people that aren't as savvy and don't understand the consequences. Especially when it comes to browsing history, payment data, and passwords, it's so easy to compromise a system now when you can hide it in something like a browser extensions.

The real answer is to do a better job educating people about what everything is but no one wants to do that. More skilled users just want to bitch about what gets taken away from them personally without acknowledging the giant elephant that is ignorance. There is so much advanced technology out there now that people don't even understand the consequences of the most mundane actions.

In my opinion, Apple's trying to do something about that even if it comes at the expense of a few power users losing some conveniences. If their past history is any indicator, they will bring back or improve up on this functionality so that power users get it back somehow but, in the meantime, the bigger and more pressing issue is what takes precedence.

There might be technical reasons why browser extensions are particularly problematic and it might make sense to phase them out in their current form, so, to be clear, that's not what I'm getting hung up on. But there seems to be a broader acceptance of Apple's vision for a nice walled garden where users are safe from everything, especially themselves, and criticisms of this are just "bitching" from people who need to see the bigger picture. I'm sorry but I don't accept that.

Mobile is the primary user environment for a whole generation of kids and millions of people coming online in developing countries around the world. What we're bequeathing them is worse than anything in early-2000s Slashdot's worst paranoid nightmares. Billions of iPhones only load OS images signed by Apple and jailbreaks are aggressively patched as urgent security issues, guaranteeing vendor lock-in. Third-party code is too dangerous so users have to get it from a vendor-controlled app store and sideloading is forbidden for security reasons. You can't have browser extensions because they can see too much, so now you have to hope that Apple implements an API for whatever you were trying to do. There's a weird double standard where the tech literati are fine with things on mobile that they would never accept on their desktop. I guess it's because we have the luxury of putting our phones away and retreating to our "real computers" to scratch our tinkering itch. Not everyone has that privilege, or inclination. If the freedom to tinker means anything to you then mobile shouldn't be an exception.

I don't think the walled garden is even necessarily good for the ill-informed or careless users we're trying to protect. Checking out the "Advanced" mode is how users learn. While it may be dangerous for a casual user to be able to run a command or make a tweak they found recommended on some website, it also can be incredibly helpful - software doesn't always work correctly or the way that you want it to, and there's not always a nice button that does exactly what you need. And there's a real danger of the browser and the other public API surfaces calcifying to only permit what Apple thinks about ahead of time, smothering innovation that could have genuinely benefited users. Imagine if computers followed this philosophy from the beginning. I doubt users would enjoy an app store where user input (text only, of course) is sent securely into the app's stdin and output is text fed securely from the app's stdout to the screen, with no interference permitted by potentially insecure code attempting to provide things like scrollback because it could see all of the user's activity.

So yes, protecting users from the worst malware can be a thing but it's not as obvious as you make it sound that this should necessarily entail removing agency from the user. By aiming for the lowest common denominator user, Apple is depriving everyone else of real advantages. And, I would argue, producing a sterile and stilted experience that's best for no-one.

Indeed, only Safari will have the right to report back on your browsing habits under the name of telemetry or steal login credentials or whatever fear you can imagine.

I don't really care, I don't use Apple products and I still have Firefox, which will happily let me shoot myself in the foot on this (for now). You know what else is a "huge vector for security and privacy issues"? Every program I install through my package manager, or other source. The solution isn't to cripple the OS so that only my distribution vendor can run certain kinds of software and no one else.

Browser extensions are becoming a notable security vulnerability, with many high profile extensions falling into the hands of (or being sold to!) bad actors. The arbitrary code execution method of ad blocking (e.g. uBlock) is very flexible but it means that without ongoing comprehensive code review using one puts you at risk if the extension ever changes hands or has a backdoor added.

Apple's method avoids this issue by never letting the extension see the page contents, it only provides match lists of what to block that the browser then enforces. Even if the extension became malicious it has no access to private data on the webpages it is ad blocking on.

What I think they're saying is that with Adblockers, they can phone home which ads they block, URLs they see, etc.

Content blockers impose rules at the outset and the rule generator won't see what the URLs/content actually is.

The way I would think of it would be like "let me see what you're seeing and I'll let you know what to let through" vs "here are a list of things you shouldn't let through but I don't need to know about what the hit rate actually is".

Although I could be misunderstanding the implementation.

While true with some, I believe uBO is a list implemented client-side, right? Other ad-blockers can and do phone home and let through ads that have paid, but uBO just has the EasyList filter installed locally and blocks those URLs. That was my impression at least, I never personally went through the source code.

I trust uBO and roughly zero others. In fact, uBO has to remind people at every opportunity to avoid certain others. It is all the others, now and in the future, that are prompting Apple to do this, and the one well-behaved extension is unfortunately suffering as a result.

I mourn the loss of uBO, but I'll take that tradeoff knowing that I can relax knowing that my family and friends aren't going to end up using some intrusive nightmare of an "ad-blocker" with Safari.

This is exactly it. Even if a malicious extension gets through, they have access to nothing on the user side. It's not a fair trade off but, in my opinion, it is a worthwhile one.

> That was my impression at least, I never personally went through the source code.

That's the rub though. There's nothing but trust preventing them from including some spyware in the next automatic update. Actually not even trust, whoever has account access to publish for uBlock could have their account hacked and someone malicious could inject spyware into a version of the extension.

Trust is everywhere in computer security. You trust Google to not deliver a backdoored version of Chrome to your machine when you download a binary instead of building from source. You trust them to not break the law and leak your personal data to third parties or discriminate against you based on the content of your emails.

I trust Raymond Hill more than I trust Google.

This isn't as much about what existing extensions do today but all about what potential extension could be doing tomorrow.

If an extension doesn't get full access to all the pages you are reading, it can't do bad things with that access when the extension's owner inevitably changes (see the fight between uBlock and uBlock Origin for example) and spyware features are added.

Even if it is, it doesn’t matter. The problem Apple faces is how to prevent the other bad actors from abusing their API. The answer they’ve settled on is remove those capabilities from the API. Another answer would be to leave the capabilities but somehow only grant access to them to “trusted” parties.

I’m sure that would have gone over really well, too. /s

In the later scenarios, what assurance does the Ablocker have that their requests are respected? I could easily see a scenario where an Adblocker says "Hey Chrome block all requests to ads.google.com" and Chrome saying "Sure thing buddy" then completely ignoring that request.

The same assurance you have that the browser wouldn’t simply inject its own ads into all pages.

There's really nothing at all preventing Chrome from doing that today if they wished... they can manipulate the page before and after the Adblocker sees it.

SHHH!!! That's for Chrome 100 ;P

I agree it's totally possible they would do that, but one could figure it out pretty easily with a touch of detective work.

And then what? Google will say that it's protecting critical functions from breaking and to piss off. Suddenly Google is a monopoly in the ad space because they have the predominant browser and let through only their ads.

they arguably are effectively a monopoly now. Them doing things like this isn't remotely new. They just got caught tracking everyone's smart TV usage. Nothing will happen to them until:

1) the Government decides to intervene.

2) Users give up and start using different services.

I'm pushing for #2, but then I switched off like a decade ago, when I saw the writing on the wall.

Were they tracking smart tv usage or were smart tv manufacturers using google apis to store their tracking data?

Both it seems:

"The most prevalent tracker, Google's doubleclick.net, showed up in 975 of the top 1,000 Roku channels, with Google analytics trackers showing up in 360, the researchers found." - https://arstechnica.com/tech-policy/2019/09/studies-google-n...

Adblocker apps/extensions don't require that assurance. The user requires this assurance, and if the browser ignores the user's wishes, the browser is the application that should be held accountable by users.

How is the user to know if it's the AdBlocker or the Browser though? It's a he-said-she-said kind of situation with the AdBlocker and the Browser potentially pointing the finger at each other.

This setup gives the Browser/Maker plausible deniability when they act badly.

Browsers and extensions aren't black boxes; it's easy to inspect them for this kind of behavior.

This model is also a big performance win. The content blocker rules are compiled to an [efficient byte code format](https://webkit.org/blog/3476/content-blockers-first-look/) which can be evaluated insanely fast (microseconds not milliseconds), compared to doing IPC and running JavaScript for each resource in a page.

Which is same as banning ad blockers. With the declarative API you can't know what domains this website connects to and you can't prevent it from connecting to bad domains. Moreover, trackers and ads can choose a random domain to completely avoid any blacklists.

The content block lists will get updated frequently just like the ad block lists. And, sure, it’s a cat and mouse game just like it is with the add blockers. But at least this way is more performant and secure.

In the end, as has been said by others, if you don’t like it then use Firefox. That’s what’s great about the browser ecosystem we have right now. There are some really great options in browsers.

It's one cat and millions of mice that multiply rapidly. Ads networks that use random unpredictable domains are intractable by the static blacklist approach. Not only that: ads networks can watch the public blacklist and adjust their domains accordingly. If declarative API was about security, Apple would rather block network access for adblockers.

Agreed about Firefox. My goal here is to call out the hypocrisy of the declarative API. So I want to repeat myself that the declarative API is about giving ads networks an easy way to not get blocked, while using performance and security as false arguments that impress only those who know nothing about performance and security.

You know; I just realized I should clarify some confusion I myself may have introduced here. My original comment suggests the trigger is always matching a domain regex but domain isn't the only trigger. Content blocker authors can make use of one or more of seven different triggers. For example:

    `load-type`: An array of strings that can include one of two mutually exclusive values. If not specified, the rule matches all load types. `first-party` is triggered only if the resource has the same scheme, domain, and port as the main page resource. `third-party` is triggered if the resource is not from the same domain as the main page resource.

So our concerns about the cat and mouse game is true, but only for domain triggers.

Actually, I've been using content blockers on iOS and I haven't noticed any ads coming through. That's not to say they won't/don't ever but my browsing experience is noticeably smooth on that platform.

As a happy Firefox and uBlock Origin user I wonder what is so fundamentally different about uBlock Origin that its filter list can't be converted/translated to the JSON format Safari's content blocking API expects.

Is it more difficult than I imagine?

OK any argument in favor of this technique shatters in front of the fact that in practice, Ad blocking on iOS is useless, and requires more resources, since some older devices still cant use it.

If they really care about privacy, they can just whitelist uBO/uMatrix and everyone will be happy.

Wouldn't you prefer if both options were available?

I certainly would. I had been using Safari on mac only because it was fine and I had no need to switch to firefox or chrome.

Now I will definitely not be using safari anymore.

What content blocker would you recommend?

Apple themselves recommended Ghostery Lite. I feel like that one had some trouble in the past but I can't recall why. Regardless, I installed it and Magic Lasso to see how they do. I used to use Wipr with some success but it appears to be no longer free. Still, if Ghostery Lite and Magic Lasso don't work out, I'll pony up for Wipr.

I gave Ghostery Lite and Ka-Block! a shot and they blocked ads on most sites except for reddit. Pretty good for free.

Wipr blocks the same ads as the above combo, but also blocks those on reddit.

YMMY

This is exactly what Chrome intends to do and everybody hates Google for it. Defending this when Apple does it is a double standard.

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.

So enforce human reviews for any update to extension with "read all requests" permission and over X users.

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.

I don't see much value in ecosystems that where only one party can build powerful tools

I don't think "ecosystems" are a priority in and of themselves for Apple.

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.

This should be the top comments, thanks for taking the time to write it out

Plus, Chrome only plans to disable the blocking functionality of webrequest, not the monitoring part.

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.

> totally believable because it's in line with the last 10+ years of their product direction.

yet they have shitware called uBlock that's there intended to confuse them with ublock origin, just sitting there in app store...

How is that related to Apple’s product vision at all?

It flies in the face of the "curation" and "privacy" arguments.

> 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.

Using theit browser, you are already trusting them. If they wanted to spy on you in Safari, they would regardless of content blocking.

"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.

https://twitter.com/gorhill/status/1134127701583904770

The two complaints are valid.

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:

https://developer.chrome.com/extensions/manifestVersion#mani...

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.

That argument was lost 11 years ago when the iPhone came out, and yet, people still can't get enough of them.

> 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.

Well, they're not exactly of the same mind.

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.)

I can't follow your reasoning. How does Google's business model justify allowing 3rd party Chrome extensions to snoop on user traffic?

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.

> extensions can’t block requests based on these observations

The new API is called "declarativeNetRequest" and allows extensions to block requests: https://developer.chrome.com/extensions/declarativeNetReques...

"There are the following kinds of rules:

* Rules that block a network request.

* 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."

(Source: https://docs.google.com/document/d/1nPu6Wy4LWR66EFLeYInl3Nzz...)

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.

I rest my case.

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.

I'm sorry, are we seriously pretending that the "inefficient rules" aren't going to just happen to be the ones that affect Google ads?

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.

It's easy to verify that this is completely not the case. Safari allows 50,000 rules [1]. Chrome allows 150,000 [2].

[1] https://help.getadblock.com/support/solutions/articles/60000... [2] https://blog.chromium.org/2019/06/web-request-and-declarativ...

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.

"Exactly." "Everybody." "Hates." Bonus: "You are an ethic-less hypocrite."

Look no further for why our society is having such trouble coming to any sort of agreement on issues that matter.

I read the GitHub post yesterday, immediately bought 1Blocker, and moved on! (And it's been great!)

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.

It certainly does not take merely nanoseconds to wait for JS to run in another process.

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

https://news.ycombinator.com/item?id=21032698

Or they could apply some level of moderation to the web store, like Mozilla has done.

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.

It's not exactly a double standard because...

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.

From OP's argument, it seems likely they'd support Chrome doing the same thing.

A double standard requires the same person or population to hold logically contradictory viewpoints. That isn't what is happening here.

Maybe, but Apple has less of an incentive to deliberately misimplement it since they don't earn huge amounts of revenue from ads.

Not through lack of trying. It's just that iAds was unsuccessful.

Apple isn’t anti-advertising or pro-advertising, but it is pro-privacy. iAds failed because Apple refused to allow invasive tracking.

Google is an Adtech company.

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.

Google makes almost all of their money through ads...

But then even Mozilla makes most of their money through Google.

There’s no double standard. Everyone hates Safari for this too… all the 500 users of it.

Of course you’ll hear a lot more noise from the users of the browser with the larger share by a wide margin.

Estimates for Safari marketshare range from 15.15 - 24.9% across all platforms [0]

[0] https://en.m.wikipedia.org/wiki/Usage_share_of_web_browsers

A better sentence: the median estimate for Safari's desktop market share is 5.12%

>desktop

Why does narrowing it to desktop devices matter?

HMU when you install uBlock Origin on your iOS version of Chrome

I don't have iOS so i'll take your word for it.

Because Apple doesn't allow any other browser engines on iOS. iOS users are shackled to Webkit, and are unable to make a choice.

I think they're talking about Desktop market share where Safari has very small usage.

Interesting. I see about the same on the web sites that I build.

I assumed it was just a fluke because I'm in the healthcare space, and that means lots of iPads and doctors rocking the latest iOS gear. I guess not.

That includes mobile users.

I’d expect there are about 500 hardcore safari fanbois on Mac but everyone else uses it to download a different browser.

Microsoft Edge is coming to Mac, obviously that’s the future.

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.

source: https://www.ghacks.net/2019/09/03/mozilla-wont-follow-google...