Google Funding Choices


New Member
tl;dr Blocking and at the network level still shows a sticky footer on affected pages. This is due to an inline script that base64-encodes the strings which trigger the functions and message. Adding #%#//scriptlet('abort-current-inline-script', 'atob', '/(?:[A-Za-z0-9+/]{4})*(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)?/') blocks them. However, this solution may be too broad and feedback based on my research is welcome.

Example sites

Steps to reproduce ad/annoyance:
  1. Block and I added these to my NextDNS deny list, but || and || should work in your AdGuard User rules filter.
  2. Visit one of the example sites above.
  3. Note that although the network requests are blocked, a yellow sticky footer appears on the page with the string, "You are seeing this message because ad or script blocking software is interfering with this page." (See example screen shot.)
Searching the page's source code for the string shown in the message yields no matches. Upon closer review of the code, we find an interesting inline script which makes the following call:

(See Source Code screenshot.)
I used a decoder tool to see if I could figure out if the string is readily decoded. It is: it's base64 encoded. The obfuscated code reads:
We're getting warmer.

Examining the inline script some more, we find another base64-encoded string:
You are seeing this message because ad or script blocking software is interfering with this page.
Bingo. We found our annoyance.

A quick source code search shows the obfuscated line is used on at least 263 sites at the time of this post. A diff of the inline code between and shows the base64-encoded string is consistent, despite several differences elsewhere in the scripts (see line 128).

So, how do we block this?

My first thought was to block the top-level call. My search reveals at least 207 sites use window.__475an521in8a__ and 56 sites use window.__d3lUW8vwsKlB__. (Which adds up to 263 total sites, indicating there's probably just the two versions of the inline script.) Sadly, adding #%#window.__475an521in8a__ = undefined; and #%#window.__475an521in8a__ = function() { return true; }; didn't seem to work.

My next thought was to block the method which calls:
So I tried this:
#%#//scriptlet('abort-current-inline-script', 'atob', '/WW91IGFyZSBzZWVpbmcgdGhpcyBtZXNzYWdlIGJlY2F1c2UgYWQgb3Igc2NyaXB0IGJsb2NraW5nIHNvZnR3YXJlIGlzIGludGVyZmVyaW5nIHdpdGggdGhpcyBwYWdlLg==/')
That worked! :D

The next question I wondered is whether I could catch all calls to atob() that are base64-encoded. According to the documentation, the abort-current-inline-script scriptlet allows a regex as a search parameter. After finding a suitable base64 regex, we arrive at the following solution which covers our bases (no pun intended):
#%#//scriptlet('abort-current-inline-script', 'atob', '/(?:[A-Za-z0-9+/]{4})*(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)?/')
That solves the problem, but I'm concerned that it's indiscriminate given that it blocks any method which uses atob() to decode base64-encoded strings. Feedback about further refining this scriptlet to block only Google Funding Messages is welcome.

P.S. Although the DOM structure is consistent, the class names are not. Targeting the rendered CSS i.e., bottom: 0px; left: 0px; position: fixed; box-shadow: rgb(136, 136, 136) 0px 0px 12px; display: flex; justify-content: center; font-family: Roboto, Arial;, is a potential second approach. Interestingly, the background color is slightly different on different pages, yet renders a shade of yellow and the z-index is greater than 2147483000—at least on my computer.



Filters Developer
Staff member
@ihateads Hi. Please check this rule:
body > div[class][style*="position: fixed; width:"][style*="z-index: 21474"][style*="justify-content: center; font-family: Roboto, Arial;"]
It does not break the script, but more safe and simple than scriptlets.