What system do you use to get that level of visibility?

Replace your router's DNS with something like pi-hole or a bog standard dnsmasq, turn up the logging, that's it. Ubiquiti devices I think also offer detailed DNS logging but not sure.

I believe unifi offers aggregated dns logs ootb but you could always set up more detailed ones on the gateway itself.

Main data comes from unbound[1], I use vector[2] to ship and transform logs. Dnstap[3] log format IME works better than the standard logs, especially when it comes to more complex queries and replies. Undesired queries get 0.0.0.0 as a response which I track.

Firewall is based on hand-rolled nftables rules.

[1]: https://www.nlnetlabs.nl/projects/unbound/about/ [2]: https://vector.dev [3]: https://dnstap.info/Examples/

Besides what others have said, another dead simple option is to use Nextdns: https://nextdns.io

Doesn't require running anything locally and supports various block rules and lists and allows you to enable full log retention if you want. I recommend it to non-techies as the easiest way to get something like pi-hole/dnscrypt-proxy. (but of course not being self-hosted has downsides)

edit: For Roku, DNS blocking like this only works if Roku doesn't use its own resolver. If it's like some Google devices it'll use 8.8.8.8 for DNS resolution ignoring your gateway/DHCP provided DNS server.

Seems like you could have a router or firewall mitm queries to e.g. 8.8.8.8 and potentially redirect/rewrite/respond

I would not be surprised if Google TV devices will sooner than later start using DoH to 8.8.8.8

I'm a noob at this, but can you do that when it is DoT or DoH? Like I thought the point of them is that you can't forget the DNS request. Even harder with oDoH, right? So does that really get around them?

yea when it's DoH or DoT I don't think you can re-route the DNS request inflight. (where the device thinks it's talking to 8.8.8.8 but it's not).

You can block access to other resolvers though which usually works.

Eventually devices might just start using hardcoded IPs...

I've explored that! Couldn't figure it out but it certainly sounds possible. And even easier solution is just to block all DNS resolvers except your chosen one. When 8.8.8.8 doesn't work GDevices will fallback to the DHCP assigned resolver (usually your gateway)

My router owns the IP 8.8.8.8 when seen from inside my network; the Roku literally can't ask Google for DNS via DNS, HTTP, or DNS-over-TLS.. It also answers DNS requests on port 53, and believes that there is no scribe.logs.roku.com, along with many other domains.

The downside is that Google seems to think I'm in a botnet, and wants us to login to see anything on YouTube.

Pfsense firewall. There is a week long learning curve and it’s best to put it on dedicated hardware.

My suggestion would be to configure your own router using a Linux distro. It's not as difficult as it sounds, the kernel already does most of the heavy lifting. All you need to really do is enable packet forwarding and configure the firewall using iptables rules (block all in, allow all out is a reasonable default). I use Unbound as my recursive DNS resolver, together with Hagezi's blacklists to provide DNS filtering. I filter ports 53 and 853, and filter by IP known public DNS servers (Hagezi maintains a list). DHCP is provided by the isc-dhcp-server package on Debian.

That's a more or less complete home router, with plenty on spare resources to run internal or external services like a Wireguard tunnel, file server, or the Docker/Podman runtime.

That being said, I still wouldn't connect a "smart" TV to the Internet. There are better options like a Linux HTPC.

Hashing might not work since the stream itself would be a variable bitrate, meaning the individual pixels would differ and therefore the computed file hash

They're using perceptual hashing, not cryptographic hashing of raw pixels. So it's invariant to variable bitrate, compression, etc.

How does perceptual hashing work?

Have you got any recommendations for further reading on this topic?

Possibly one of the better known (and widely used?) implementations is Microsoft's PhotoDNA, that may be a suitable starting point.

In the same way that Shazam can identify songs despite the audio source being terrible over a phone, mixed with background noise. It doesn't capture the audio as a WAV and then scan its database for an exact matching WAV segment.

I'm sure it is way more complex than this, but shazam does some kind of small windowed FFT and distills it to the dominant few frequencies. It can then find "rhythms" of these frequency patterns, all boiled down to a time stream of signature data. There is some database which can look up these fingerprints. One given fingerprint might match multiple songs, but since they have dozens of fingerprints spread across time, if most of them point to the same musical source, that is what gets ID'd.

These are two articles I liked that are referenced in the Python ImageHash library on PyPi, second article is a follow-up to the first.

Here's paraphrased steps/result from first article for hashing an image:

1. Reduce size. The fastest way to remove high frequencies and detail is to shrink the image. In this case, shrink it to 8x8 so that there are 64 total pixels.

2. Reduce color. The tiny 8x8 picture is converted to a grayscale. This changes the hash from 64 pixels (64 red, 64 green, and 64 blue) to 64 total colors.

3. Average the colors. Compute the mean value of the 64 colors.

4. Compute the bits. Each bit is simply set based on whether the color value is above or below the mean.

5. Construct the hash. Set the 64 bits into a 64-bit integer. The order does not matter, just as long as you are consistent.

The resulting hash won't change if the image is scaled or the aspect ratio changes. Increasing or decreasing the brightness or contrast, or even altering the colors won't dramatically change the hash value.

https://www.hackerfactor.com/blog/index.php?/archives/432-Lo...

https://www.hackerfactor.com/blog/index.php?/archives/529-Ki...

wouldn't LSH (Locality Sensitive Hashing) make more sense here?

Perceptual hashes are a type of locality sensitive hash.

I don’t know why you quoted the addresses.

Markdown habit.

Tell me you don't Markdown, without telling me you don't Markdown.

It's a developer thing, using backticks means the enclosed text is emphasised when rendered from Markdown.

Backticks mark fixed width inline code, not emphasis.

I know what they do, it doesn't change the fact that we use them for emphasis.

Chuckled when I saw the reasonable correct informative and perfectly polite answer…is the one in gray. Cheers.

Backticks long predate markdown.

How dare someone not be a developer!

It's polite to give parsers (human or otherwise) hints that they're about to encounter text which is now intended for a different kind of parser.

I recently forgot to surround my code in ``` and Gemini refused to help with it (I think I tripped a safety guardrail, it thought I was targeting it with an injection attack). Amusingly, the two ways to work around it were to fence off my code with backticks or to just respond to:

> I can't help you with that

With

> Why not?

After which it was then willing to help with the unquoted code. Presumably it then perceived it as some kind of philosophical puzzle rather than an attack.

It's disappointing to see people here use language like "perceived" for an LLM.

As a panpsychist I have no special esteem for an LLM's perceptive powers. I also anticipate that the planet perceives us as nuisance.

Fair question, it does look a bit jarring when not rendered. I write a lot of markdown and it's a very strong force of habit to use backticks to sort of highlight a technical term and turn it into a noun. Similar to writing endash as a double hyphen.

When I read what I write, my eyes glance through backticks and maybe come back if I need to parse the inner term in more detail.

  > Most likely ... sending the hash

If you're tracking packets can't you tell by the data size? A 4k image is a lot more data than a hash.

I do suspect you're right since they would want to reduce bandwidth, especially since residential upload speeds are slow but this is pretty close to verifiable, right?

Also just curious, what happens if you block those requests? I can say Samsung TVs really don't like it... but they will be fine if you take them fully offline.

> If you're tracking packets can't you tell by the data size? A 4k image is a lot more data than a hash.

I admit, I've not gotten around to properly dumping that traffic. For anyone wanting to do this, there's also a spike of DNS requests every hour on the hour, even if tv is off(well, asleep). Would be interesting to see those too. Might be a fun NY holiday project right there. Even without decrypting (hopefully) encrypted traffic, it should be verifiable.

> Also just curious, what happens if you block those requests?

Due to `*.roku.com` DNS black hole, roku showed no ads but things like Netflix and YouTube using standard roku apps("channels") worked fine. I now moved on to playing content using nvidia shield and blocking outside traffic completely. Only odd thing is that the TV occasionally keeps blinking and complains about lack of network if I misclick and start something except HDMI input.