This happens more and more often, and there is a fairly easy + popular workaround (which also comes with 99% ad blocking as a bonus). Just either set up pi-hole locally OR use a hosted DNS service that does essentially the same thing.
Main idea: Ads, updates, etc. typically (not always) need to resolve hosts before connecting to servers. Simply resolve these hosts to 0.0.0.0 instead of a real IP.
Arguments for pi-hole or other local solution: Free. Private.
Arguments for hosted solution: No set-up headache, no local raspberry pi or other machine to maintain. Overall a bit simpler.
Guide for blocking updates after the service is set up (I just went through this a month or two ago to block updates to my LG TV):
Step 1: Search around for servers that correspond to updates for your device.
Step 2: Test these lists; realize that they are often incomplete.
Step 3: Shut your device off. Open pi-hole like service, and watch queries live. While doing so, turn on your device (and if you have the option, check for updates).
Step 4: Put all of the queried hosts you see into your block list.
Step 5: Later, you may encounter broken functionality. When this happens, look at your logs, and see which server(s) were blocked at that moment. Remove only those from the blocklist. (And cross your fingers that the manufacturer doesn't use the same hosts for typical functionality and updates.)
> Step 5: Later, you may encounter broken functionality. When this happens, look at your logs, and see which server(s) were blocked at that moment
Eventually you end up with advertisements being served because the application refuses to show the content without the advertisements.
So let me cut back to your main idea:
> Main idea: Ads, updates, etc. typically (not always) need to resolve hosts before connecting to servers. Simply resolve these hosts to 0.0.0.0 instead of a real IP.
Better solution: resolve these hosts to an address you control on your network. You could even resolve it to a "public" address and add a static route to your router.
You can then choose to serve no-content from that address.
Even easier: just don't connect it to your network. Everything connected to my network runs free software that I control. If you absolutely must have something on your local network then have it in a VLAN that has no internet access and can't access your main LAN.
> This happens more and more often, and there is a fairly easy + popular workaround (which also comes with 99% ad blocking as a bonus). Just either set up pi-hole locally OR use a hosted DNS service that does essentially the same thing.
DNS over HTTPS is going to render this method ineffectual eventually. Smart devices are going to stop trusting anything on the local network.
why connect the junk to the internet to begin with? it’s a TV. I can buy a better streaming box and plug it in. People really over complicate things sometimes IMO.
This happens more and more often, and there is a fairly easy + popular workaround (which also comes with 99% ad blocking as a bonus). Just either set up pi-hole locally OR use a hosted DNS service that does essentially the same thing.
Main idea: Ads, updates, etc. typically (not always) need to resolve hosts before connecting to servers. Simply resolve these hosts to 0.0.0.0 instead of a real IP.
Arguments for pi-hole or other local solution: Free. Private.
Arguments for hosted solution: No set-up headache, no local raspberry pi or other machine to maintain. Overall a bit simpler.
Guide for blocking updates after the service is set up (I just went through this a month or two ago to block updates to my LG TV):
Step 1: Search around for servers that correspond to updates for your device.
Step 2: Test these lists; realize that they are often incomplete.
Step 3: Shut your device off. Open pi-hole like service, and watch queries live. While doing so, turn on your device (and if you have the option, check for updates).
Step 4: Put all of the queried hosts you see into your block list.
Step 5: Later, you may encounter broken functionality. When this happens, look at your logs, and see which server(s) were blocked at that moment. Remove only those from the blocklist. (And cross your fingers that the manufacturer doesn't use the same hosts for typical functionality and updates.)