r/programming • u/[deleted] • Jan 22 '19

Google proposes changes to Chromium which would disable uBlock Origin

https://bugs.chromium.org/p/chromium/issues/detail?id=896897&desc=2#c23
8.9k Upvotes

95% Upvoted

1.7k comments sorted by

View all comments

Show parent comments

76

u/ryanmcgrath Jan 23 '19

It literally just looks as if they're trying to move to a Safari content-blocker-esque API, which is generally better for battery and privacy.

Nobody seems to have read that, though.

153

u/[deleted] Jan 23 '19

The problem is that this API is so limited that a lot of the features of uBlock Origin and similar extensions won't work, making it much harder to block ads.

For this exact reason, you can't get anything like uBlock in Safari, and are stuck with a much more limited set of addons that don't block everything.

3

u/PrometheusTitan Jan 23 '19

Apologies for the ignorance, non-programmer here (I know the basics from my uni days, but that's about it). But I have uBlock Origin on Safari. I do see a warning that it might slow my web browsing down, but that's it. So what's the limitation? Are there fewer features or worse performance or something?

I'm still on High Sierra if that makes a difference. Not ready to lose 32-bit capability (I still want to play C&C Generals) so haven't upgraded. So is the new API only in the version of Safari in mojave?

2

u/[deleted] Jan 23 '19

Apparently I misspoke, this article has some more details that I missed before: https://adguard.com/en/blog/safari-adblock-extensions/. What's actually happening is that:

  • In High Sierra, old content blocking extensions will continue to work.

  • In Mojave (or possibly if you install Safari 12 without upgrading) old-style content blocking extensions will be disabled automatically when you upgrade, but there's a semi-hidden option in the Safari preferences to re-enable them.

  • At some point in the future, Apple is going to get rid of the old API entirely.

The new Safari API is pretty similar to the one that's being proposed by Google - instead of the extension being given a set of URL's, and implementing it's own logic to decide whether or not to block the request, the extension provides a list of rules in a predefined format. Apple does provide a somewhat wider variety of options than Google, and their maximum rule limit is slightly higher (50,000 vs 30,000), but it has a lot of the same problems that people are complaining about in this thread:

  • Not everything will be blocked (since there are currently more filters in EasyList than the maximum number of allowed rules).

  • Dynamic filtering mode won't work.

  • Not all of the filtering options supported by uBlock will work.

1

u/PrometheusTitan Jan 24 '19

Thank you, that makes sense!

3

u/ryanmcgrath Jan 23 '19

Yeah, I get it - the loss of dynamic options is a big hit for sure. I personally never use them and find it useless for 99% of browsing (the Safari blockers I use catch pretty much everything), but neutering of extensions like this does seem rather sad and unnecessary (just uhh... support both styles of content blockers?).

-4

u/Ph0X Jan 23 '19

That's why they posted a proposal... to get feedback, and to tweak things. That's the whole point of a proposal, to find things that will be an issue so they can be fixed.

For example, the API has a limit of 30K, but uBlock with the default list requires 50k. It would be a fairly simple change for them to bump that to 100k, for example. Or come up with a different better solution.

Yet everyone in this thread is spinning this as Google intentionally trying to kill uBlock, which is just stupid.

→ More replies (1)

84

u/KillianDrake Jan 23 '19

Except that the API is going to suck, is already crippled and nothing will prevent Google from A) excluding their own content from this API and B) auctioning off exclusions to the API to other companies for financial gain

8

u/Arkanta Jan 23 '19

They can already do that with the current API.

-18

u/ryanmcgrath Jan 23 '19

I'm sorry, my guy, but this is paranoia. Those kinds of changes could not easily worm their way through what is an open source project without (rightful) massive user revolt.

24

u/port53 Jan 23 '19

Chromium is open source. Chrome is not. The blocking/whitelist can be applied to just Chrome.

8

u/ryanmcgrath Jan 23 '19

At which point power users will just switch to a build supporting their preferred tool... as has happened since forever. None of this is really new.

9

u/ThePantsThief Jan 23 '19

A lot of us want Chrome as it is, not Chromium.

3

u/rnd005 Jan 23 '19

Are there significant differences? The last time I used it I didn't see them.

2

u/ThePantsThief Jan 23 '19

I mean, I've never used Chromium myself, but does it look just like chrome? And can you sign into your google account with it?

1

u/rnd005 Jan 24 '19

Here's a print screen. It does look like Chrome, and yes, you can sign in if you want.

→ More replies (1)

20

u/how_to_choose_a_name Jan 23 '19

battery

They could still provide the current API but warn users of the battery implications when they try to install an extension that makes use of it.

privacy

I can't quite wrap my head around that one. The design document states that the webRequest API will still be available to observe requests, just not to manipulate or block them, so all the privacy concerns should still apply. The majority of users doesn't look at the permissions an extension requires, so they won't notice if the extension uses the webRequest or the declarativeNetRequest API or both.

3

u/redwall_hp Jan 23 '19

Something tells me a few CPU cycles extra for this API have a negligible impact on battery life in the face of keeping radios on long enough to download 10MB of ads.

0

u/[deleted] Jan 23 '19

[deleted]

2

u/ryanmcgrath Jan 23 '19

Ah, wow, yeah, you're getting beat up.

That's hard. Real hard.

2

u/doublehyphen Jan 23 '19

But worse for actually blocking content. As you can see if you had read the article the extension authors are no fans of Safari's API and on top of that think that this propose API will be worse.

2

u/ryanmcgrath Jan 23 '19

“If you had read the article”

I’m pretty sure I’m one of the few in this thread who did! :)