Google to restrict adblockers.

Back to firefox it is then :smiley:

9 Likes

Maybe enterprising users can find away around this...you're right that would be called Firefox.

There is still a lot of unclear things here.

  1. Google devs keep saying that all this is just so the "end user" (aka you and me) will have a bigger say in if an extension should go in and read your data and block things. It's clear that part of it is hoping users will freak out and say "no, don't check my data" to uBlock et all BUT they actually sound like if the end user is okay with it, it will work.

  2. Chrome based browsers can opt out of this change. Which means Brave, Opera, Vivaldi, Microsoft Edge etcetera can still have the functionality as it is now

Or Vivaldi, Edge, Opera or Brave, or...

:thinking: Hmm. I am wondering if Chromium will be subjected to the same thing?

Chromium can be looked upon as a Chrome-based browser without any of Google's proprietary software.

But they all use chrome appstore...... (or whatever it is called).

I cannot imagine they have the manpower to fork chromium and keep it going.

Not a matter of forking, as far as I understand it, just a matter of switching a single setting (the same that the enterprise users can flip).

But if the apps are not available? AFAIK side loading is also a problem in chrome based browsers (as in not allowed).

:slightly_smiling_face: In all honesty, Mozilla Firefox is an excellent browser. @BS666 has a valid point; enterprise users can utilize Mozilla Firefox if Google Chrome changes for the worst.

2 Likes

The extensions are not banned, but they won't work as they do now unless given permission (by the end user? Google? Google say "end user", but everyone else assumes Google).

1 Like

It will be interesting to see what they do. I am not sure any of those browsers have the infrastructure to manage their own app store and I am not sure that extension developers will see it as worthwhile. Also, the assumption that it even can be turned off is based on a pretty thin statement.

Of course it will.

What is this based-on? If they remove the API, it seems unlikely the extensions will live on in the chrome app store.

1 Like

As an interesting side note, people may be voting with their feet.
This article: https://www.mozilla.org/en-US/firefox/switch/

5. 	
	Switch from Chrome to Firefox (mozilla.org)
	2554 points by WisNorCan 10 hours ago | hide | 829 comments

2554 points WoW! In 10 hours...

On https://news.ycombinator.com/

Install dnsmasq and use blocklist. If you run your own dns resolver locally (very likely a stub resolver) which refuses to resolve ad servers, who needs addons ?

Alternatively use adguard dns or run your own adguard instance locally if you trust Putin :wink:

1 Like

It's based on the wording: They are painting it nicely, but I can't honestly tell if they're being serious. The wording from the Google dev doing all the interviews says "The API is still there, but big parts of it is blocked to allow end users to get more control over what gets blocked in their data traffic.

The fact that he keeps saying the word "control" makes me think the idea is NOT to block outright permanently, but put an opt-in somewhere. They hope, of course, that people will NOT opt in and therefore allow ads. But he keeps repeating that for the end users this would mean more control, which in turn suggests that the extension would have to ask me if I want it to run, and then work as before.

1 Like

The fallacy in this argument is the base assumption that "end users" want "control". They don't. They want a 1-click easy solution that works. Google's decision is inconvenient for all "end users". It's convenient for Google alone. For their ad revenues and tracking. And they have an incentive to lie about their malpractices to generate more profit.

That, and other well-known-oft-repeated catchphrases like "we are the product", "corporations are evil" etc etc.

p.s. It's good to have control when 1-click solutions don't work for an individual case. That's a different matter altogether. All linux distros have sudo and bash, but that doesn't imply their out-of-the-box installations are malicious garbage.

Oh I am fully in agreement. I am also convinced that they have made the calculation that people will "exercise their control" and therefore allow more ads.

1 Like

It will be interesting to see what they do. I am not sure any of those browsers have the infrastructure to manage their own app store and I am not sure that extension developers will see it as worthwhile.

Opera already runs its own app store. A lot of them are not great, but uBlock Origin, HTTPS Everywhere, and Privacy Badger are all current, usually updated within a few days of updates on Chrome.

Personally I am very interested in where Microsoft goes with this. If they allow adblockers in the new Edge... they might have an edge on Windows, again which they haven't had since IE3.0

This whole thing reminds me of the monkey shines video game companies are doing with micro transactions. "Loot Boxes are provided by us to enhance the player's experience and provide them with choices." It is all corporate BS. What they are doing is protecting their business model of selling adds.

I read somewhere, and if I am remembering correctly, that Google provides over 50% of the ads on the internet, and Facebook covers another 30%. So any form of blocking ads hurts their bottom line.

The thing is, by the number of users who are using some form of ad block, it shows that people feel the number of ads many websites display are out of control. I understand that websites need the revenue from ads to pay the bills, but when ads on your site take attention away from your content, you are using too many.

2 Likes

Your understanding is very different than mine. My understanding is that they are deprecating the parts of the webrequests api that allow blocking or modifying traffic. They are replacing that with a declarative api of some sort. It doesn't mean that you won't be able to have ad blockers any more, it means that those adblocking extensions will have to be re-written/heavily modified to use the new declarative apis. This isn't an extension permissions issue, it is a underlying API issue.

In slightly more plain English, today, en extension can read your requests and do something about it what it seeing. In the future, an extension will be able to tell chromium-based browsers, I want you to block traffic that looks like this rule. That is vastly more limiting. On top of that, there will be a limited number of rules you are allowed to have.

I would speculate this would have the following effects

  • It will increase browser security because it will be much harder to write dangerous/misbehaving extensions
  • It will limit the impact on performance some of these extensions can have(because they won't be able to do as much)
  • It will gimp ad-blockers quite a bit
  • It will more or less eliminate most privacy oriented extensions unless all they are doing is basic blocking.
  • Many development/qa related extensions will no longer be able to have the full functionality that exists today

The reality is, this probably won't have a huge impact on most chrome users. Ad-blockers will still exist, they just won't be as effective. Many people will live with that.

The people who will be hit the hardest by this are the privacy focused individuals. They will likely need to move to something else or find some other way to inspect and block requests.

To me, this seems unlikely. What I would guess they are meaning by control, is that through use of a declarative API, you have more transparency into what the extension is doing. They have been spinning this from the beginning trying to stop the revolt in a small but vocal part of the community.

What a dns blacklist can do is worlds less than what some of the more advanced ad-blockers/privacy plugins can do.

That would still rely on the extension developers to continue to develop extensions that won't work in chrome specifically for the chromium-based browsers. The browser developers would also have to maintain patches for the webrequests API to re-enable functionality. We are a year or more from seeing how this all plays out but it will certainly be interesting.

Of course, all of the above is based on the somewhat limited information we have today and could be totally wrong.

4 Likes