Proxying Ads and Trackers

We are avid consumers of Pi-Hole, the DNS based ad-blocker, which can run with minimal computational resources. After years of using DNS based ad-blocking, advertisement entities continue to catch on and develop ways to circumvent this simple method for blocking ads. For most of us using any mechanism to block advertisements, when one comes across your screen, or your significant other complains, it’s all hands on deck to understand how to block the offending material.

Some brief background on Pi-Hole – The internet doesn’t need another blog on how to setup/configure/use Pi-Hole, so I won’t be covering that. I did want to hover around the 10,000-foot view just for a minute. In short, DNS is a fundamental technology that translates hostnames [Ex. google.com] into IP addresses [Ex. 172.217.1.33]. Pi-Hole is configured using lists, many of which are constantly curated by the community, and they contain known hostnames that serve up advertising/tracking/analytics. When a client, such as your cell phone, attempts to reach an endpoint on the internet via its hostname, Pi-Hole will respond to this query appropriately by comparing the requested DNS record to the lists previously mentioned. If the requested resource is in the “Blacklist,” Pi-Hole responds back with the address 0.0.0.0, effectively rendering those elements that depend on that endpoint, useless. In this case, the advertisement element would effectively be blocked.

Recently, we have been experiencing particular sites where Google Ads were being served up in iOS apps and websites, leveraging browsers that couldn’t block HTML elements. I am a proponent and regular of the app SmartNews on iOS; hands down, the best news aggregator app on the platform. Stories from Electrek.co commonly appear in my aggregated news feed within SmartNews, and with relative consistency, I consume the material they publish. Electrek.co is a news outlet dedicated to electric transportation and sustainable energy.

As seen above, there is an advertisement served from what looks to be like Google Ads. After looking at the Pi-Hole logs for a couple of minutes and being unsuccessful in finding an offending domain name, I fired up Edgeomium [Dev Channel] on the desktop to look closer at the advertising elements involved. Note that this instance of Microsoft Edge doesn’t have any ad-blocking extensions installed and is still in its default configuration.

After navigating to the relevant article page and right-clicking one of the Google Ads then choosing “Inspect” to bring up the developer tools, I noticed what seems to be a growing and tricky tactic now when serving advertisements. This tactic entirely circumvents Pi-Hole’s ability to interject and prohibit an offending DNS request since the advertising elements, and their dependencies are perceived to be coming from the parent domain, Electrek.co. What I found interesting, was the fact that they are developing circumvention’s specifically targeting DNS based ad-blocking abilities such as those core to Pi-Hole functionality.

Looking deeper into the developer tools console, I noticed that the first attempt to load the advertising elements seemed to be organic, in that it attempted to load them directly from https://googleads.g.doubleclick.net and not via a proxy mechanism.

The fallback in this specific case is to “proxy” the ads. It seems that an HTTP endpoint is materialized on the Electrek.co side, which will serve the content in a proxy like fashion. Note the “Perceived serving endpoint” and the “Actual serving endpoint.” The “src” attribute for the image clearly shows that Electrek.co is the serving constituent. Additionally, note the “data-aproxy-src” attribute which indicates the intended endpoint that contains the relevant content. In this case, its an image of an electric vehicle plugged into a wall charger.

The “Fake” Image Source: https://ww.electrek.co:443/0:aHR0cHM6Ly90cGMuZ29vZ2xlc3luZGljYXRpb24uY29tL3NpbWdhZC84OTc2NTAyNjYyMzQyODIwMzIzL2Rvd25zaXplXzIwMGtfdj

The “Real” Image Source:
https://tpc.googlesyndication.com/simgad/8976502662342820323/downsize_200k_v1
Under normal circumstances when using Pi-Hole, this image object would absolutely be blocked as the domain name would resolve to 0.0.0.0, seen below:

The example above is a single image. Note that the majority of these intrusive advertising/tracking/analytics resources are being proxied. See the numerous scripts which also have proxying attributes added to them in the event they can’t organically load.

In summary, advertisers and website operators will continue to progress towards an unstoppable method for delivering the things the majority of us despise, ADVERTISEMENTS. The mechanism described above will only become more prolific as advertisers will make it very simple if it is not already, to perform this proxying ability.

Additionally, some of the others tactics which I foresee becoming more prevalent are:

• Browsers beginning to tunnel DNS over HTTPS [DoH] (or Operating Systems for that matter)
• Bolstering restrictions on what extensions can and cannot do in the browser context
• Convergence of namespaces to further obfuscate and blur desired content vs. advertising content
• Leveraging WebAssembly [Wasm] potentially rendering content analysis and detection more difficult

For now, I only have the time and patience to just deal with this peeve and method of circumvention. One idea that comes to mind towards a resolution, outside of using a traditional browser with the ability to block elements inline:

• Man-In-The-Middle (MITM) Proxy – I would have to install a profile on iOS for the certificate to be acceptable on my mobile device.