Summary
The TV is a Samsung QE55Q9FNA (2018, Tizen) on firmware T-KTM2DEUC-1340.4 (shown as 1340). In the TV's settings, Interest-Based Ads and Viewing Information Services were declined (as were Voice Recognition and Online Remote Management), and Auto update was Off. Six packet captures were taken on 2026-10-25. In that state, the TV still:
- fetched ads from AdGear (Samsung Ads,
rtb.adgrx.com,tvx.adgrx.com,cdn-stv.adgrx.com) and uploaded encrypted ad logs totvp-ads-log.samsungads.com: on the home screen (test 4), while an external HDMI source was being watched (test 6), during USB video playback (test 5), and after the TV was put in standby (test 5); - sent regular encrypted uploads to
lcprd1.samsungcloudsolution.net, about once a minute in tests 4 and 5 and at irregular intervals during HDMI viewing in test 6; - started a firmware-upgrade attempt despite Auto update being Off (seen on screen at 16:01:14 in test 6). It matches, to the second, a mutually authenticated TLS session with
bpu.samsungelectronics.com. No firmware download was seen, because the firmware-download hosts were blocked.
- No ACR contact. No DNS lookup or connection to
samsungacr.com(automatic content recognition) was seen in any of the six tests. In tests 4 to 6 that domain was reachable, and test 6 included about 5 minutes of HDMI viewing. - The upload contents are unknown. All uploads to Samsung, AdGear and the ad-log host are encrypted (HTTPS). Only hostnames, times and byte counts are visible, not what the records contain (for example identifiers, active input or viewing data).
- Limited scope. The results cover only this one device, on this firmware and with these settings, over short test windows (5 to 11 minutes each). They do not show what happens at other times, on other models or on other firmware.
- No evidence was found of microphone recording or screenshot uploads.
TV settings during the tests
These photos of the TV screen were taken at 12:41 to 12:45 CET on 2026-10-25, while the consent dialogs were reviewed. Every consent box was left unchecked. The photos are cropped to the dialog and all metadata has been removed. The on-screen text is in Swedish.
Tests and timeline
All times are CET (UTC+1) on 2026-10-25. The TV's address on the home network was 192.168.131.22. In tests 1 to 3, Samsung's advertising, telemetry, ACR and update domains were blocked at the router. In tests 4 to 6, the advertising, telemetry, ACR and account domains were unblocked, and only the firmware-download (OTN) hosts stayed blocked. Byte counts are TCP/UDP payload, and "up" means from the TV to the internet.
| Test | Window (CET) | Samsung domains | Activity on the TV | Observed |
|---|---|---|---|---|
| 1 | 13:03:53–13:08:53 | blocked | Menu, then a Samsung TV Plus channel | Blocked attempts to reach tvp-ads-log.samsungads.com (13:05:40), lcprd1, configprd and osb-apps. 135 plaintext HTTP requests for Samsung's connectivity check check.xml. Ads were inserted into the TV Plus stream through Amazon MediaTailor. |
| 2 | 13:10:56–13:15:55 | blocked | Video playing (TV Plus) | The TV sent 97 377 B upstream in total, of which 16 810 B went to the streaming server and 46 740 B to MediaTailor. There were no sustained uploads. check.xml was requested 134 times. |
| 3 | 13:16:45–13:21:58 | blocked | Standby, then a cold start | At switch-off (13:16:45–48), AdGear (tvx, rtb, cdn-stv.adgrx.com, about 171 kB down) was reached, because it was not on the block list. tvp-ads-log was attempted 4 times and blocked. OneTrust mobile-data.onetrust.io was contacted at 13:17:30 and 13:20:06. The Netflix app sent about 358 kB upstream (13:17:30–13:18:00). There were two short gaps in the TV's traffic. |
| 4 | 13:50:29–14:00:29 (captured 13:50:29–13:54:11) | unblocked (except OTN) | Home screen, then TV Plus channel zapping. The HDMI, USB and standby phases were planned but not captured, because of the capture size limit. | At 13:52:09–10, three encrypted uploads to tvp-ads-log.samsungads.com (829 / 834 / 838 B) in the same second as AdGear requests. Uploads to lcprd1.samsungcloudsolution.net about every 60 s (13:52:06, 13:53:05, 13:54:05). oempprd.samsungcloudsolution.com sent about 857 kB down. No ACR lookup. |
| 5 | 14:20:00–14:31:00 | unblocked (except OTN) | Power-on and an attempt to get HDMI working, with no HDMI picture (14:20:25–14:23:30). USB video (14:23:30–14:26:00). Standby (14:26:40). | AdGear request, then encrypted tvp-ads-log upload, at 14:20:32, 14:20:59, 14:21:12 (power-on/HDMI attempt), 14:23:54 and 14:25:54 (USB playback), and 14:26:54 (after standby). lcprd1 uploads once a minute (about hh:mm:31). After standby, a boot-like burst (Samsung services, ad logging, Netflix, YouTube) until 14:28:43, then silence. No ACR lookup. |
| 6 | 15:58:45–16:09:45 (unblock took effect 15:59:17) | unblocked (except OTN) | External HDMI source playing, then standby and power-on with the remote. These two times were not noted. They are inferred from the traffic as about 16:04:20 and 16:08:38 (low confidence). | AdGear request, then tvp-ads-log upload (843 + 847 B), at 15:59:36, 16:00:28 and 16:01:15 during HDMI viewing. About 410 kB was downloaded from cdn-stv.adgrx.com. lcprd1 uploads 16:00:18–16:04:19 (17 510 B up). At 16:01:14 an upgrade attempt appeared on screen (Auto update Off). In the same second, a client-certificate TLS session with bpu.samsungelectronics.com ran (149 + 549 B up, 290 B reply). otnprd11.samsungcloudsolution.net was looked up at 16:00:40, but no packet was sent to it. No firmware download. No ACR lookup. |
Before the captures, on boot at about 12:26–12:35, the TV also checked for updates by itself, with Auto update Off. It showed "There are no new updates for you at the moment". This was observed on screen only, not in a capture.
Contacted hosts
Hostnames come from DNS answers, the TLS Server Name Indication and HTTP Host headers. "Blocked" means the owner's router blocked the host during that test.
| Host | Operator / role (as observed) | Tests | Notes |
|---|---|---|---|
tvp-ads-log.samsungads.com | Samsung Ads, ad-event logging | 1, 3 (blocked); 4, 5, 6 | Encrypted uploads, usually two records of about 840 B after each AdGear request |
rtb.adgrx.com, tvx.adgrx.com, cdn-stv.adgrx.com | AdGear (Samsung Ads), ad requests and ad content | 3, 4, 5, 6 | Not on the block list in tests 1–3. About 410 kB down from cdn-stv in test 6 |
lcprd1.samsungcloudsolution.net | Samsung, periodic uploads (purpose unknown) | 1, 3 (blocked, retried about every 60 s); 4, 5, 6 | Small encrypted records, mostly 0.4–1 kB, plus one of 8 464 B in test 5 |
bpu.samsungelectronics.com | Samsung | 6 | Mutual-TLS session at 16:01:14, the moment of the on-screen upgrade attempt. Not on the block list |
apu., cpu., dpu., xpu.samsungelectronics.com | Samsung | 3, 4, 6 | Connection attempts only, with no data exchanged |
otnprd9., otnprd11.samsungcloudsolution.net | Samsung firmware delivery (OTN) | 5, 6 | DNS lookups only. Kept blocked, and no packets were sent |
cdn.samsungcloudsolution.com | Samsung, connectivity check check.xml | 1–6 | Plaintext HTTP, about 120–135 requests per 5 minutes while blocked |
configprd.samsungcloudsolution.net, time.samsungcloudsolution.com/.net, notice.samsungcloudsolution.com, oempprd.samsungcloudsolution.com | Samsung configuration, time and notices | 1, 3 (blocked); 4–6 | Time sync partly in plaintext HTTP |
osb-apps, osb-v1, osb-v1-alb, osb-v1-eusvc, osb-auth-eusvc, osb-tnc-v2-appsacc, gpm.samsungqbe.com | Samsung Smart Hub, account and terms services | 1, 3 (blocked); 4–6 | |
gld.push.samsungosp.com, eu-auth2.samsungosp.com | Samsung push and account services | push: 1, 3, 4, 5; account: 5, 6 | Push on port 5223 |
api.samsungcloud.com, api.smartthings.com, *.samsungiotcloud.com | Samsung cloud and SmartThings | 5, 6 | At power-on in test 5. SmartThings keep-alive about every 90 s |
tvpndynamiclogopeu.samsungcloud.tv | Samsung TV Plus channel logos | 3, 5 | |
musicid.samsungcloud.tv | Samsung | 1, 3, 5 | DNS lookup only, never connected |
samsungacr.com | Samsung ACR (content recognition) | none | Never looked up or contacted, including while reachable in tests 4–6 |
*.mediatailor.us-east-1.amazonaws.com | Amazon MediaTailor, ad insertion in TV Plus streams | 1, 2, 3 | |
*.samsung.wurl.tv, *.playouts.now.amagi.tv, *.fast.rakuten.tv | Samsung TV Plus and FAST channel streaming | 1–5 | |
mobile-data.onetrust.io | OneTrust consent SDK | 3 | About 74 kB down and 3.2 kB up |
selfsigned.ueiwsp.com | Universal Electronics (UEI) | 3, 5 | |
d1oxlq5h9kq8q5.cloudfront.net | Unattributed (Amazon CloudFront) | 5 | 24 connections in the burst after standby |
Netflix, YouTube and tv4-smarthub-preview.a2d.tv hosts | Third-party apps preloaded by the TV | 1–3, 5, 6 | Netflix also queried DNS at 8.8.8.8 directly, instead of the configured resolver 1.1.1.1 |
The TV sent ARP requests to at most 4 local addresses per test. No local network scanning was seen.
Frequently asked questions
Does a Samsung TV still send data after you decline Interest-Based Ads and Viewing Information Services?
In this study, yes. With both consents declined, a Samsung QE55Q9FNA on firmware 1340 still fetched ads from AdGear (Samsung Ads) and uploaded encrypted ad-event logs to tvp-ads-log.samsungads.com on the home screen, during external HDMI viewing, during USB video playback and after standby.
Does the Samsung TV log ads while you watch HDMI or USB?
Yes, in these tests. Encrypted ad-log uploads were seen during about five minutes of external HDMI viewing (test 6) and during USB video playback (test 5). What the records contain is unknown, because they are encrypted.
Was Samsung ACR (automatic content recognition) traffic seen?
No. The ACR domain samsungacr.com was never looked up or contacted in any of the six tests, including while it was reachable. That does not prove ACR never runs at other times.
Does the TV update itself with Auto update turned off?
It tried. With Auto update Off, an upgrade attempt appeared on screen at 16:01:14 in test 6, in the same second as a certificate-authenticated TLS session with bpu.samsungelectronics.com. No firmware was downloaded, because the firmware-download hosts were blocked.
How can I stop a Samsung TV from sending this data?
In this study the traffic was stopped with hostname-based (layer-7) firewall rules on the owner's router, blocking Samsung's ad, telemetry, ACR and update domains. Declining the on-screen consents alone did not stop the ad logging.
How was the traffic recorded?
With the packet-capture function of the owner's own managed switch, on the TV's port only. Nothing on the TV was modified, nothing was decrypted, and no Samsung system was accessed. SHA-256 hashes of the raw captures are on the method page.
Status
- 2026-10-25: The owner sent Samsung a data subject access request under GDPR Article 15, with a copy to a Swedish supervisory authority. The reply is due by 2026-11-25 (one month, Art. 12(3) GDPR).
- A complaint was filed with the Swedish telecom regulator on 2026-10-25.
- Raw packet captures are not published, because they contain other traffic from the home network. They are available to Swedish supervisory authorities on request. Their SHA-256 hashes are listed on the method page.