uBlock Origin still works fine in Chromium today. Even if Google were to disallow it and other powerful adblockers, the alternative (similar to content blockers on MobileSafari) is not a serious problem, at least for me. I have Ka-Block! on my iPhone, which blocks ads just fine, despite having a much less powerful interface than uBO.

>uBlock Origin still works fine in Chromium today.

They intended to gimp the API. Not sure if the changes are in effect already though.

>Even if Google were to disallow it and other powerful adblockers, the alternative (similar to content blockers on MobileSafari) is not a serious problem, at least for me. I have Ka-Block! on my iPhone, which blocks ads just fine, despite having a much less powerful interface than uBO.

Good for you. It's not enough for me. I even write my own rules for the sites I visit often.

You can write your own rules for most Safari content blockers. But if I don’t trust websites not to invade my privacy, why would I trust a third party ad blocker that has access to my entire browsing history as opposed to the Apple method where the content blockers just give Safari a list of rules?

That's a very good point, but I have to say ublock origin has done nothing yet to breach my trust.

Don't all ad-blockers work with (regex-like) rule lists these days?

The difference is that ad blockers traditionally intercepted your web requests to block ads meaning they had both network access and access to your browsing history.

Content Blockers in Safari submit a list of rules to Safari and Safari blocks the requests. No third party has access to your browser history.

Note that Safari has added new APIs to allow for a content blocker to regain access to such information if you so choose.

Link?

Not that I don't believe you but I can't find any information

Does that let the extension intercept the browsing history or just allow the extension to get information about a page after the user pulls up the share sheet and chooses to send the page to the extension?

As I understand it, that delegate method is called whenever an extension rule matches something on the page.

That would be amazingly slow to call an out of process function on each match when the page renders. Extensions run as a separate process. I would be amazed if Apple would allow something that inefficient as careful as it is about battery and memory efficiency.

I mean, the Safari application is already doing XPC with the web content process constantly anyways. And perhaps they can batch these messages?

Why would Safari be doing any communication with the content blockers? The content blockers are submitting JSON one time to iOS Safari and aren’t running at all.

The Safari App Extension is running in the background, which is presumably what the process is communicating with.

You’re talking about MacOS and not iOS? As far I know, the only time Safari or any other app on iOS calls an extension is when the user chooses to “share” with that extension

Yeah, I think this API is only available on macOS. On iOS this would require keeping the extension alive in the background, which Apple seems largely opposed to allowing.

That's just macOS, not iOS, right?

I believe so.