I read the original article back when it was published in November 2020[0]. This is what led me to introduce new static network filter options:

- strict1p, strict3p [1]

- header=, experimental, disabled by default [2]

I used Simo Ahava's blog as test case, and with these new options, I could craft a filter to block the Google Tag Manager script on Simo Ahava's blog. However due to the lack of more test cases, no more progress has been made about this since then.

Things that stood out to me when reading about all this:

Simo Ahava's refers to the CNAME approach as "vulnerable"[3]:

> This way you’ll be instructed to use A/AAAA DNS records rather than the vulnerable CNAME alias

"Vulnerable" to what? To uncloaking as I understand it, and by extension, "vulnerable" to users taking steps to protect their privacy.

Whether the very experimental solution in uBO ends up working or not, this case shows very well how Google Chrome's Manifest Version 3 (MV3) put a lid on innovation content-blocking wise: All the new filter options introduced above can't be implemented with declarativeNetRequest.

===

[0] https://www.pixeldetracking.com/fr/google-tag-manager-server...

[1] https://github.com/gorhill/uBlock/wiki/Static-filter-syntax#...

[2] https://github.com/gorhill/uBlock/wiki/Static-filter-syntax#...

[3] https://www.simoahava.com/analytics/server-side-tagging-goog...