Where Your Residential IPs Come From Is Now a Procurement Question

On 3 July 2026, Google's Threat Intelligence Group published a post titled "Google's Continued Disruption of Malicious Residential Proxy Networks." It names NetNut, a commercial residential proxy provider that GTIG also tracks as Popa. Google says it acted "in coordination with the FBI, Lumen, and others" and lists what it did: disabled Google accounts and services NetNut used for malware command and control, shared technical intelligence on NetNut's software development kits and backend C2 infrastructure with platform providers and law enforcement, and set Play Protect to warn users about and disable applications known to incorporate NetNut SDKs. GTIG puts the network at "at least 2 million devices, distributed across the world," and says the action reduced the operator's available device pool "by millions."

That post was not the first. It builds on a 29 January 2026 GTIG post on IPIDEA, which Google called one of the largest residential proxy networks in the world. That earlier action named thirteen ostensibly independent proxy and VPN brands that Google attributed to the same operators, including 922 Proxy, ABC Proxy, IP2World, Luna Proxy, PIA S5 Proxy and PY Proxy. Google partnered with Cloudflare to disrupt the group's domain resolution and reported that in a single seven-day window in January 2026 it observed over 550 tracked threat groups routing through IPIDEA exit nodes.

Two takedowns in six months, both aimed at the supply side of the residential proxy market, is a pattern. And the thirteen-brands detail is the one that should change how a data team buys.

The supply chain nobody diagrams

A residential pool is not infrastructure the vendor owns. It is an aggregate of other people's home connections, and the mechanism for getting there is almost always a software development kit compiled into a consumer application. The app developer gets paid for bandwidth instead of running ads. The proxy operator gets exit nodes. The user, in the version that works, is told what is happening and agrees to it.

Google's description of NetNut's method is worth reading literally, because it describes the same mechanism operating without the consent step: "NetNut populates its botnet by distributing SDKs for devices commonly found in homes, such as smart TVs and streaming boxes." GTIG adds that home devices join proxy networks "either because they are pre-installed with malware before purchase or because users unknowingly download applications containing hidden proxy code," and that it identified NetNut plugin components inside Badbox 2.0.

The technical delivery is identical to the legitimate version. The difference is entirely in disclosure and consent. Nothing on a vendor's dashboard distinguishes the two, so the only place the check can happen is diligence.

Some vendors in the proxy networks category do describe the mechanism openly. Massive publishes a five-step diagram of it on its homepage, and states that "every IP comes from someone using an app they love, who opted in to share a slice of bandwidth and earns for it," listing "verified consent" and "KYC on every client" among its compliance controls (observed 27 July 2026). PacketStream runs the simplest variant: a desktop app that peers install directly, paying them $0.10 per GB of customer traffic and selling that bandwidth on at $1.00 per GB with a $50 minimum, per its own site on 27 July 2026. Peers can "stop or uninstall the app at any time."

Others describe the shape without the detail. Infatica markets "40M ethically sourced proxies across 195 countries" and operates what it calls the Infatica SDK, "a peer-to-business ecosystem," but its homepage delegates the sourcing specifics to a handbook PDF rather than stating them inline. IPRoyal publishes a dedicated sourcing page saying it sources residential IPs "through its direct partner" Pawns.app, "as well as through established IP service provider partnerships," and maintains a separate KYC policy page. Naming the peer app is more than most do. It still leaves the consent screen text, the payout terms and the opt-out path undocumented on the public page.

For the larger vendors, including Bright Data, Oxylabs, SOAX and Evomi, I could not verify a public sourcing disclosure at a guessable URL on 27 July 2026, which is not evidence that none exists. Several of these companies have published compliance material in the past. The point is that a page you cannot find in two minutes is not a page your procurement process can rely on, and the answer belongs in a contract anyway.

Your exposure is operational before it is legal

The enforcement actions land on operators. Google disabled NetNut's accounts and seized IPIDEA's domains through partners. Neither post describes action against the companies that were buying bandwidth from those pools. On the current record, a buyer's direct legal exposure from a supplier's sourcing practices is real but secondary, and it mostly runs through contract and reputation rather than through prosecution.

The operational exposure is immediate and much easier to quantify. Google says both actions reduced the available device pool by millions. A pool that loses millions of exit nodes does not degrade politely. Success rates fall on the hardest targets first, geographic coverage thins unevenly, and the vendor's status page will describe it as elevated error rates. If that happens during a scheduled collection window, the window is gone. You cannot re-scrape a price on a date that has passed, and a gap in a time series is not something a later run can repair.

Which puts sourcing in the supplier-continuity review rather than the ethics appendix. A vendor whose pool depends on one SDK partner, or on a partner whose apps are one Play Protect update away from being disabled, is a single point of failure sitting underneath your pipeline. Concentration risk in the pool is the same class of problem as concentration risk in the vendor list, and it deserves the same answer: failover across more than one supplier, tested before you need it.

Questions that fit in a procurement form

Ethics arguments do not survive contact with a purchasing process. Questions do. These are answerable in writing, and a vendor's willingness to answer is itself the signal.

• What SDK, and in which apps? Ask for the name of the peer app or SDK and a representative sample of partner applications. Massive and IPRoyal answer the first half publicly. Most vendors will answer under NDA.
• What does the consent screen say, and when is it shown? Ask for a screenshot of the actual dialog a user sees, not a policy summary. Consent presented at install differs materially from consent buried in a terms update.
• How does a peer leave, and how fast? Uninstalling the app is the floor. Ask whether there is an in-app toggle and how quickly a departed device stops receiving traffic.
• How is the peer compensated? A disclosed payment, in cash or in app features, is what distinguishes a monetisation deal from hidden code. PacketStream's $0.10 per GB is unusual only in being published.
• What share of the pool comes from your largest single partner? This is the continuity question. A vendor that cannot answer it does not know its own concentration.
• What happens to my success rate if that partner is removed? Ask for the runbook, not a reassurance.
• Do you KYC your customers, and what use cases do you refuse? A vendor that screens buyers is a vendor that has something to lose.

That last one gets resisted internally more than it should. KYC on the buy side feels like friction: forms, a call, a delay before your first request. It is the cheapest available signal that a supplier expects to still exist in two years. Providers who accept anonymous crypto payment for unlimited residential bandwidth are optimising for a customer base you do not want to share an IP range with, and shared reputation is exactly how rotating residential exits work. Their blocks become your blocks.

What to actually do

Add three sourcing questions to whatever vendor evaluation template you already use, and put the answers in the contract rather than the sales thread. Ask for written notice of material changes to pool composition, in the same clause where you ask for notice of price changes. Get pricing structure and sourcing disclosure from the same conversation, since a vendor that will discuss one and not the other is telling you something.

Then assume disruption anyway. Keep a second residential supplier provisioned and periodically exercised, so a degradation event is a config change instead of a procurement cycle. Record which vendor served each collection run, because if a pool is disrupted you will want to know which of your historical data came through it. And when a contract renews, re-ask the concentration question. The answer moves.

Do the work for the boring reason: losing a quarter of collection is an expensive way to find out that a supplier you never diagrammed had one bandwidth partner and lost it. The background on how these pools are assembled is worth reading once. The contractual angle on supplier obligations is worth reading before you sign.