How do I block ads on YouTube?

blacklisting

#265

We were talking about YouTube specifically.

So we know that ads and videos are served from the same YouTube domains. So you can’t block based on that.

We also know that when you click a video YouTube calls the YouTube api and asks for what to show - likely an ad url and or a video url. Of course uBlock can filter on that an pi hole can’t.

What I was actually talking about was if you are in the US that YouTube api knows you are there ‘somehow’ and sends back 1 of a million YouTube ads for the US.

If on the other hand you are in some tiny obscure country it will send you 1 of maybe 100 ads available - in other words you will see a lot less ads in a small obscure country than the US.

Now the question is how does it know which country you are in? There’s a few possibilities:

  1. it checks which ip the request comes from ie your ip.

  2. when you request the dns for some domain let’s say api.youtube.com, the dns server sends the ip of a google server setup to respond with ads AND videos for your country. Basically a regional server that handles all YouTube api requests. We still can’t block this ip as it’s needed by YouTube for everything.

I would have assumed it was 1) BUT testing out some vpn servers which show the ip as US I see Dubai ads.

This leads me to think this vpn setup may be using a Dubai dns server which incorectly sends back ips for google servers in Dubai. Ok their setup is broken but it raises the question that could 2) be how youtube serve you ads for your country?

Most public dns servers should serve you local ips based on where you are requesting from - but some probabaly don’t. Has anyone tried an alternative dns and actually got ads from a different country ever?

Someone further up said they did exactly that, I was skeptical but after the vpn test I did it may be worth a second look.

Edit: I am neither in US or Dubai so it’s got nothing to do with where I really am!


#266

Tell us :wink:


#267

CDN, Content Delivery Network

These server can even be located inside the nerwork of your ISP. If you use the DNS of your ISP you will stay completely inside the nerwork of your ISP.

Google will have installed a tracking system on those CDN to not miss out of userdata.

If you use VPN you will go directly to servers in the internet connection node and those can be area, country or several countries.

VPN let you appear as you surfing from a different location but the DNS is inside the network of you VPN provider.

You can get in trouble if you use DNS of your ISP then it could point to a CDN that is not reachable through the VPN you are using.

So the source address is the best indication where are and ofcourse Alphabet and other tracking firms have tools installed on you mobile devices to track you always and everywhere.


#268

This particular vpn uses its own dns. The ips it returns can’t be reached outside of the vpn network whereas all other YouTube addresses seem to be reachable from anywhere in the world.

It’s likely Dubai have special youtube nodes to comply with local policy, but that wasn’t really my point.

What this means is that an IP address in the US (the vpn end point) was able to be served ads from Dubai because of the dns resolution. So in that case we could redirect some host (which one?) to a tiny countries youtube node to reduce the ads significantly.

Anyway it needs more investigation. It’s also possible that the app itself is connecting to a site or non http/s protocol somewhere to get its external up like STUN does.


#269

I don’t think that this will fly in the end.

You are using DNS nodes that havesome kind of repression forced on them. Lets say we are going to usea DNS on a small country or island that is free. It will serve general general DNS information because it will not a CDN infrastructure/datacenters.

The Y-o-u-t-u-b-e behaviour is not a problem on my PC or Android devices because software filters out that stuff.

If you want to outsmart them you have find a domain rewrite program that sits in front of Pi-hole


#270

More I read this thread, the more I believe that a complimentary client-side plug-in is needed. Client-side code should communicate with pi-hole back-end to automatically update black-list queries.


#271

Those are already there and they do detect and block. uBlock is such a add-on.

Adding a dynamic part to Pi-hole will complicate all kind of things.


#272

Client side is no good for smart TVs.


#273

Then how fo you run then an add-on on the smart TV to steer Pi-hole.

To me this is a ship that sailed.

Better think of a system that acts like a proxy and removes the advertisment.


#274

You used to just block the ad servers and change the TV’s DNS settings. You can still kinda do it but you also need something that emulates a YouTube server and says “no ad, just play the video”.


#275

If I’m not mistaking every device has some sort of Ad tracking id and perhaps a standard way to pass it in the data exchange between client/server. If this could be sniffed-out and blocked it would work?


#276

The apps and website seem to work slightly differently.

App:

  1. App starts and connects to redirector.googlevideo.com, this returns a media endpoint.

  2. app sends a large post to the endpoint above to authenticate, get an access key and allow acces, if you blocked redirector nothing is sent yet. (This access key is used from now on to all media endpoints)

  3. app connects to YouTube api etc and gets the video list etc

-> click a video in app

  1. site connects YouTube.com and asks for ad and media endpoints.

  2. app connects to both endpoints (ad and video). App sends large post to authenticate IF you blocked redirector, to the first of the endpoints connected - could be video could be ad.

  3. app starts to receive from video endpoint then pauses. Simultaneously it receives from ad endpoint - which may return nothing.

  4. if no ad in 5) or ad is finished the app resumes receiving the video.

You can’t block the above using domains. It’s impossible. If you can install your own certificate you CAN intercept the ssl traffic and block the ad request to the api.

Even if you block YouTube.com at a specific time to block the api request and not the rest the app tries numerous backup methods to get the ad including using a random media endpoint and asking for a random ad. I believe the normal way is to ask for a targeted ad and fallback is to ask for any ad directly from a random media endpoint.

Looking at the above it’s basically imposssible to block this without intercepting the traffic. To do this off device you need to do ssl mitm which means your own CA and connecting devices trusting it.

Oh and YouTube apps also use QUIC as their primary connect for media. Then fallback to tcp https if it fails.

Web:

I haven’t looked at this extensively but I’m guessing it’s not far from the above. Using a browser plugin you can intercept before ssl encryption so you can basically filter the traffic.

Final notes:
I strongly suspect that the endgame here is that YouTube will create an access flow - get ad, when ad is finished or no ad send video access key - request and play video.

They could still do this by only pre sending parts of the video until the access key is given.

At this point blocking will become impossible.

With youtube red etc being pushed heavily now, and ads increasing I think this is a major focus for youtube now - we probabaly won’t win this one :confused:


#277

See my post below. To sniff you need to intercept ssl, and to do that your device needs to have capability to trust a third party certificate.

Mobile phones, computers etc can do this, smart TVs etc probabaly can’t.