Samsung Banned the SDK Category That Turned an Editor's-Choice Pac-Man App Into a Residential Proxy. If You Monetize an App With a Third-Party SDK, Check Yours.
TechCrunch reported on August 3 that a number of popular Samsung smart TV apps contained code quietly turning the TV into a residential proxy exit node, routing strangers' internet traffic through the owner's home connection. One of the apps involved was a licensed Pac-Man game sitting in Samsung's own Editor's Choice section, curated and promoted by the platform itself. Samsung's response was to ban residential-proxy SDKs platform-wide, freeze new registrations carrying the functionality, and start pulling existing offenders. LG made a near-identical move a month earlier. If you monetize a mobile or TV app through a third-party SDK, this is worth ten minutes of your afternoon.
What actually happened
The apps didn't build proxy infrastructure themselves. They bundled a third-party SDK — a "resproxy" SDK — that sells the device's IP address and bandwidth to outside buyers, who route their own traffic through it. From the perspective of anyone else on the internet, requests routed this way appear to come from an ordinary residential IP address instead of a datacenter, which is exactly what makes residential proxy networks valuable, and exactly why they're increasingly linked to fraud, scraping evasion, and other traffic that platforms and websites specifically try to block. The TV owner has no visibility into any of it. Their connection just quietly does double duty.
The Editor's Choice detail is the part I'd sit with longest. This wasn't a sideloaded app from an unverified developer or a sketchy third-party store. It was inside Samsung's own curated section, the storefront's explicit signal that this app had been reviewed and was safe to install. Researchers describe proxyware SDKs spanning thousands of apps across multiple smart TV platforms, which tells you this isn't one bad actor slipping through — it's a category of monetization SDK that a meaningful number of app developers integrated, likely without fully understanding what it does once installed.
How this actually gets into an app
Ad and analytics SDKs are how a lot of free apps make money, and the developer integrating one typically evaluates it once, at integration time, based on what the SDK claims to do and what the terms of service say then. SDKs update. Behavior can change in a later version without the app developer re-reading anything, because from the developer's side, it's just a dependency bump like any other. A monetization SDK that starts as "show ads, report analytics" can add proxy functionality in a later release, and the app developer who bundled it originally may never notice, because nothing about their own code changed. The revenue check clears the same as always. The behavior underneath it doesn't.
This is structurally the same problem as any supply-chain risk: you audited the thing once, and you're trusting that audit still holds months or years later, for a component you don't control and don't get notified about when it changes.
Why this matters even if you don't build for smart TVs
The specific platform here is Samsung TV, but the mechanism generalizes to any app monetized through a bundled third-party SDK — mobile included. If you've got an app in the App Store or Play Store making money through an ad network, an analytics SDK, or any "monetize your app in five minutes" integration, the question worth asking isn't "did I check this SDK when I added it," it's "do I actually know what it does right now, this version, today." Those are different questions, and most solo developers running a monetized app can honestly answer the first one and not the second.
The consequence isn't abstract. Apple and Google both pull apps for exactly this kind of behavior once discovered, and platform review doesn't distinguish between "I built this proxy functionality myself" and "an SDK I bundled added it without telling me." Your app is what gets removed either way. The SDK vendor's name doesn't show up on the App Store listing. Yours does.
What I'd actually do
Pull the list of every third-party SDK in every app you currently have live or monetized — ad networks, analytics, crash reporting, anything you didn't write yourself. For each one, check the vendor's current terms of service and any recent security research or news coverage naming that SDK, not just what you remember reading when you integrated it. If a vendor has had any reporting linking it to proxy, VPN-relay, or bandwidth-sharing functionality, at minimum read what changed and decide deliberately whether you're comfortable with the current behavior, rather than continuing to run it because updating hasn't broken anything visibly yet. This is maybe thirty minutes across an app or two, and it's the kind of audit that's boring right up until it's the reason your app got pulled.
The honest take
Most SDKs are exactly what they say they are, and most solo developers running an ad SDK from a known vendor have nothing to worry about. I'm not suggesting you rip out your monetization stack over this. What I am suggesting is that "I checked it once, at integration time" is doing more work in your mental model of safety than it should be, given that the actual behavior lives in a dependency you don't control and don't get warned about when it changes. Samsung and LG both had to find out from outside researchers and press coverage, not from their own review process, that curated, promoted apps were compromised in exactly this way. If the platforms with dedicated review teams missed it, "I checked it when I added it" isn't the bar to hold yourself to either.
Author
Lukas
@lukcombinator