LG can remove every residential proxy SDK from its television app store. That may protect households and make one source of proxy capacity harder to operate. It will not make the next residential IP arriving at a login page trustworthy.
The distinction is easy to lose in the argument over smart TV apps. Consent governs how a device joins a proxy network. App-store policy governs one way the software reaches that device. Neither tells a website whether the next request from that household connection originated inside the household.
That is the part security and fraud teams have to operate.
The App Store Had a Real Problem
Spur Intelligence Labs downloaded and inspected 6,038 LG webOS and Samsung Tizen app packages. It found confirmed residential proxy SDK fingerprints in 2,058 of them. More than 42% of the LG apps were affected.
The apps included games, screensavers and utilities. Some presented a choice between advertising and sharing the television's connection. Spur also found consent language saying that proxy activity could continue after the app closed.
LG's response was direct. The company told KrebsOnSecurity that developers must remove the residential proxy option from their webOS apps or have those apps suspended. It also said it would strengthen its evaluation of developer submissions.
That is a reasonable platform control. A television is shared household equipment, not a personal phone that one adult necessarily administers. A one-time prompt does not show that the person holding the remote owns the internet connection, understands persistent background operation or still remembers the decision months later.
Removing the SDK reduces that exposure. It does not turn residential traffic back into direct traffic.
Consent Describes Enrolment
A meaningful consent record can establish something important: an authorised person knowingly allowed a particular device and software version to share resources under a stated set of terms.
That is a higher standard than a buried clause or software installed without the device owner's knowledge. It should include a plain explanation, an affirmative choice, a visible participation state and a withdrawal path that actually removes the device from every pool receiving its capacity.
Even strong consent has a boundary. It does not show who later bought access to the connection. It does not prove that customer vetting worked, that destination restrictions held or that the request now reaching a website is harmless.
There are at least three relationships involved:
- The device and network owner decides whether the connection may be shared.
- The proxy provider decides which customers and uses it will permit.
- The destination decides what a relayed request may do to an account, transaction or API.
Consent speaks to the first relationship. Provider controls speak to the second. Neither can make the third decision on the destination's behalf.
Consent can make the supply relationship consensual. It cannot make every request using that supply legitimate.
An App-Store Ban Describes Distribution
App stores can remove applications, reject updates and block known SDKs. Those actions matter because they can reduce supply, protect device owners and raise the cost of enrolling more endpoints.
The policies are not all the same. Amazon's Device and System Abuse Policy prohibits apps that facilitate proxy services to third parties. Google Play permits proxy services only when proxying is the app's primary, user-facing core purpose. LG has chosen to remove residential proxy functionality from webOS apps.
Each rule governs software distributed through that platform. None covers every route by which a household connection can become a proxy exit. Capacity can also come from software on phones and computers, applications obtained elsewhere, compromised routers, infected streaming devices and pre-installed software. Our investigation into how bandwidth sharing feeds residential proxy networks follows those supply paths separately.
A store can close its door. It cannot certify that an address seen by an unrelated website is no longer available through another device, supplier or reseller.
The Provider Can Disappear While the Addresses Remain
The July 2026 action against NetNut makes this distinction measurable. Google, the FBI and industry partners disrupted accounts, applications and domains associated with the network. Google said the action caused significant degradation and reduced the available device pool by millions.
Layer3 Intel then measured what happened to the observed exit inventory. Its NetNut takedown analysis reported a 99.92% fall in unique NetNut exit IPs observed per hour by 5 July. At the branded network layer, the service had collapsed.
The address layer told a less tidy story. Of the IPv4 addresses observed through NetNut in its final one to two days, 78.81% appeared through other proxy networks during the following 14 days.
That result does not prove that the same televisions, routers or other devices moved between providers. Public IP addresses change, multiple devices can share an address through carrier-grade NAT, and several suppliers or resellers may expose overlapping inventory. Layer3 Intel also estimated, after applying its selected June baseline, that about 1.06 million fewer addresses reappeared than ordinary churn predicted. The takedown had a measurable effect.
The bounded conclusion is still useful: a provider name can almost disappear while much of its recently observed public-address inventory remains visible elsewhere. Our analysis of the measurement sets out what that overlap can and cannot establish.
Provider identity is not a stable security boundary. App-store presence is not one either.
The Destination Sees the Last Step
The website receiving the traffic cannot inspect the television, recover the consent screen or ask which app store approved the software. It sees the end of a longer chain:
device -> public IP -> supplier -> proxy pool -> reseller -> buyer -> destination
Most of that history is hidden at request time. The destination can observe the connection, the client and the work being attempted.
A request from an Australian residential ISP may belong to a customer at home. It may also be a request sent from another country and relayed through that connection. The address locates the exit. It does not authenticate the operator.
Peakhour therefore treats residential proxy detection as evidence inside the request decision. It sits beside credentials, account state, network and client fingerprints, route sensitivity, behaviour and recent outcomes.
The same proxy observation can support different actions:
- Opening a public, cached page may require no intervention beyond recording the signal.
- Trying one password across many accounts may justify a shared rate limit or block.
- Changing a recovery email from a first-seen client may require stronger verification.
- Repeating expensive API work across rotating addresses may call for a limit keyed on the credential, client and route rather than the IP alone.
The proxy result changes how much evidence the service requires. It does not select the action by itself.
A Compliant Path Still Has Value
The limits of consent do not make consent unimportant. The limits of app-store enforcement do not make enforcement pointless.
If a platform permits bandwidth-sharing software, it should demand more than a provider's assurance that users opted in. A credible path needs authoritative and recurring consent, a persistent participation indicator, effective withdrawal, buyer and use-case controls, private-network protections, supplier and reseller lineage, incident handling and independently testable records.
Those controls can distinguish accountable supply from hidden or compromised enrolment. They can protect households and make abuse harder. They cannot guarantee that no residential connection will carry a proxy request, and they cannot tell a destination what to do with the request already in flight.
The mistake is expecting one control to answer a question it cannot observe.
Consent answers whether a device was knowingly enrolled. An app-store decision answers whether a distribution channel permits the software. The destination still has to decide whether the request may log in, reset an account, buy limited inventory, scrape an API or consume expensive origin work.
That decision belongs on the request path, using current evidence. A residential address tells us where the request left the network. It does not tell us who initiated it or what they intend to do.
For the operating model, read A Proxy Flag Is Not a Security Policy and A Proxy Takedown Is Not a Security Control.
