Everyone worries about the apps on their phone. Almost no one looks at the ones on their TV. We scanned 6,038 of them across LG and Samsung; 2,058 were selling your IP address.
On screen, it's a relaxing fish tank. Or a clock. Or solitaire. Or puppies. Under the hood, it is a residential proxy: software that can send other people's internet traffic out through your living room. And we found it everywhere.
Smart TVs are almost ideal proxy hosts. They sit on the same home network as everything else, but they do not feel like computers, so people rarely audit them like computers. There is no battery drain to notice, no cellular bill to spike, no app switcher full of suspicious background activity. A TV can stay plugged in, signed in, and online for years while the user thinks of it as furniture.
That changes the consent equation too. Most people do not have a working mental model for what it means to sell access to their residential IP address, no matter what device they are using. On a TV, the gap is even wider: a one-time prompt navigated with a remote can disappear into the setup flow, while the app keeps monetizing the connection long after anyone remembers what they accepted.
The answer is money. Ads need attention, but when you insert ads it degrades the user experience. These apps are designed for the opposite: a clock, a fish tank, a quiet screen that doesn’t bother you with constant ads. Add a proxy SDK and the app can keep looking calm while the TV's internet connection makes money in the background.
Below are what these companies consider consent for their proxy SDKs. They ask once, and then never again.
The background clause is the part that matters: all three prompts say the proxy can keep running after the app is closed. The app goes away. The proxy does not.
Some apps make the trade-off even more explicit. Pac-Man on Tizen frames Bright Data as the ad-free option: decline and you keep the ad-supported game, accept and the app gets to use the TV's connection for web indexing. That is a clean little monetization fork: watch ads or become part of the proxy network.
This is not just a story about proxy companies convincing random app developers to embed a monetization SDK. In a lot of cases, the proxy company, or something wearing its name, appears to be the publisher too.
Bright Data, Bright Data Ltd, and Bright SDK account for 367 proxy-flagged apps in the dataset. Honeygain UAB (subsidiary of Oxylabs) shows up as the publisher on another 16.
That changes the shape of the problem. Some of these are not normal apps that happen to have a proxy SDK inside them. They look more like first-party proxy inventory: thin shovelware games, screensavers, and utility shells shipped at scale so the SDK has somewhere to run. The app is the wrapper. The residential IP is the product.
Other TV platforms have already drawn a line. Amazon makes it explicit: its Device and System Abuse Policy prohibits apps that facilitate proxy services for third parties. Roku has reportedly shut the door too: Lowpass, syndicated at The Verge, reported that Roku bars developers from using Bright SDK and similar proxy services, and that Roku apps using the SDK disappeared after the company was contacted.
LG and Samsung have not drawn an equivalent public line. That is the gap these apps are living in. The same business model that Amazon bans and Roku reportedly blocks is still showing up at scale on webOS and Tizen.
Once a TV app can act as a proxy, the risk is not limited to someone borrowing your public IP address. The app is running inside your home network. If the proxy provider decides to allow requests to private or local addresses, or if their filtering fails, that TV becomes a foothold for reaching things that were never meant to be exposed to the internet: router admin panels, NAS devices, printers, cameras, developer machines, and other apps listening on local ports.
This is not theoretical. In January 2026, KrebsOnSecurity reported on Kimwolf, a botnet that abused residential proxy networks to tunnel back into the local networks behind proxy endpoints. The report describes attackers using proxy access not just for public-web traffic, but to reach devices on the same LAN as the proxy node and spread further from there.
The SDKs make that boundary visible. The Bright Data sample ships with an explicit private/local blocklist: `127.0.0.0/8`, `10.0.0.0/8`, `172.16.0.0/12`, `169.254.0.0/16`, `192.168.0.0/16`, and `255.255.255.255`. That is good to see, but it also proves the point: the TV can make the connection; the boundary is the SDK's policy code.
In the Massive sample, the proxy session parses a server-supplied `host:port` value and opens a `net.Socket` to it. In the Honeygain/Oxylabs sample, a server message with `messageType: "connect"` supplies `address.host` and `address.port`, and later chunk messages write bytes into that connection. In the local Massive and Honeygain/Oxylabs samples, we did not find a comparable private-range blocklist.
That makes the provider's policy and enforcement the real boundary. The boundary is not technical; it is enforced by the proxy company's customer vetting, traffic filters, internal rules, and whatever platform review LG or Samsung choose to apply. Proxy providers can say the traffic is limited to approved public-web use cases, but the device owner has no practical way to verify that from the TV. If that boundary changes, breaks, or is abused, the same SDK that was framed as "web indexing" can become a cybercriminal's personal VPN connection into your home network.
We did not rely on store descriptions or permission prompts. We downloaded the actual LG webOS and Samsung Tizen app packages, unpacked them, and scanned the files inside.
The fingerprints looked for confirmed SDK artifacts: Bright Data `brd_api.js` and `brd_sdk` services, Massive clients and `.massivesdk` services, Honeygain/Oxylabs SDK files and service names, and related tokens or package names. Every app counted there had a confirmed proxy SDK fingerprint.
Prior to publication, Spur Intelligence Labs shared its findings with Bright Data, Massive, and Oxylabs and invited each company to comment. All three organizations responded. Their responses are summarized below.
"Consent separates a legitimate network from a nefarious one, and is provable across a tested framework that outlines transparent and compliant sourcing, vetting, governance, and accountability. Bright Data built this framework for consented networks that are intentionally discoverable and therefore accountable. Our practices are scrutinized by independent auditors and security companies. Use is only approved for legitimate and verified business, research, and journalistic purposes. Our intent is to protect our network, our customers, and the internet as a whole. We encourage the entire industry to follow.”
“We pride ourselves on being privacy- and security-focused from the consumer side. While it's true that the device owner has no practical way to verify this, that is in part by design: the endpoint is intended to have minimal impact and a minimal interface to the user, for their own peace of mind. We previously included sliding controls that let users enable additional resource utilization, but in practice these effectively performed a self-inflicted denial of service, which users then attributed to the product. So, for user safety and stability, participation is now a simple enable/disable choice.
“Users of our network go through a Know Your Customer (KYC) process to validate that they have a legitimate business purpose. Technical controls are primarily server-side, as we do not perform man-in-the-middle traffic decryption or monitoring, which would introduce its own security and liability concerns.”
Oxylabs stated that it restricts access to private and local network ranges through multiple technical controls at both the infrastructure and SDK levels, including filtering, traffic inspection, and local blocklists. The company noted that SDK updates may take time to propagate to deployed smart TV applications due to app store review processes.
The company further stated that only approved applications distributed through its Honeygain SDK Partnership Program are eligible for inclusion in its proxy network.
Oxylabs also reported that its controls have been independently assessed through third-party penetration testing and security audits, including testing focused on preventing local network access. The company emphasized that technical controls are supplemented by customer vetting, KYC processes, governance controls, and ongoing monitoring.
A TV app should not be able to quietly turn a living-room device into residential proxy infrastructure. Screensavers, games, clocks, and novelty apps can be boring, cheap, or ad-supported. If an app is going to monetize a household’s internet connection, the user should be clearly informed about what that means, how the connection will be used, and what risks and tradeoffs they are accepting.
The problem is not that residential proxy networks exist. It is that they are being embedded at scale in devices that most consumers do not think of as computers and are not equipped to audit. A one-time consent prompt buried in a TV app is not a substitute for meaningful transparency, ongoing control, and platform oversight. The risk is amplified when consent comes from individuals within the household who use the device but shouldn’t give consent, such as minors.
Amazon bans this category of software, and Roku reportedly blocks it. LG and Samsung could choose a different path, but they should at a minimum establish clear policies governing residential proxy SDKs, require prominent disclosure and user controls, and scrutinize apps that relay third-party traffic through consumer devices. The app goes away. The proxy does not. Platforms should ensure that users understand that distinction before they are asked to participate. Equally, consumers need to be mindful of the opportunity for their home networks to be leveraged by third parties through devices otherwise considered benign, such as smart TVs.
The proxy providers contacted for this research emphasized customer vetting, traffic restrictions, and abuse-prevention controls. Those controls may reduce risk, but they do not change the underlying reality that residential proxy infrastructure is being embedded at scale in devices that most consumers do not recognize as participating in such networks.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。