I have a love-hate relationship with ad blockers. On the one hand, I despise the obnoxious ads that are forced down our throats at what seems like every turn. On the other hand, I appreciate the need for publishers to earn a living so that I can consume their hard-earned work for free. Somewhere in the middle is a responsible approach, for example the sponsorship banner you see at the top of this blog. Companies I choose to partner with get to appear there and they get themselves 140 characters and a link. That is all. No images. No video. No script. No HTML tags. No tracking. Sponsors are happy as they get exposure, visitors are happy because there’s none of the aforementioned crap and I’m happy because it pays a lot better than ads ever did anyway. It almost seems like everyone is happy. Almost…
As I wrote about a couple of years ago, ad blockers aren’t always happy and frankly, attitudes like that just make the whole ad problem even worse. That post attracted hundreds of comments ranging from “I don’t mind ads” to “burn them all with fire and the consequences be damned”. But it’s not just the detrimental impact of blocking the very source of a website’s revenue that worries me, it’s also the fact that running an ad blocker means giving a third party an enormous amount of power over your browser. This creates a different risk to ads themselves – a much more serious one if it comes to fruition – and it looks like this:
Do you use a popular browser extension? How confident are you that the creator wouldn’t accept a $10k offer to hand it over only to have it then go rogue on you? https://t.co/hPfW5CJLUz
— Troy Hunt (@troyhunt) September 5, 2018
That’s actually my top tweet over the last 4 weeks by a significant margin because it’s one we can all relate to. I certainly went back and revisited all the browser extensions I had installed and killed a few unnecessary ones. Bottom line is that you really want to consider how much you trust the organisation (or in many cases, the person) behind the extensions you run and even when you do, there’s no guarantee it won’t be backdoored MEGA.nz style.
Which brings me to Pi-hole. I’m going to keep the intro bits as brief as possible but, in a nutshell, Pi-hole is a little DNS server you run on a Raspberry Pi in your local network then point your router at such that every device in your home resolves DNS through the service. It then blacklists about 130k domains used for nasty stuff such that when any client on your network (PC, phone, smart TV) requests sleazy-ad-domain.com, the name just simply doesn’t resolve. Scott Helme put me onto this originally via his two excellent posts on Securing DNS across all of my devices with Pi-Hole + DNS-over-HTTPS + 126.96.36.199 and Catching and dealing with naughty devices on my home network. Go and read those because I’m deliberately not going to repeat them here. In fact, I hadn’t even planned to write anything until I saw how much difference the service actually made. More on that in a moment, the one other bit I’ll add here is that the Raspberry Pi I purchased for the setup was the Little Bird Raspberry Pi 3 Plus Complete Starter Kit:
This just made it a super easy turnkey solution. Plus, Little Bird Electronics down here in Aus delivered it really quickly and followed up with a personal email and a “thank you” for some of the other unrelated stuff I’ve been up to lately. Nice 🙂
I went with an absolute bare bones setup which essentially involved just following the instructions on the Pi-hole site (Scott gets a bit fancier in his blog posts). I had a bit of a drama due to some dependencies and after a quick tweet for help this morning followed by a question on Discourse, I was up and running. I set my Ubiquiti network to resolve DNS through the Pi and that’s it – job done! As devices started picking up the new DNS settings, I got to see just how much difference was made. I set my desktop to manually resolve through Cloudflare’s 188.8.131.52 whilst my laptop was using the Pi-hole which made for some awesome back to back testing. Here’s what I found:
Let’s take a popular local Aussie news site, news.com.au. Here’s what it looks like with no Pi-hole:
In the grand scheme of ads on sites, not too offensive. Let’s look at it from the machine routing through the Pi-hole:
Visually, there’s not a whole lot of difference here. However, check out the network requests at the bottom of the browser before and after Pi-hole:
Whoa! That’s an 80% reduction in network requests and an 82% reduction in the number of bytes transferred. I’d talk about the reduction in load time too except it’s really hard to measure because as you can see from the waterfall diagrams, with no Pi-hole it just keeps going and going and, well, it all gets a bit silly.
Let’s level it up because I reckon the smuttier the publication, the bigger the Pi-hole gain. Let’s try these guys:
And for comparison, when loaded with the Pi-hole in place:
And now – (drum roll) – the network requests for each:
Holy shit! What – why?! I snapped the one without Pi-hole at 17.4 mins after I got sick of waiting. 2,663 requests (one of which was to Report URI, thank you very much!) and 57.6MB. To read the freakin’ news. (Incidentally, in this image more than the others you can clearly see requests to domains such as fff.dailymail.co.uk failing as the Pi-hole prevents them from resolving.)
After just a few quick tests, I was pretty blown away by the speed difference. I only fired this up at about 8am this morning and I’m just 9 hours into it but already seeing some pretty cool stats:
It’s also flagging a bunch of things I’d like to look at more, for example my wife’s laptop being way chattier than everything else:
I haven’t looked yet, but if anyone knows the purpose of that microsoft.com domain that continually get Pi-holed, leave a comment below (I assume it’s related to the native Windows 10 mail client). And yes, I’ll chat to her about the Fox News situation as well!
I’m yet to have any legit functionality break because of the Pi-hole, but Scott has had to whitelist a couple of domains (literally 2, from memory) such as the Google Analytics dashboard. Of course, it’s entirely feasible that legit stuff will break and I myself have gone through troubleshooting pains on behalf of other people before only to then realise that it was their modification of my site that caused the failure. That’s always going to be a risk and frankly, that’s on me if my choice of tooling breaks something.
So in summary, no compromising devices, no putting your trust in the goodwill of an extension developer, no per-device effort, the bad stuff is blocked and the good stuff still works:
Lastly, Pi-hole has a donate page and this is one of those cases where if you find it as awesome as I have already, you should absolutely show them some love. Cash in some of that time you’ve reclaimed by not waiting for rubbish ads to load 😎