Your smart TV is the chattiest device on your home network - here is what it actually sends
A modern Samsung, LG, Sony, Roku, or Fire TV is a full Linux or Android device with a microphone, a camera-style frame grabber that snapshots whatever is on the screen several times per second, and a permanent connection to half a dozen ad and analytics endpoints. The technology is called ACR - automatic content recognition - and it runs whether you stream from the TV's built-in apps, plug in an Apple TV, or watch a Blu-ray. Here is what ACR captures, what your TV sends home over the network, which settings actually turn it off, and how to isolate the TV on a separate VLAN or guest network so the rest of the house is not on the same wire.
The television in your living room is, by a wide margin, the chattiest device on your home network. A modern Samsung, LG, Sony, Roku, Hisense, TCL, or Vizio is a full Linux or Android computer with a permanent broadband connection, a microphone in the remote (and sometimes in the bezel), and a piece of software that nobody talks about in the showroom: a frame grabber that snapshots whatever is currently on the screen, computes a fingerprint of those pixels, and sends the fingerprint home to a server that identifies the show, the film, the advertisement, or the video game you are watching. The technology has a name. It is called automatic content recognition, ACR for short, and every major TV manufacturer does it, on by default, on almost every model sold since around 2017.
ACR is not a secret. It is documented in every TV's privacy policy, has been written about in detail by the FTC (in the 2017 Vizio settlement), the Markup, Princeton's Mozilla-funded research group, Northeastern, the Mozilla Foundation, and consumer organizations like Which? and Consumer Reports. The reason it does not feel widely-known is that the user-facing setting is buried four menus deep, given a deliberately bland name like "Viewing Information Services" or "Live Plus" or "Smart Interactivity" or "Use Information from TV Inputs", and turned on by default during setup with a screen designed to look like a software update.
This piece walks through what the TV actually captures, where it sends the data, how often, what the named settings do (and what they do not do), and the two practical defenses that handle the realistic risk: turn the in-TV settings off, and put the TV on its own network so that whatever it does or does not send is at least not sharing a wire with your laptop, your phone, and your work files.
What ACR actually does
Smart TVs run a small loop in the background that does approximately this: every fraction of a second, grab a copy of the framebuffer (the bitmap currently being drawn to the screen), compute a perceptual hash of that bitmap, append the hash plus a timestamp to a local queue, and periodically flush the queue to a server. The published rates differ by manufacturer and model - measurements have observed everything from twice per second to thirty times per second - but the order of magnitude is "constantly, while the screen is on".
The server on the other end has a library of pre-computed hashes for essentially every commercial film, every TV show episode, every aired commercial, every cable and satellite channel feed, and (on the more aggressive systems) every major video game's menu screens and gameplay segments. The match returns a structured record: "this is episode 3 of The Bear, minute 18, originally aired on FX, currently being consumed via Hulu", or "this is the 30-second Geico ad that aired in the second commercial break of CBS Evening News on Tuesday".
The match works at the pixel level. The TV does not need to know which app is open, which input is active, or what the DRM stream is reporting. It does not need cooperation from Netflix, the Apple TV, the Xbox, or the Blu-ray player. As long as something is on the panel, ACR identifies it. The first surprise for most people is that buying an Apple TV to escape the smart-TV apps does not escape ACR. The Apple TV's privacy posture is genuinely good. The Samsung or LG television it is plugged into is still snapshotting the screen and sending hashes home.
Where the data goes
ACR data is the high-value piece, but it is not the only thing leaving the TV. A typical smart TV, in the first minute after being powered on for the first time, makes contact with somewhere between five and fifteen distinct third-party domains. The names that come up across every independent measurement are a small list:
- Samba TV (samba.tv, samba-collector.com). Embedded in many Sony, Sharp, Hisense, TCL, Philips, and some Toshiba models. Samba is one of the largest pure-play ACR vendors and monetises the data by selling audience-measurement and ad-targeting products to broadcasters and advertisers.
- Inscape (inscape.tv, inscape-data.net). Owned by Vizio. The Inscape data set is the one the FTC sued Vizio over in 2017; Vizio settled for $2.2 million, kept the business, and renamed it.
- Gracenote (gracenote.com, several Tribune-era domains). Originally a music-fingerprinting company, now Nielsen-owned and a major supplier of ACR-adjacent metadata.
- Alphonso (alphonso.tv). Acquired by LG in 2021 and now the engine behind LG's "Live Plus" ACR feature.
- Manufacturer telemetry: Samsung's samsungcloud.tv and samsungelectronics.com endpoints, LG's lgsmartad.com, Roku's scribe.logs.roku.com, Fire TV's amazon.com analytics, Google TV's play.googleapis.com and similar.
- Generic ad networks: doubleclick.net, scorecardresearch.com, googlesyndication.com, adobedtm.com. These fire on the TV's home screen, the app picker, and inside individual apps.
Volumes are not dramatic in raw bandwidth terms - a few megabytes a day for a TV that is mostly idle, into the low tens of megabytes for one in heavy use - but the signal-to-noise is unusually high. ACR identifies what you watched, when, on what input, in which household, cross-referenced with whichever identifiers the TV manufacturer sells alongside it (typically a stable device ID, the home IP, and on some manufacturers the Wi-Fi BSSID, which is enough to fingerprint your household even if the IP changes).
The settings that actually turn it off
Every manufacturer has a setting that, by their own documentation and by independent measurement, stops the ACR hash uploads. The names are different on every brand because there is no industry standard and because the names are deliberately bland. The current ones, as of mid-2026:
- Samsung (Tizen): Settings โ General & Privacy โ Terms & Privacy โ Viewing Information Services. Disable. Also disable "Interest-Based Advertising" in the same menu, and "Voice Recognition Services" if you do not use the voice remote.
- LG (webOS): Settings โ General โ System โ Additional Settings โ Live Plus. Disable. Also disable "Advertisement" (which controls the LAD - LG Ad Decisioning - personalised ad ID) and "User Agreements".
- Sony (Google TV/Android TV): Settings โ Privacy โ Samba Interactive TV. Decline (or revoke if you accepted at setup). Also turn off "Usage and Diagnostics" and "Ads Personalisation" in the parent Google TV settings.
- Vizio (SmartCast): Menu โ Admin & Privacy โ Viewing Data. Disable. This is the post-FTC- settlement renamed setting; it controls Inscape.
- Roku: Settings โ Privacy โ Smart TV Experience. Uncheck "Use Information from TV Inputs" (this is Roku's ACR toggle) and "Personalize my experience" under Advertising.
- Hisense / TCL (Google TV or VIDAA):Settings โ System โ Privacy โ Viewing Information Services. Disable.
- Fire TV: Settings โ Preferences โ Privacy Settings. Disable "Device Usage Data" and "Collect App Usage Data". Fire TV's "Interest-Based Ads" setting controls the personalised ad ID.
Two things to know about these settings. First, they revert. Major firmware updates have, on multiple brands and multiple occasions, re-enabled the ACR toggle as part of a "Terms of Service update" presented as a single Accept button. The defensive posture is to check the privacy menu after every major TV update, and to treat any new "Accept" screen during boot as a thing to read rather than dismiss.
Second, the ACR toggle stops the ACR uploads specifically. It does not stop the rest of the telemetry: the app-internal analytics that Netflix, Disney+, Hulu, and YouTube each run independently of the TV; the operating-system telemetry that the manufacturer collects; the home-screen ad requests; or the third-party advertising integrations on the platform itself. Each of those has its own toggle, and the only durable answer is to walk through the privacy menu and turn everything off that is not strictly required for video playback. Nothing in that list is required for video playback.
The microphone question
The voice-remote case is the simplest one. If the remote has a microphone button, holding it down sends audio to the manufacturer's voice service - Bixby on Samsung, the LG voice service, Google Assistant on Google TV, Alexa on Fire TV. The audio is sent on purpose, on press, and is the feature working as designed. If you do not use it, the protection is to disable the corresponding voice service in settings, which on most platforms also stops the remote from sending the audio in the first place.
The harder case is the small group of TVs - notably the higher-end Samsung models from 2014-2017, but the category has not entirely disappeared - that have a microphone in the bezel of the TV itself, intended for always-on voice activation without picking up the remote. The 2015 Samsung privacy policy line that warned users "please be aware that if your spoken words include personal or sensitive information, that information will be among the data captured and transmitted" became famous because it was so directly stated. Most newer TVs have moved away from the bezel mic, but if you have a model that has one, the only complete defenses are physical: cover the mic with opaque tape (the mic hole is usually marked in the manual), or unplug the TV from the network entirely when not in use. The software-disable option exists in the settings menu but is harder to verify; if the threat model warrants the question, the physical cover is the answer that holds.
Why network isolation is the next layer
The in-TV settings get you most of the way there for ACR specifically. They do not address two larger questions: what happens when the TV firmware is out of date and contains a known vulnerability (which is the normal state for any device older than three years from a manufacturer that has lost interest), and what happens when an app installed from the TV's app store turns out to have been compromised or sold to a less reputable owner.
Smart TVs share, with smart bulbs, robot vacuums, doorbells, baby monitors, network printers, and connected speakers, the worst patch hygiene of any device category on the consumer market. The operating system is an old Android or Linux fork. The CVE list is long. The manufacturer's incentive to ship updates ends when the model is discontinued, which on most brands is around three years from launch. Sitting on the same network as one of these devices means that a compromised TV is on the same broadcast domain as your laptop, your phone, your NAS, your password- manager's sync traffic, and (in many setups) the SMB shares your work files live on.
Network isolation moves the TV - and the rest of the IoT devices - onto a separate logical network that cannot reach the trusted devices. There are three levels of how to do it, in increasing order of thoroughness:
- Guest network on the existing router.Every consumer router shipped in the last five years (eero, Google Nest Wifi, ASUS, TP-Link, Netgear, Fritzbox, Linksys) supports a separate guest SSID with its own IP range and "client isolation" toggled on. Move the TV and every other IoT device onto the guest SSID. The setup is a five-minute job in the router's app: create a guest network, give it a memorable name (e.g. "Home IoT"), enable client isolation, and re-pair each device. From that point on, the IoT devices can reach the internet but cannot reach your laptop, your phone, or each other - and from your laptop's perspective the IoT devices simply do not exist on the network.
- True VLAN on a router that supports it.A Unifi Dream Router, a Firewalla Gold, a Fritzbox, a MikroTik, or an OPNsense/pfSense box lets you create a tagged VLAN with its own subnet, its own firewall rules, and explicit allow/deny statements between VLANs. The advantage over a guest network is granularity: you can allow exactly the cross- network connections you want (your phone to the Chromecast for casting, for example) and block everything else. The Unifi UI in particular has made this a 20-minute setup that used to require a weekend.
- DNS filtering on top. A Pi-hole, AdGuard Home, NextDNS, or the DNS filtering built into Firewalla or Unifi can subscribe to lists that include the ACR endpoints (Samba's domains, Inscape's, Gracenote's, manufacturer telemetry hosts) and silently fail those requests. The TV keeps playing video; the hashes never leave. Combine this with the in-TV settings and the network isolation, and the three layers cover each other's failures - if a firmware update re-enables the ACR toggle, the DNS layer still blocks it; if the TV starts using hard-coded DNS to 8.8.8.8 to bypass the Pi-hole, the firewall on the IoT VLAN blocks outbound DNS to anything except your own resolver.
The two things to watch in the DNS-blocking layer. First, several manufacturers (Samsung and LG in particular, on 2023 and newer firmware) have started hard-coding DNS servers like 8.8.8.8 or 1.1.1.1 instead of using the router-supplied one. This bypasses any DNS-level filtering. The fix is a firewall rule on the router that drops outbound UDP and TCP port 53 from the TV's IP to anything except your own DNS server (or your Pi-hole). Second, some ACR endpoints have moved to DNS-over-HTTPS, which encrypts the lookup inside an HTTPS connection and is much harder to filter at the DNS layer. The firewall answer there is to block known DoH endpoints (a list of them is maintained by the NextDNS and AdGuard projects) from the IoT VLAN, or - more durably - to put the TV on a VLAN with no internet access at all for the periods you are not actively streaming, if your router supports time-based rules.
The cast-and-AirPlay question
A frequent objection to putting the TV on a separate network is that Chromecast, AirPlay, and DLNA discovery use multicast DNS (mDNS) and broadcast protocols that, by design, do not cross subnets. Move the TV to the guest network and your phone cannot find it. This is a real and annoying side-effect, and there are three reasonable answers:
- On Unifi, eero, and a growing number of consumer routers, there is now an "mDNS reflector" or "Bonjour gateway" setting that forward discovery traffic between specific VLANs. Turn it on for the IoT VLAN and your trusted VLAN; the TV becomes visible to your phone again without giving the TV access to your other devices.
- For TVs that support AirPlay 2 (most newer LG, Sony, and Samsung), the discovery now uses Apple's own mechanisms which work across subnets if both ends can reach the internet - usually fine in this setup.
- For Chromecast specifically, plugging an Apple TV or a dedicated Chromecast dongle into the trusted side of the network (and accepting that this one device straddles both worlds) keeps casting working without giving the rest of the TV's stack the same access.
What this looks like in practice
The end state for a household that wants to keep ownership of what its TV does looks something like this. The TV itself is set up with a throwaway email for any required account, the privacy menu is walked once at setup and re-walked after every firmware update, ACR and personalised advertising are off, voice services are off unless used. The TV lives on a guest network or a dedicated IoT VLAN that cannot reach the household's laptops, phones, and storage. A Pi-hole or NextDNS subscription includes the ACR and TV-telemetry block lists. Casting works because the router is set up to reflect mDNS between the two networks for the specific TV. Streaming works because none of the above has anything to do with video playback.
The cost is one evening of setup. The benefit is that the chattiest device in the house stops being on speaking terms with the most sensitive ones, and the identification of what gets played on the screen stops being uploaded to a chain of advertising intermediaries on a five-second loop.
A short checklist
- Walk the privacy menu on your specific TV and disable the ACR toggle by whatever name it has (Viewing Information Services, Live Plus, Smart Interactivity, Use Info from TV Inputs, Viewing Data). While you are there, turn off personalised advertising, app usage tracking, and voice services you do not use.
- Re-check after every firmware update.Major updates have re-enabled these toggles on every major brand at least once. Treat the post-update "Accept the new terms" screen as something to read.
- Put the TV on a guest network or IoT VLAN.Five minutes in the router app on any modern consumer router. Enable client isolation. The TV can reach the internet; it cannot reach your laptop.
- Add DNS filtering with Pi-hole, AdGuard Home, or NextDNS, subscribed to the ACR and TV-telemetry lists. Combine with a firewall rule blocking outbound DNS from the TV's IP to anything except your own resolver.
- If the model has a bezel microphoneand you do not use the always-on voice feature, cover the mic hole with opaque tape. The setting to disable it in software exists but is harder to verify than a physical cover.
- For HDMI sources you care about,remember that ACR sees the panel, not the input - the Apple TV or PlayStation plugged in does not escape ACR, only the in-TV settings and the network controls do.
Where this fits
The smart TV is the household version of a pattern that shows up everywhere on a modern network: a device with a permanent connection, a long list of third-party integrations, and a setup screen that treats permission as a default. The same pattern applies to a browser, which is covered in five things your browser sends to every site, and to the cables that move data between devices, covered in the USB-C cables piece. The question of what is end-to-end encrypted over the network (and what is not) is in the E2EE article, and what happens to the recordings, screenshots, and viewing history once you press delete is in the delete piece.
Privvert's tools all run locally in the browser - no upload, no server in the middle, no telemetry. The reasoning is on the privacy page, and the rest of the practical guides are on the blog.
Related reading
AI tools and your files: what ChatGPT, Claude, and Gemini actually keep when you upload
Drag a contract into ChatGPT, upload a spreadsheet to Claude, hand a folder of photos to Gemini - and the question that almost nobody answers in the marketing is what happens to the file after the model has finished answering. The short version: it lives a lot longer than the reply does, in more places than the consent screen suggests, and the rules are different between the free tier, the paid tier, and the enterprise tier of the same product. There are also live legal carve-outs - the New York Times v OpenAI preservation order has forced ChatGPT to keep deleted chats since mid-2025 - that the in-app help pages do not mention. Here is what each of the big AI tools actually does with a file you upload, what 'we don't train on your data' actually means in 2026, the incidents that show what goes wrong when the policy and the reality diverge, and the practical answer for handling anything sensitive.
ยท21 min readWhy an 'unguessable' Dropbox or Google Drive link is not private
Generating a share link feels like the privacy-respecting choice. The file does not get emailed around, the URL is long and random, and only people you send it to can open it. The reality is messier: search engines have been indexing shared cloud links since at least 2014, the Wayback Machine has snapshotted plenty of them, browsers and password managers sync the URLs across devices that may not all be yours, the Referer header leaks the link to every third-party script on whatever page you paste it into, and a single screenshot that includes the address bar is enough to make the link public forever. There is a long record of real incidents - Box.com exposing tens of thousands of corporate files via guessed and indexed share links, Microsoft Power Apps leaking 38 million records through default-public sharing, OneDrive 'private' links appearing in Bing - to make the point that 'anyone with the link' is not a niche-case warning. Here is what actually happens to a share link after you create it, where it leaks, and the share settings that are genuinely private.
ยท19 min readThe 'Print to PDF' trap: what your exported PDF still contains - and what a screenshot leaves out
Print to PDF feels like flattening a document to a clean, sealed file. It is not. The PDF that comes out the other side typically still contains the full selectable text under every black box, the original author name and editing history in the metadata, hidden layers from the source application, comments and tracked changes you thought you removed, and - on macOS and Windows - a record of the printer driver and the machine that produced it. A screenshot of the same PDF, by contrast, is a flat bitmap with none of that. Here is what Print to PDF actually preserves, why a flattened screenshot leaks less in many real cases, when each is the right tool, and how to produce a PDF that is genuinely safe to send.
ยท17 min read