Here comes the Google Chrome change that worried ad blocker creators

oldschool

Level 81
Verified
Top Poster
Well-known
Mar 29, 2018
7,044
I think he's wondering if MS Edge will follow Chrome and implement V3 immediately.
This is precisely what I was referring to, i.e. their position about V3 and adblocking extensions. I realize that M$ controls what gets built into the browser and V3 would never impact its adblocker. Here is one post from M$ re: V3 Manifest V3 changes are now available to test in Microsoft Edge. It states, in part:
We recognize the value of content blocking extensions and appreciate the role they play in honoring user’s choice by blocking advertisements and enhancing privacy by blocking cookies and we want developers to continue to offer these capabilities. After an extensive review of the concerns raised by content blockers and the community, we believe that a majority of those concerns have been resolved or will be resolved before Web Request API is deprecated. If you continue to face issues, we encourage you to share your feedback, where our team can engage to understand and address your feedback.
You can find other 3rd party posts about M$, none of which I'm aware of that provide any more clarity about their plans. Their position is unclear about whether they will fully implement Chrome's new restrictions. Brave has its built-in adblocker but even they are not clear about the future of adblocking extensions, unless I've missed something.
And there is this Chrome 88 will prevent Ad blockers from working, but Vivaldi and Brave will resist where the author makes this argument without any source for this belief, other than the logic of development costs:
Edge already allows testing the Manifest V3 feature, so it will follow Google with this move. Vivaldi and Brave, two Chromium based browsers, won't enable Manifest V3 as long as they can. However, I doubt that this will last for long. It will require extra cost for them to keep the Chromium code base unlinked from the mainstream.
 
Last edited:

oldschool

Level 81
Verified
Top Poster
Well-known
Mar 29, 2018
7,044
The big problem for adblocking extensions is that the Static filters can only be updated when the extension is updated.
This is one big problem, but not the only one.
Dynamic filters can be updated and used over sessions, but the problem is that they are limited in numbers (less than 5000 when I recall correctly)
But no Noop rule alone will ruin dynamic blocking. From my earlier post, Gorhill states:
However, it's still not possible to implement noop rules, which purpose is to ignore inherited block/allow rules and fall back strictly on static filters, and which is a key concept to dynamic filtering. Summary, latest version of declarativeNetRequest, as per documentation, still breaks dynamic filtering in uBO, due to the inability to implement the noop concept. Suggestions welcome if somebody can think of a way to implement noop rules which I am not seeing.
 

silversurfer

Level 85
Verified
Honorary Member
Top Poster
Content Creator
Malware Hunter
Well-known
Aug 17, 2014
10,057
Adguard DNS and probably also Next-DNS, both does the work to hide the majority of ads on websites, I tried on both Edge and Firefox.
That's just in case of any adblocker browser extensions doesn't work anymore due to Manifest V3, or users won't using software like AdGuard for Windows.

Hopefully, developers of browsers extensions/addons will be able to create a more user friendly solution to block ads as always been the case, we will see...
 
F

ForgottenSeer 92963

@oldschool

Although Google and Gorhill both use the same description, the static and dynamic rules of Google are not the same as the static and dynamic rules of Gorhill.

:)

Google has added CSS and Script rules, but in a different way they are now. So people telling all will be implemented eventually are right and wrong. Right in the sense that a similar mechanism will be available. Wrong in the sense that current adblock developers think it is a not implementation the way they wanted.

As stated by AdGuard, you should rethink how content blocking will be implemented.

Static rules: third-party blocking with a limited number of rules only targeting the most used ad and tracking networks (like Disconnect, Ghostery and my EU_US most used).

Dynamic rules; used for overrides and allows to solve false positives and website breakage at first-party level).

Advanced Script and CSS rules to deal with advertising and tracking circumventing the static rules (e.g Admiral and Youtube advertising) and some common annoyances (e.g. Google consent).
 
Last edited by a moderator:

oldschool

Level 81
Verified
Top Poster
Well-known
Mar 29, 2018
7,044
@oldschool

Although Google and Gorhill both use the same description, the static and dynamic rules of Google are not the same as the static and dynamic rules of Gorhill. Google has added CSS and Script rules, but in a different way they are now. So people telling all will be implemented eventually are right and wrong. Right in the sense that a similar mechanism will be available. Wrong in the sense that current adblock developers think it is a not implementation the way they wanted.
You are probably correct and I don't understand all the coding details (of the differences) in how they are using terminology.

Gorhill has posted these initial thoughts, indicating he will need to seriously re-invent µBO so it might function under V3 declarativeNetRequest.

gorhill commented yesterday •​

edited​

However, it's still not possible to implement noop rules
It might be possible to maybe implement noop rules through complicated negative lookahead regex-based filters. For example:
* * 3p-frame block
* * 3p-script block
github.com amazonaws.com * noop
github.com githubapp.com * noop
github.com githubassets.com * noop
github.com render.githubusercontent.com * noop

Maybe could be achieved with:
*$thirdparty,script,subdocument,domain=~github.com
/^[\w-]+:\/\/(?!(\S+\.)?amazonaws\.com\/|(\S+\.)?githubapp\.com\/|(\S+\.)?githubassets\.com\/|(\S+\.)?render\.githubusercontent\.com\/)/$thirdparty,script,subdocument,domain=github.com

This is only for medium mode with configuration for one single site. I wonder how this would look like for my current ruleset of 391 rules.
Again, as per declarativeNetRequest documentation, regex-based filters are limited to 1000 (and also as per declarativeNetRequest, a regex-based filter can be rejected).
And each time one would click to create/remove a temporary rule as is typically often done when working in medium or hard mode, uBO would have to recompile, remove and reinstall all the dynamic rules.
On the other hand, uMatrix does not require the concept of noop, and the priority property should allow the implementation of its matching algorithm.
In the end, only an actual prototype will be required to sort out for sure what is possible or not.
It doesn't look like it will be easy ...
 
Last edited:

plat

Level 29
Top Poster
Sep 13, 2018
1,793
It doesn't look like it will be easy ...
Well this is the commentary I was sort of waiting for and didn't have to wait for very long once the news of the Manifest v. 3 timeline broke.

gorhill says he needs a prototype on which to (re) build his content blocker and for that he has to wait. So we wait. Hopefully, it turns out we've been making a much bigger deal out of Manifest v. 3 than how it will actually turn out. But somehow, my gut feeling is: like Microsoft and Windows 11, Google probably ain't gonna budge much. Monopolies have greater degrees of freedom that way.

We'll see.
 

SpiderWeb

Level 10
Verified
Well-known
Aug 21, 2020
468
We need a mass migration back to Firefox. Google is clearly abusing it's dominant position to force everyone to consume the Internet their way. I switched to Firefox this week. It has all the Chrome extensions including some Google banned because of the way they blocked ads.
 

silversurfer

Level 85
Verified
Honorary Member
Top Poster
Content Creator
Malware Hunter
Well-known
Aug 17, 2014
10,057
When you are going to setup Adguard DNS, then all ads are blocked to be hidden, the difference compared to adblocker browser extensions are able to remove all blank spaces where ads are placed on websites. Of course, it's not like a real user friendly solution, but at least it works in this way that ads are invisible...

I believe that even other chromium-based browser like Edge, Brave, Opera, Vivaldi, all have to support Manifest V3 sometime in the future, probably the same happens for Firefox at least a few years later than 2023. We will see, now it's too early to be sure ;)
 

Gandalf_The_Grey

Level 76
Verified
Honorary Member
Top Poster
Content Creator
Well-known
Apr 24, 2016
6,506
Mass migration to Firefox won't help because according to the links @rain2reign posted Mozilla will also be changing the way how extensions work:
What is the timeline for these changes?

Given Manifest v3 is still in the draft and design phase, it is too early to provide a specific timeline. We are currently investigating what level of effort is required to make the changes Google is proposing, and identifying where we may depart from their plans.

Later this year we will begin experimenting with the changes we feel have a high chance of being part of the final version of Manifest v3, and that we think make sense for our users. Early adopters will have a chance to test our changes in the Firefox Nightly and Beta channels.

Once Google has finalized their v3 changes and Firefox has implemented the parts that make sense for our developers and users, we will provide ample time and documentation for extension developers to adapt. We do not intend to deprecate the v2 API before we are certain that developers have a viable path forward to migrate to v3.

Keep your eyes on the add-ons blog for updates regarding Manifest v3 and some of the other work our team is up to. We welcome your feedback on our community forum.
 
F

ForgottenSeer 92963

Adblocking on DNS level can only block resolve requests (find an IP adres for this URL domain), it can't modify CSS styling, can't strip/redirect elements out of HTML and can't inject javascript.

DNS level adblocking really is no alternative for content filtering with extensions. DNS adblocking is using a mechanism to block bad URL's used for malware, phising, command & control servers.

The reverse is also true, malware blocking using local URL blocklists is also silly (covers at best 1 percent of the blacklist used at DNS and Antivirus Companies have in the cloud).

Malware URL blocking with local URL blocklist in your adblocker is like using a speed boat for world wide cargo transport.

When a DNS blocks a request to a bad URL, the intended use is to break the (malware) delivery chain. It is all or nothing. It is a sledge hammer compared to the tweezers of adblock rules

Just open Easylist filter and search for @@ (allow exception) and 'important' (giving priority to a block rule over an allow rule) or 'third-party' (block as third-party, allow first-party). And these three examples are the easy ones, this are not the cosmetic rules or advanced CSS, HTML and javascript(let) rules I mentioned earlier.


PS
I am using DNS level blocking of advertisement for my android TV box (because that is the best I get for free on that device).
 
Last edited by a moderator:

plat

Level 29
Top Poster
Sep 13, 2018
1,793
We are jumping the gun a little bit. Reality: we end-users can't do anything right now. A prototype isn't even available yet for developers to examine.

This doesn't look good--probably most if not all browsers will follow Google's lead. The question is: to what extent? The actuality of Manifest v.3 is supposedly 1 and 3/4 years away. It's like preparing for a hurricane that hasn't formed yet.
 
F

ForgottenSeer 92963

This are the three main issues extension writers have with Mainfest V3 (at this moment).

1. For general purpose adblockers like uBlock, AdGuard and AdBlockPlus the update of the different filter types (static, regex, script, css) has to be allowed by Google, without the need of updating the extension.

2. For advanced content filtering some sort of ignore for the dynamic rules (uBO's noop short for no operate meaning ignore and do nothing) has to be facilitated by Google.

3. The current AdBlockPlus syntax as we know it now (with all sorts of rules combined in one list) will probably have to be split and rewritten into different type of rules (grouping all blocks into static filters, allow overrides in dynamic filters and the advanced CSS, javascriptlet and regex rules each in their own seperate filterlist). This will require a lot of work (and some learning/getting used to) for list contributors.

Google has listened to the critism of extension programmers, but until now they implemented improvements not how the extension programmers wanted it. There is still time and room for improvement, but my take on it that it is 50/50. In 1,5 years from now we might say it was a storm in a glass of water or we settle for sledge hammer like adblocking on DNS level combined with browser build-in adblocking and a few website specific adblockers (e.g for Youtube, Tiktok, Facebook, Twitter and Instagram).
 
Last edited by a moderator:

oldschool

Level 81
Verified
Top Poster
Well-known
Mar 29, 2018
7,044
In 1,5 years from now we might say it was a storm in a glass of water or we settle for sledge hammer like adblocking on DNS level combined with browser build-in adblocking and a few website specific adblockers (e.g for Youtube, Tiktok, Facebook, Twitter and Instagram).
Indeed. It's too early to get too worked up about this but not too early to be monitoring developments, etc.
 

About us

  • MalwareTips is a community-driven platform providing the latest information and resources on malware and cyber threats. Our team of experienced professionals and passionate volunteers work to keep the internet safe and secure. We provide accurate, up-to-date information and strive to build a strong and supportive community dedicated to cybersecurity.

User Menu

Follow us

Follow us on Facebook or Twitter to know first about the latest cybersecurity incidents and malware threats.

Top