The work at Ember Security has us working with AI day in and day out — hacking it, using it, training it. We’re all aware of the datacenter-level efforts underway to advance AI capabilities. What you may not be aware of are the distributed efforts to train AI using the devices inside your own home.
In this post, we explore how the company Bright Data facilitates large-scale AI models scraping training data from the web using its residential proxy network.
What is Bright Data?
Bright Data is a data collection company that sells access to what it markets as the world’s largest residential proxy network — 400M+ home IP addresses. Its customers route web-scraping traffic through these IPs. The supply behind that network comes from an SDK: a piece of software embedded in user apps that, with the user’s consent, turns their phone or smart TV into an exit node.
We’ll document what you, the everyday user, should know about what this company’s SDK does on your devices — your phone and your smart TV. We’ll explore how their SDK works, which platforms have shipped it, and why your web-connected TV is the ultimate proxy for AI models looking to train on scraped web data.
Why This Matters Now
AI companies rely on web-scraped content: for pre-training, for retrieval, for agent grounding, for search. But the public web isn’t easily scrapable from a datacenter. Cloudflare, DataDome, and HUMAN all 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 various sources is fueling unprecedented-scale data harvesting efforts tied to AI projects. The FBI issued a formal advisory earlier this year.
Much of the press coverage has focused on the illegal residential-proxy supply: botnets, trojanized apps, and pre-infected IoT hardware. Bright Data, however, operates on the legal supply side — its 150M+ IPs are sourced through a consent SDK embedded in partner apps. This analysis 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 — aka Smart TV — is a near-perfect residential proxy. Compared to a mobile phone:
| Factor | Phone | Smart TV / CTV |
|---|---|---|
| Power | Battery most of the day | Always plugged in |
| Network | WiFi + cellular | Always WiFi, high-speed |
| Uptime | Intermittent | 24/7 in standby |
| Bandwidth ceiling | Low (cellular caps) | Effectively unlimited |
| User attention | Actively used | Often unattended |
| Consent UI | Text on a phone screen | Text navigated via TV remote arrow keys |
| Company/family oversight | Higher (MDM, mobile EDR) | Almost none |
A TV never hits 1% battery, jumps between WiFi networks, or gets locked when the user is asleep. Some partner publishers disclose the Bright Data relationship in their privacy policies, but privacy-policy disclosure is a poor control surface for a TV. It’s hard to scroll through a legal document navigated by arrow keys on a remote.
Bright Data’s Partners
Bright Data exposes a partner manifest endpoint that is unauthenticated. Identifiable partners include:
- PlayWorks Digital Ltd — 400+ CTV game titles; reaching ~250M TV homes through Comcast, Sky, Cox, LG, Samsung, Vizio, Roku
- CloudTV — Built into 125+ TV brands and 15+ OEMs
- Longvision Media HK (LongTV) — 5M OTT customers across Hong Kong and Malaysia
- Viber Media (Rakuten) — 250M-820M monthly users of Viber messenger
- Supercent (Korea) — #1 Korean mobile publisher by downloads in 2023
- Moonfrog Labs (Stillfront subsidiary) — ~10M MAU on Teen Patti Gold alone
- Hola Networks — Bright Data’s parent company; user base reported in the tens to ~100M+ range
The manifest confirms that at least three CTV-focused entities monetized their users’ devices as residential proxy exit nodes. PlayWorks in particular reports CTV distribution across every major TV platform and ISP, with reach figures in the hundreds of millions of households.
How the SDK Turns Your Device into a Proxy Exit Node
The Bright Data SDK is a publicly documented commercial product. What follows builds on public documentation with findings from reverse-engineering the shipping iOS framework and instrumenting 30 days of its runtime traffic.
The Unauthenticated Config
On each launch, the SDK calls an endpoint with the app bundle ID and SDK version as parameters. The endpoint is unauthenticated — provide these two values and any random UUID, and the server returns the same response a real device gets: feature flags, idle detection thresholds, per-country bandwidth tiers, and the partner manifest.
The Tunnel
After config retrieval, the SDK opens a persistent WebSocket to proxyjs.brdtnet.com:443. The TLS certificate uses the CN for Luminati Networks — Bright Data’s pre-2018 company name. The server requires no authentication to connect and immediately begins a handshake that establishes the session, assigns an identifier, and polls the device for its idle status, battery, network type, and available bandwidth.
Once the device reports favorable conditions, the server pushes scraping job instructions that the SDK executes as HTTP requests against third-party sites, using the user’s residential IP as the source.
When the SDK Considers You Idle
The config ships an explicit rulebook:
- Relay even with the screen on
- Relay while the user is on a phone call
- Minimum battery: 20%
- Maximum CPU usage: 70%
- Maximum memory usage: 90%
The key finding: 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.
VPN Bypass
The SDK constructs its network connection with a specific required interface — en0 (WiFi) or pdp_ip0 (cellular) — rather than using the system default route. On iOS, this bypasses any configured VPN’s tun0 interface entirely. The tunnel does not cross a user-configured VPN, even when the rest of the app’s HTTPS traffic does.
The SDK uses two independent inspection bypasses, one per plane:
- Control plane (config, telemetry): Built on CFNetwork primitives rather than URLSession, defeating URLSession-level instrumentation
- Data plane (tunnel): Built on NWConnection with the physical interface required, defeating VPNs
Geography Tiers
The config ships per-country bandwidth thresholds. Devices in Uzbekistan and Oman are allowed to relay down to 1% battery, with daily caps 20x the default. Qatar and UAE devices are throttled below default. The default worldwide allowance permits 500 MB of third-party traffic per month over the user’s home connection.
Protection Approaches
Three approaches to detect and block the tunnel, ordered by ease of deployment:
Method 1: DNS Block
Block these hostnames at your router:
- proxyjs.brdtnet.com
- proxyjs.luminatinet.com
- proxyjs.sharp-sdk.com
- clientsdk.sharp-sdk.com
- clientsdk.brdtnet.com
Method 2: TLS SNI Filtering
Drop or alert on TLS handshakes where server_name matches *.brdtnet.com, *.luminatinet.com, or *.luminati.io. Works at the network boundary without TLS inspection.
Method 3: TLS Certificate Fingerprint
Block by certificate fingerprint for the known domains. Valid until Sectigo cert rotation (current certs valid through mid-2026).
For managed fleets, the complementary control is MDM-based app binary scanning: search installed apps for Swift symbols BrdWebSocketFacade and BrdNetwork.DNSResolver, and prohibit apps containing them on company-issued devices.
This blog post was written in partnership with independent security researcher Buchodi.
