Smart TVs have traditionally been analyzed as video distribution devices, advertising surfaces, and increasingly valuable sources of data within the Connected TV (CTV) ecosystem. However, recent decisions by LG and Samsung to ban certain applications have brought attention to something far less visible: the ability to transform a household television into a network node used by third parties.
The origin of the issue lies in so-called residential proxy SDKs, software components that some developers had integrated into television applications.
An SDK (Software Development Kit) is simply a collection of libraries and tools that a provider offers to incorporate specific functionality into another application. In digital advertising, for example, we are used to SDKs for measurement, video delivery, or monetization. In this case, the SDK enabled a television's Internet connection to be used as part of a residential proxy network.
Research conducted by cybersecurity firm analyzed more than 6,000 Smart TV applications and found this technology to be widely distributed. According to data later reported by , more than 42% of the applications analyzed on webOS and more than 25% of those available for Samsung televisions contained code related to these networks.
The issue led first LG and then Samsung to change their policies and begin removing apps that included this functionality. Samsung confirmed in August 2026 that it had restricted new apps using this type of SDK and was identifying existing ones to remove them from its platform, according to .
But the interesting part is not simply that a television can “share Internet access.”
What truly matters is understanding what it technically means to turn a Smart TV into a residential proxy and what consequences this has for Internet architecture, cybersecurity, and especially for AdTech and CTV.
A proxy is an intermediary between a client and a server.
In a normal connection: User → Web server, the server sees the IP address from which the user is connecting.
With a proxy: User → Proxy → Web Server, the server mainly sees the proxy's IP address.
In a residential proxy network, that intermediary node is located within a real residential Internet connection.
The traffic flow may look like this:
ISP stands for Internet Service Provider, that is, the company that provides Internet access, such as Verizon, AT&T, Deutsche Telekom, and others.
As a result, the server at the end of the chain sees a request that appears to originate from a genuine residential connection. The television acts as what is technically known as an exit node: the final device in the proxy network before traffic reaches the public Internet.
And that is precisely where its value lies.
Security systems have relied for years on IP addresses and the networks they belong to as one of many signals used to classify traffic.
Every Internet provider owns one or more ASNs (Autonomous System Numbers), identifiers used on the Internet to represent large networks managed by a specific organization. Amazon, for example, has ASNs associated with AWS. Google has its own. So do Verizon, AT&T, Deutsche Telekom, Movistar, Orange, and many others.
This allows analysts and security systems to determine whether an IP address belongs approximately to:
or to:
This does not necessarily identify an individual, but it does provide information about the type of infrastructure from which a connection is originating.
An automated process sending hundreds of thousands of requests from an Amazon AWS server can be relatively easy to identify because all traffic originates from IP ranges associated with cloud infrastructure.
This is one reason why scraping services, automation platforms, and malicious actors may use residential proxies.
Instead of:
they can obtain:
From the website's perspective, the request may then appear to come from a normal household Internet connection. The IP address is real. The Internet provider is real. The geolocation is reasonably accurate.
What may no longer be real is who is actually generating the traffic.
A modern television combines several features that make it particularly attractive for this model. It is permanently connected to the Internet, can remain on or in low-power states for long periods, typically uses a fixed residential connection, and can remain installed for many years. Moreover, a modern Smart TV is technically much closer to a computer than it might appear.
Samsung uses Tizen, while LG uses webOS. Both are operating systems capable of running applications, executing JavaScript code, establishing network connections, and communicating with remote services.
An application can therefore establish outbound connections to the Internet just like a mobile app or a web browser.
And, most importantly, users rarely monitor what is happening on their television's network connection.
If a computer starts consuming CPU, battery, or bandwidth, we will probably notice it eventually. On a television, it is much less obvious. This makes the device extremely attractive for maintaining persistent network connections in the background.
The most interesting investigation into how this works internally was conducted by Norwegian cybersecurity company .
Its researchers analyzed Samsung televisions and found applications that incorporated technology from Bright Data, one of the largest commercial residential proxy providers. One of the most striking cases involved a Pac-Man game distributed through Smart TVs that had even appeared in Samsung's “Editor's Choice” section.
But there is a fundamental nuance here.
Finding an SDK inside an application does not automatically mean that the television was operating as a proxy.
Mnemonic observed that the component could remain inactive and be activated later through remote configuration.
Conceptually, the architecture could work like this:
The decision to activate certain functions can therefore be made remotely through infrastructure, rather than necessarily being permanently encoded within the installed application.
This brings us to a considerably more important problem than the proxy itself. Many CTV applications are actually shell applications: extremely small applications that function as containers. The package installed from the app store may contain little more than a Bootstrap, a small piece of initial code whose purpose is to connect to a server and subsequently download content, configuration, or even much of the application's logic.
To put it simply:
Installed Application → Local Bootstrap → Remote Server → JavaScript / Configuration / Content → Final Behavior
This makes it possible to update an application without having to constantly redistribute new packages. It is a perfectly common architecture and is not inherently malicious.
The problem arises with the security model used by app stores. Suppose Samsung reviews an application before publishing it.
The manufacturer inspects version 1.0 and determines that it is safe.
However, when the application runs weeks later, it downloads JavaScript or configuration from:
The developer can subsequently modify that file without necessarily submitting a new version of the application to the store.
Mnemonic's conclusion is particularly relevant:
what was reviewed does not necessarily have to be exactly what is later running on the television.
TechCrunch confirmed that many of the applications investigated were precisely these kinds of minimal shells that loaded their functionality from external servers. From a security perspective, this makes static application review an insufficient control. Manufacturers may also need to observe their runtime behavior, that is, what the application actually does while it is running.
Following the investigations, both LG and Samsung decided to cut off this monetization channel.
Samsung confirmed to TechCrunch that it had restricted new application registrations that incorporated proxy functionality, was developing specific policies targeting residential proxy SDKs, and was working to identify and remove existing applications containing them.
The decision is important because it shifts the issue from user consent to platform governance. A proxy provider can argue that the user has given consent. A developer can claim that users have been properly informed.
But manufacturers are taking a different approach: certain capabilities simply should not be part of a Smart TV's monetization model.
And this is probably the most relevant question for the future of CTV. The television is no longer just a screen.
Today, we have:
Operating System → Apps → Background Processes → SDKs → Remote Code → Persistent Connections → Advertising Infrastructure
The result is a complete computing platform permanently embedded within millions of residential networks. This also means that its security model needs to evolve.
Until now, the traditional app-store model could be understood as:
But applications capable of dynamically changing their behavior require something closer to:
In other words, it is not enough to analyze what an application contains when it is published.
We need to observe what it actually executes, which servers it communicates with, what code it downloads, which processes it keeps running, and how its behavior changes over time.
That is probably the most important technological lesson from this entire case.
Residential proxies are the symptom.
The underlying problem is that the Smart TV has become a much more complex computing and networking infrastructure than the traditional platform-control model still reflects.
And for AdTech, there is also an immediate consequence.
For a long time, a residential IP address could be used as a reasonably strong signal that there was a household behind it.
In today's Internet, that inference increasingly requires more context. Because behind a residential IP address there may be a user. There may be a device. There may be a bot.
Or there may be a Smart TV carrying traffic generated thousands of kilometers away.
At tvads we has a professional team able to advise you on this field and and guide you in any area of your streaming advertising business, advising you or even operating it on your behalf if necessary
All author posts