The smart TV in your living room is a node in the AI scraping economy

The work at Include Security has us working with AI day in and day out (hacking it, using it, training it, etc).

We’re all aware of the community-level opposition happening against datacenters, aimed at improving AI capabilities, being built recently. What you might not be aware of are the distributed efforts to train AI that could be using the devices inside your home.

In this post, we’re going to explore how the company Bright Data facilitates modern AI models scraping training data from the Internet using its residential proxy network.

Bright Data is a data-collection company that sells access to what it markets as the world’s largest residential proxy network of 400M+ home IP addresses that its customers route web-scraping traffic through. The supply behind that network comes from an SDK: a piece of software embedded in consumer apps that, with the user’s consent, turns their phone or smart TV into one of those exit nodes.

We’ll document what you, the average user, should know about what this company’s SDK does on your systems such as your mobile phone and your smart TV. We’re going to explore how their SDK works, which platforms have shipped it, and why your Internet-connected TV is the ultimate proxy for AI models looking to train on data scraped from the Internet.

Why This Matters Now

AI companies depend on web-scraped content: for pre-training, for retrieval, for agent grounding, for search. But the modern web isn’t scrapeable from a datacenter. Cloudflare, DataDome, HUMAN, among others throttle or block requests from known cloud IPs.

The workaround is residential proxies. A scraping job routed through a Comcast or T-Mobile subscriber’s connection arrives at the target site from an IP that belongs to a paying residential customer. Krebs reported in October 2025 that “a glut of proxies from Aisuru and other sources is fueling large-scale data harvesting efforts tied to various AI projects.” Academic measurement going back to 2019 shows these networks are overwhelmingly misused. The FBI issued a formal advisory earlier this year.

Most of the existing press has focused on the illegal residential-proxy supply: botnets (Aisuru, Kimwolf), trojanized apps (HUMAN Security’s PROXYLIB disclosure), pre-infected IoT hardware (Google/Mandiant’s IPIDEA takedown). These are the bad actors.

On the other hand, the legal supply side has received far less scrutiny. Today Bright Data is the largest residential proxy network in the world by its own marketing, advertising “150M+ IPs” sourced via a consent SDK embedded in partner apps. This research documents how that SDK works, which platforms have shipped it, and why the connected-TV is the ultimate residential proxy.

Why Connected TV (CTV) is the Ideal Proxy

Connected TV, a.k.a Smart TV, is a near-perfect residential proxy. Compared to a mobile phone:

FactorMobile phoneSmart TV / CTV

PowerBattery most of the dayAlways plugged in

NetworkWiFi + cellularAlways WiFi, high-speed

UptimeIntermittent24/7 in standby

Bandwidth ceilingLow (cellular caps)Effectively unlimited

User attentionActively usedOften unattended

Consent UIText on a phone screenText navigated via TV remote arrow keys

Corporate/family oversightHigher (MDM, mobile EDR)Virtually none

A TV never hits 1% battery, jumps between WiFi networks or gets locked when the user is asleep. Some partner publishers do disclose the Bright Data relationship in their privacy policies PlayWorks is one example. But privacy-policy disclosure is the wrong control surface for a TV. It is hard to scroll through a legal document navigated by arrow keys on a remote, and the in-app consent dialog, doesn’t convey that a paying Bright Data customer is about to route their scraping traffic through the user’s home internet.

Petflix, a Roku app documented by The Verge, is a representative case. Its opt-in screen reads: “To enjoy Petflix for free with fewer ads, you are allowing Bright Data to occasionally use your device’s free resources and IP address to download public web data from the internet. Bright Data will only use your IP address for approved business-related use cases. None of your personal information is accessed or collected except your IP address. Period.” The Petflix dialog says “occasionally.” The SDK’s publicly queryable config sets max_bw_monthly_wifi: 200,000,000,000 bytes — a 200 GB default monthly WiFi budget.

Who Bright Data Names as Partners

Bright Data exposes a partner manifest endpoint. The endpoint is unauthenticated and anyone can fetch it. Names in the manifest that I was able to identify with high confidence from public sources:

Partner ID (from config)EntityScale

playworks_digitalPlayWorks Digital Ltd400+ CTV game titles; reach ~250M TV homes via Comcast, Sky, Cox, LG, Samsung, Vizio, Roku

cloudtvCloudTVIntegrated across 125+ TV brands and 15+ OEMs

longvision_media_hong_kong_co_limitedLongvision Media HK (LongTV)5M OTT users across HK and Malaysia

viber_media_s_r_lViber Media S.à r.l. (Rakuten)250M–820M monthly users of the Viber messenger

supercent_incSupercent (Korea)#1 Korean mobile publisher by downloads in 2023

moonfrog_labs_private_limitedMoonfrog Labs (Stillfront subsidiary)~10M MAU on Teen Patti Gold alone; acquired for $90M

hola_networksHola NetworksBright Data’s lineage parent; user base reported in the tens to ~100M+ range at peak per Hola’s own historical marketing

Others (desoline, free_time, ott_studio, global_microtrading, m_m_media, easystaff_lp) are present but less identifiable from public sources. bright_screensavers, bright_videos, and brightdata are Bright Data’s own apps.

A note on what the partner list proves: Being listed in Bright Data’s config means an integration might have existed at some point. It does not by itself prove that a specific publisher’s currently-shipping app(s) includes the SDK in production. For any named publisher, per-app verification is required.

What the partner list does directly prove:

Bright Data ships this roster in an unauthenticated public endpoint.

At least three CTV-focused entities (PlayWorks, CloudTV, Longvision) monetized their user’s devices as residential proxy exit nodes. PlayWorks in particular reports CTV distribution across major TV platforms and ISPs, with reach figures in the hundreds of millions of households per its own marketing materials.

How does the Bright Data SDK turn a user’s device into a residential proxy exit node?

The Bright Data SDK is a publicly documented commercial product, offered to publishers via Bright Data’s SDK integration docs (with a JavaScript variant for web). What follows builds on that public surface with findings from reverse-engineering the shipping iOS framework and instrumenting 30 days of its runtime traffic.

The SDK ships as an iOS framework (brdsdk.framework) inside partner apps. I reverse-engineered the binary and captured 30 days of traffic from a research fleet running the SDK inside a consent-installed partner app.

The Unauthenticated Config

On every launch the SDK calls:

GET ?appid=&ver=&uuid=sdk-ios-

The endpoint is unauthenticated in any meaningful sense. The server gates only on two query parameters appid (an app bundle ID, which can be found in the App Store listing of the partner app) and ver (the SDK version string). Supply those and any randomly generated UUID, and the server returns the same response a real device gets: feature flags, idle-detection thresholds (battery %, CPU/memory ceilings, WiFi-vs-cellular rules), per-country bandwidth tiers, and the partner manifest I showcased above. Each of these branches is worth examining on its own: the idle rules that decide when your device is eligible to relay, a flag that routes peer traffic around your VPN, a map that stitches your installs across platforms into one identity, and the per-country bandwidth caps.

The Peer Tunnel

After config fetch, the SDK opens a persistent WebSocket to:

wss://proxyjs.brdtnet.com:443

This hostname resolves to AWS Global Accelerator IPs (3.33.193.183, 15.197.193.114 as of this writing). The TLS certificate is CN=*.luminatinet.com — the domain for Luminati Networks, Bright Data’s pre-2018 corporate name. The rebrand was publicly announced in 2018. Active SDK infrastructure still runs on the legacy cert, which is a useful detection pivot: the current customer-facing proxy service lives on brightdata.com-branded domains, so any luminatinet.com / brdtnet.com traffic on your network is specifically the peer-tunnel plane, not customer-side Bright Data usage. The server identifies itself as uWebSockets: 20.

The peer endpoint requires no authentication to upgrade. The server accepts any TLS-valid WebSocket upgrade and immediately pushes the connecting client an application-layer frame with the client’s public IP echoed back. From there, a handshake unfolds:

Server → client: tunnel_init establishes the session, returns the client’s public IP.

Server → client: cid_set the server assigns the client a session-tracking identifier in the format -/lscp443__. We confirmed this format matches the cid field present in the SDK’s captured telemetry traffic from real devices.

Server → client: status_get the server polls the device for its idle state, battery, network type, and available bandwidth. The device responds with a continuous telemetry feed: idle, wifi_connected, mobile_connected, mobile_type (LTE/5G), roaming, battery_level, using_battery, screen_on, on_call, cpu_usage, mem_usage, raw_bw, bw, ipv6_supported, appid (the host app), sdk_version, platform, and the assigned cid. This is a continuous feed of physical-device state to a third party, delivered via a consent dialog whose text is chosen by the host app publisher.

Handshake complete. Once the device reports favorable status, the server’s job-matching layer is free to push cmd_tun frames: individual scraping-job instructions that the SDK executes as HTTP requests against third-party sites, using the user’s residential IP as the source.

Every frame on the WebSocket is plain JSON with a fixed envelope:

{"type": "ipc_call"|"ipc_post"|"ipc_result"|"ipc_error", "cmd":  , "cookie": , "err_code": 0, "msg": { ...payload... }}

The full command vocabulary extracted from the binary and verified on the wire:

DirectioncmdPurpose

Server → Clienttunnel_initOpen session, echo public IP

Server → Clientcid_setAssign session identifier

Server → Clientstatus_getPoll device idle/battery/bandwidth

Server → Clientcmd_tun / tunDispatch a scraping job

Server → ClientdnsRequest DNS resolution of a target

Server → ClientconsentRequest consent state

Client → Serverstatus_sendPeriodic heartbeat with device state

Client → Servertun_report / tun_ack / tun_finRelay-job lifecycle responses

Client → Servertunnel_init_declineDecline a session

Client → ServerlogsShip diagnostic logs to server

There’s no message signing, HMAC, client certificate or device attestation. Only the TLS layer and the server’s IP-reputation filter gating which peers actually receive jobs. For readers familiar with commercial malware protocol design: this is substantially less secure than typical C2.

When the SDK considers you “idle”

The config ships an explicit rulebook for when the device is eligible to relay someone else’s traffic:

"idle_metrics": { "ignore_screen_on": true,      // relay even with the screen on "ignore_on_call": true,        // relay while the user is on a phone call "max_bw_ratio": 1, "min_battery": 0.2, "wifi_on_battery": true, "min_battery_wifi": 0.2, "max_cpu_usage": 70, "max_mem_usage": 90, "mem_screen_off": true, "idle_timeout": 30, "not_idle_timeout": 10 }

The ignore_screen_on and ignore_on_call flags are notable: “idle” does not mean the user is away from the device. It means the device’s CPU, memory, and battery are within the SDK’s thresholds. A user on a phone call, actively reading the screen, is considered idle for relay purposes.

Cross-Plat

[truncated for AI cost control]