My Sony TV was running Samba TV's ACR. I turned it off.

Texas is suing Sony, along with Samsung, LG, Hisense and TCL. Sony is the one in my living room, so it is the one I looked at. The attorney general filed in December 2025, alleging that these televisions use automatic content recognition, or ACR, to record what is on the screen and sell that on, with no meaningful consent beyond a settings toggle most people never see.

I had been meaning to check mine for months, and the lawsuit was what finally prompted me.

What ACR actually does #

ACR does not depend on which app you are using. It fingerprints the image on the screen, so it captures broadcast TV, discs, a games console, and anything on an HDMI input, a laptop included. Researchers at UCL and UC Davis measured it in 2024 and found the traffic for both live TV and HDMI input. They also found that the opt-out, where one exists, often fails to stop it.

My set is a Bravia 4K UR3. Underneath the Google TV interface it runs Android 10, which is what makes the rest of this possible: if it is Android, I can open a shell on it as I would on a phone.

Finding it #

The TV is also just a device on my network, so I started there. An ARP sweep, then a port scan of the one host with a fixed vendor MAC:

80/tcp    open  http     nginx
7000/tcp  open  rtsp     AirTunes rtspd
8008/tcp  open  http     (Google Cast)
8009/tcp  open  ssl      (Google Cast)

nginx, AirPlay and Chromecast on the same address indicate a Google TV with AirPlay 2, which is what a modern Bravia is. Port 5555, where ADB listens, was closed. That was the one I needed open.

One toggle, mislabelled #

Developer options are in the usual Android place. Settings, System, About, then tap the build number seven times to unlock them. There is a single switch called USB debugging, and the name undersells it: enabling it also makes the TV accept ADB over the network.

adb connect <tv-ip>:5555

The TV prompts to authorise my laptop, which I accept. The first thing worth checking is what I am connected to:

$ adb shell getprop ro.product.model
BRAVIA 4K UR3
$ adb shell getprop ro.build.version.release
10

There is no root here, and none is available: Sony does not unlock Bravia bootloaders, the build is signed, and no public root exists for these sets. None of what follows needs it.

What was on there #

$ adb shell pm list packages | grep -iE 'samba|idd|interactivetv'
package:tv.samba.ssm
package:com.sony.dtv.interactivetvutil
package:com.sony.dtv.interactivetvutil.output
package:com.sonyericsson.idd.agent

tv.samba.ssm is Samba TV, version 2.11.4. Samba is the company the research repeatedly names, the “second party” in the title of the UCL paper. interactivetvutil is Sony’s wrapper around it, the component behind the “Samba Interactive TV” entry in the settings. com.sonyericsson.idd.agent, with native daemons named idds, iddd and idd-logreader, is Sony’s own usage telemetry, inherited from its Sony Ericsson phone software.

Android’s package dump reports enabled=0 for all of them, which looks like “off” but is not. In PackageManager, 0 means “default”, which is to say enabled. ps confirms it:

$ adb shell ps -A | grep -iE 'samba|interactivetv|idd'
u0_a119  tv.samba.ssm
u0_a31   com.sony.dtv.interactivetvutil
oem_2906 [email protected]
system   idds
oem_2906 iddd

All of it was running, on a set that was only showing Freeview. The consent for it was a policy screen I clicked through during setup.

A word on the name #

Yes, that is tv.samba.ssm, and no, it has nothing to do with the SMB file server that has carried the name Samba since the nineties. The advertising company began as Flingo in 2008, named its interactive-TV platform “Samba” in January 2013, and adopted the name for the whole company that September. Nobody has recorded why they chose it, and the most likely explanation is the Brazilian dance rather than any deliberate misdirection. The Samba file-sharing project objected regardless, and have said publicly that they hold the trademark and that Samba.tv has nothing to do with them.

I doubt the collision was deliberate. It is still an awkward coincidence that software fingerprinting my screen shares a name with a service administrators routinely allow through the firewall.

Switching it off #

pm disable-user stops a package and its services, survives a reboot, and deletes nothing. It is the least invasive option, and the right place to start.

adb shell pm disable-user --user 0 tv.samba.ssm
adb shell pm disable-user --user 0 com.sonyericsson.idd.agent
adb shell pm disable-user --user 0 com.sony.dtv.interactivetvutil
adb shell pm disable-user --user 0 com.sony.dtv.interactivetvutil.output

The ACR engine went down and stayed down, as did the telemetry agent, across every reboot since. The wrapper was different. After a reboot it came back. Its flags explain why.

flags=[ SYSTEM HAS_CODE PERSISTENT ALLOW_CLEAR_USER_DATA ]
privateFlags=[ ... PRIVILEGED ]

PERSISTENT. The framework restarts persistent system apps at boot regardless of a user-level disable. So I uninstalled it for my user, which is reversible because the APK remains in the system image:

adb shell pm uninstall --user 0 com.sony.dtv.interactivetvutil
adb shell pm uninstall --user 0 com.sony.dtv.interactivetvutil.output

It returned anyway. A persistent, privileged system app cannot be fully stopped without root, and I do not have root. Rather than keep guessing, I watched what it actually did.

Proving it, without root and without a tap #

I could not run Wireshark on the TV. Packet capture needs a raw socket, a raw socket needs CAP_NET_RAW, and the ADB shell has no capabilities at all:

$ adb shell cat /proc/self/status | grep CapEff
CapEff: 0000000000000000

adb root is refused on a production build, which ends any prospect of capturing on the device. I could have bridged the TV’s cable through a spare router and captured there, which works, but there is a simpler approach that is almost as good. The shell user is in the readproc group, and /proc/net/tcp and /proc/net/tcp6 are readable. Every open socket is listed there: remote address, port, state, and the owning uid. Poll that once a second, decode the hex, and map each uid back to its package, and you have a live list of what the television is connecting to: no payloads, since those are TLS, but every destination and the app behind it.

So I re-enabled Samba for a minute and watched. The relevant lines:

com.sony.dtv.interactivetvutil   52.84.118.55:443
com.sony.dtv.interactivetvutil   99.86.12.52:443

Both addresses are Amazon CloudFront, where Samba hosts its backend. That is Sony’s Samba component connecting out as soon as it is allowed to run. I then disabled the stack again and watched the same table. The CloudFront connections were gone. The wrapper process was still running, but over a thirty-second window after boot it opened no external sockets. With the engine beneath it disabled, it has nothing to send and nowhere to send it. The only outbound traffic left was my own encrypted DNS to NextDNS, Google’s Play and Cast housekeeping, and the streaming apps I use.

That is the before and after: with the component live I could watch it reach a content-delivery network, and with it disabled the connection was no longer there.

Watching the table also showed why the wrapper has to be removed rather than merely disabled. Left installed, it restarts, and because it is privileged it re-enables Samba. Disable Samba alone and a reboot restores it. Uninstall the wrapper for your user so it cannot run, and nothing re-enables Samba; the set then comes up clean on every boot. I rebooted several times to confirm that.

Could I not just block it at the firewall? #

This is where the CloudFront detail matters. The endpoints are not something like acr.samba.tv on a fixed address I can null-route. They are shared CloudFront edges whose addresses rotate and are reused across a large part of the web. Block the ranges and you break a great deal of the internet along with Samba, and the addresses move the next day in any case. Blocking by hostname at the DNS layer is cleaner, and that is what my NextDNS list does, but it is a constant game of catch-up: a new hostname appears, the tracking resumes, and you are a day behind whoever adds them. Removing the software from the device is the only approach that holds, because there is then nothing to take the snapshot and nothing to resolve an address in the first place.

What a firmware update will do to all this #

This is the weak point. The disables and the uninstall live in /data, so they survive a power cycle, which is what most people would think to test by pulling the plug. A firmware update is different. It rewrites the /system partition, and it can reset package state and restore what I turned off. Without root I cannot delete the APKs from that read-only, verified-boot partition, and I cannot hold a package disabled against an update determined to re-enable it.

There are two ways to live with this. You can freeze updates by disabling Sony’s updater packages and blocking its update hosts, but that also stops security fixes, and I would not tell anyone to leave a networked device unpatched indefinitely. Or you keep the commands in a script and run them again if an update lands. Detection is free. If Samba’s CloudFront connections reappear under interactivetvutil in /proc, or its hostnames show up in the NextDNS log, it is back, and you re-run the script. I have taken the second option. Freezing a television’s firmware permanently to block one package is not a trade I would make.

Everything here reverses with pm enable and cmd package install-existing.

The scripts #

It is all in a repo: bravia-guard. The commands as disable.sh, a restore.sh to undo them, the /proc watcher as verify.sh, and the guard as bravia-guard.sh for cron. A --ads switch also disables the promotional and recommendation packages Sony includes. It has only been tested on my UR3, so the package names will differ on other models; the repo explains how to find your own, and a pull request adding your model would be the most useful contribution.

One note on leaving network ADB enabled for the guard. It is gated by a key the TV has to have accepted, so another device on the network cannot obtain a shell. If you want it restricted to a single trusted machine, revoke the authorisations in Developer options and re-approve only that one. That is sufficient for a home network.

What bothers me #

The capability troubles me less than the fact that it is enabled by default, on hardware I own outright, behind an opt-out that the research says often does nothing. It took a shell, four commands and a look at /proc to switch it off and to confirm it stayed off. On most sets it is still on.