Every provider asserts ethical sourcing about itself. Twelve questions to ask instead, four tests that need no trust, and what a deflection looks like.
· 18 min read · Provider evaluation
Search for ethically sourced residential proxies and you get a page of vendors asserting the badge about themselves. Every one of them says the IPs are consented. Not one of them publishes a method you could use to check — theirs or anybody else's.
This is that method. It is written in the second person because it is a buyer-side test, and it applies to every provider you will evaluate, including this one. Twelve questions to ask. Four tests that work whether or not the answers are honest. And the specific shape of a deflection, so you recognize one when it arrives.
For most of the last decade, "where do the IPs come from" was a question the compliance team never asked, because the proxy line item sat inside an engineering budget and nobody read it. That changed in July.
On 2026-07-02 the FBI and Google's Threat Intelligence Group disrupted the residential proxy network operated as NetNut, tracked by researchers as the "Popa" botnet (Krebs on Security). Google assessed the network had co-opted more than 2 million consumer devices globally (SecurityWeek).
Partners in the operation included Lumen Technologies, the Shadowserver Foundation and the IRS Criminal Investigation division (Infosecurity Magazine). The FBI said it worked with industry partners to seize hundreds of domains associated with the network, and netnut.com was replaced with a seizure notice from the FBI and the IRS Criminal Investigation division (Krebs on Security).
In a single week in June 2026, Google's Threat Intelligence Group observed 316 distinct threat clusters using suspected NetNut exit nodes (BleepingComputer). The action built on the January 2026 disruption of the IPIDEA proxy network (Infosecurity Magazine).
Set aside every question about who knew what. The operational consequence for a buyer is narrow and concrete: the exit path of your traffic is now a compliance surface, not a spec line.
Three things follow.
Your legal and security teams have a reason to ask where your proxy bandwidth comes from, and "our vendor says it is ethically sourced" is not an answer that survives being written down. Your continuity planning now has to include the possibility that a network your provider depends on stops resolving on a Thursday. And the diligence you do before signing is the only diligence you will ever get to do, because there is no auditor to appeal to afterward.
You cannot evaluate a sourcing claim without knowing what the possible answers are. There are four, and they sit on a spectrum from clearly consented to clearly not.
A person installs an application whose stated purpose is to share bandwidth. They are told what it does, they are compensated in cash, credit or points, and they can uninstall it. This is the model every vendor describes when asked, and it is the only one where the participant would recognize the description of what they agreed to.
A developer embeds a bandwidth-sharing SDK into an unrelated application — a game, a utility, a wallpaper app — and monetizes the user's connection instead of showing ads. Consent exists, in the EULA, at install time, in a paragraph about "sharing your internet connection with the network." It is real consent in the legal sense and it is invisible in the practical sense, because nobody reading a flashlight app's terms is thinking about becoming an exit node.
This is the model most residential pools actually run on, at scale, and the one where the gap between the disclosure and the participant's understanding is widest.
A free VPN, an ad-blocker, a download manager. The user came for the service, the bandwidth sharing is how the service is funded, and the disclosure sits somewhere between a checkbox and a sentence in a FAQ. Materially the same as the SDK model, with a stronger argument that the user received value.
Malware, covert SDKs shipped without the app developer's knowledge, and capacity bought from operators who do not ask. No consent at any layer. The device owner does not know, cannot check and has no way to leave.
The uncomfortable part for a buyer is that all four models produce identical traffic. A packet from a consented panel participant and a packet from a compromised smart TV are indistinguishable at your end. Which means the only thing separating you from the fourth model is the quality of the diligence you did, and the honesty of the answers you got.
There is one industry body in this space. The Ethical Web Data Collection Initiative (EWDCI), hosted by the i2Coalition, publishes a set of principles including a proxy commitment: "We commit to sourcing proxies ethically, with informed consent and in compliance with data protection standards" (EWDCI principles). Companies that pledge to work within that framework are awarded an EWDCI Certified designation, and the members are listed publicly.
Read that carefully, because the distinction matters more than the existence of the program:
None of that makes the initiative worthless — a published principle you can point at is better than a slogan, and a public member list is a real artifact. It does mean the badge is a commitment rather than a finding.
And the phrase itself is unregulated. "Ethically sourced residential proxies" is
a string any vendor can put in a <title> tag with no filing, no attestation
and no consequence. There is no registry of pool provenance, no chain-of-custody
document, and no way to trace an individual exit address back to the moment its
owner agreed to anything.
So stop trying to evaluate the claim. Evaluate the disclosure.
Send these to a named person, in writing, before you sign. The value is not only in the answers. It is in which questions get answered specifically and which get answered with a paragraph about the company's commitment to ethics.
Score the replies against this. Read the middle column as the artifact you are asking to be handed, and the right column as the sound a vendor makes when there is no artifact.
| # | Question | A specific answer contains | An evasion sounds like |
|---|---|---|---|
| 1 | Where do the IPs come from, named at the program level? | The panel brand, SDK product name or partner network, by name | "We use opt-in panels" |
| 2 | Can you see the consent flow a participant sees? | Screenshots or a live link, in the participant's language | A copy of the EULA text |
| 3 | Is compensation disclosed, and in what form? | The form, the amount, the frequency, and when it is shown | "Participants are compensated" |
| 4 | Can a participant opt out, and how long until their IP leaves the pool? | The mechanism plus a propagation time in hours or days | "Users can uninstall at any time" |
| 5 | Is there an SDK, and which applications embed it? | Named applications, or a stated contractual bar on naming them | "We do not disclose partner relationships" |
| 6 | Do you resell another network's pool, and will you say whose? | A named upstream, or an explicit no | Anything about the size or quality of "our network" |
| 7 | What is the abuse-reporting path, and what is the takedown SLA? | A named channel, a response time, a definition of resolved | A generic support address |
| 8 | Which target categories are prohibited, and is that enforced technically or only contractually? | A published category list, plus which entries fail at the gateway | "Prohibited by our terms of service" |
| 9 | What logs are kept, for how long, and who can compel them? | Retention in days, per log type, plus the disclosure process | "We do not log" |
| 10 | Is KYC required, and at what threshold? | The check performed and the volume or spend that triggers it | Treating the question as being about you |
| 11 | What happens to your sessions if an upstream network is seized? | Failover behavior, notification time, a status page with history | "We have redundancy" |
| 12 | Will they put any of this in writing? | An email you can forward, or a contract annex | Verbal agreement and no document |
Each question is unpacked below: what you are actually testing for, and why the deflection is the deflection.
You are testing whether they will name the actual acquisition channel: the panel brand, the SDK product name, the partner network. Not the model — the program. Deflection to watch for: a description of the model ("we use opt-in panels") with no name attached to it. Every provider can describe the model. Naming the program is the disclosure.
Ask for screenshots or a link to the live disclosure, in the language the participant reads it in. You are testing whether the consent is legible or buried. Deflection: a copy of the EULA text rather than the screen. The question is what the participant saw, not what they legally agreed to.
Cash, credit, in-app currency, ad removal, premium features. You are testing whether the exchange was explicit enough that the participant knew a trade was happening. Deflection: "participants are compensated." In what, how much, how often, and does it appear before or after installation?
Two numbers: how they leave, and the propagation delay. You are testing whether withdrawal is real or nominal. Deflection: "users can uninstall at any time." Uninstalling is not the same as being removed from the pool, and the lag between the two is the answer you asked for.
You are testing for the model most likely to be invisible to participants. A provider that runs an SDK and says so is being straight with you. Deflection: "we do not disclose partner relationships." That may be a genuine contractual constraint. It is also the answer that makes the rest of the checklist load bearing.
The most useful question on this list, and the one you will get the least direct answers to. Resale is normal and not disqualifying. Undisclosed resale means your diligence terminated one layer above where the IPs actually come from, and your continuity risk is attached to a company whose name you do not know. Deflection: any answer about the size or quality of "our network" that never addresses whose network it is. Ask it of every vendor. Ask it of this one.
A named channel, a response time, and what "resolved" means. You are testing whether abuse handling is a function or a promise. Deflection: a generic support address with no stated timeline.
Two different things. A contractual prohibition is a clause you sign. A technical enforcement is a request that fails. You are testing which one they have. Published restricted categories — government, banking and payment, traffic monetization, high-risk services — are the artifact to ask for; ours are at restricted target categories and restricted regions and prohibited use. Deflection: "prohibited by our terms of service," with no answer about enforcement.
Retention windows, in days, per log type, plus the legal process under which they are disclosed. You are testing whether their retention policy is compatible with your own data governance. Ours is stated in the published log retention section of the privacy policy. Deflection: "we do not log." Every gateway logs something, and a provider claiming otherwise is either wrong or answering a different question.
You are testing the provider from the other direction: how hard is it for someone with bad intentions to become their customer? A network with no identity checks at any volume has a different abuse profile from one that verifies above a threshold. Deflection: treating the question as being about you rather than about the population you share the pool with.
Ask for the mechanics, not the reassurance. Does traffic fail over, and to what? How is the change communicated, and how quickly? Is there a status page with history? You are testing whether they have thought about it since July. Deflection: "we have redundancy."
The final filter. An answer given on a sales call is worth nothing in twelve months when the person who gave it has changed jobs. Ask for the answers as an email you can forward to your legal team, or as an annex to the contract. Deflection: enthusiastic verbal agreement and no document.
Half of the evaluation should not depend on anybody's honesty. Run these during a paid evaluation period, on a sample large enough to mean something — a few thousand exits, not a few dozen.
Collect the exit address for several thousand requests and resolve each to an ASN. A pool sold as residential should map predominantly to consumer ISPs. A material share landing on hosting providers, cloud ranges or transit-only ASNs tells you the pool is mixed, whatever the label says. Plot the distribution rather than the average — one long tail of hosting ASNs is easy to miss in a summary statistic.
Reverse DNS on consumer addresses usually carries ISP-assigned patterns; hosting addresses usually do not. Run the same sample through the IP reputation and proxy-detection services your targets are likely to use. You are not looking for a clean sheet. You are looking for how much of the pool is already flagged before you have sent a single request through it.
Request a specific country or city, then check what the destination itself reports rather than what a geolocation database says. Databases disagree with each other and none of them is the authority your target uses. Sample 30 exits per location, record the agreement rate, and treat a poor rate as a data quality finding rather than a rounding error. The full method, including what a city-level claim can physically deliver, is in how to check a city-level geo claim. If the provider bills advanced filters differently — as with country, city and ASN targeting, where state, city, ZIP and ASN filters are billed at twice the standard rate — verify the accuracy of the thing you are paying double for.
The test that makes question 6 enforceable. Sample exits from two vendors you believe to be independent, over the same time window, targeting the same country. Compare the address sets. Meaningful overlap means they share an upstream, whatever either of them told you. This is also the only reliable way to discover that your "multi-vendor redundancy" strategy is one network wearing two invoices.
There is a documented reason to expect this. Reporting on the July action quoted Google's assessment that "when faced with the degradation of their own botnet, proxy operators begin buying capacity from their competitors, effectively becoming a reseller" (Krebs on Security). Resale is not an edge case in this market. It is what a network under pressure does next, which is why question 6 is on the list and why this test exists to check the answer.
Nothing, on their own. That argument is made in full in what a pool-size claim is worth; the short version follows.
No provider publishes a counting methodology. Ask three vendors what a "unique IP" means and you will get three answers: addresses seen in the last 30 days, addresses seen ever, addresses theoretically reachable through an upstream agreement, or the sum of several of those with the overlaps left in. A number without a method is not a measurement.
Worse, headline pool size is uncorrelated with the thing you actually care about, which is how many usable, unflagged, correctly located exits are available in your target country at the hour you run your job. A pool of tens of millions concentrated in three countries is smaller than a pool a fraction of the size distributed across the market you need.
Ask instead: how many distinct exits did my traffic use last month, in the countries I requested? That number is measurable from your own logs, and it is the only pool-size figure that describes your experience.
Plan for the upstream, not for the vendor. The mechanics of doing it after the fact — what to extract, what breaks silently, how to cut over — are set out in migrating when a network disappears. What follows is what to have in place before you need that.
Copy this. Send it to every provider on your shortlist, and send it to us.
1. Where do your residential IPs come from, named at the program level?
2. Can we see the consent flow a participant sees, in their language?
3. Is compensation disclosed to participants, and in what form?
4. How does a participant opt out, and how long until their IP leaves
the pool?
5. Do you operate an SDK, and which applications embed it?
6. Do you resell another network's pool, and will you say whose?
7. What is the abuse-reporting path, and what is the takedown SLA?
8. Which target categories are prohibited, and is that enforced
technically or only contractually?
9. What logs do you keep, for how long, and under what process are they
disclosed?
10. Is KYC required of customers, and at what threshold?
11. What happens to our sessions if an upstream network is seized?
12. Will you put your answers to 1-11 in writing?
Score the responses on specificity, not on tone. A provider that answers eight of twelve precisely and declines four with a stated reason has told you more than one that answers all twelve warmly and names nothing.
Not in the sense of an audited standard. One industry body, the Ethical Web Data Collection Initiative hosted by the i2Coalition, publishes principles and awards a certified designation to companies that pledge to work within its framework. No independent audit methodology is published on its public pages. The phrase itself is unregulated and any vendor can use it, so treat it as a commitment to verify rather than a finding to rely on.
You cannot verify consent directly — the traffic looks identical either way. You can test the disclosure. Ask the twelve questions above in writing, then run the independent tests: ASN distribution across a few thousand sampled exits, reverse DNS and reputation lookups, geo-claim agreement against the target's own reported location, and pool overlap against a second vendor.
Reselling is common and not disqualifying by itself. Undisclosed reselling is the problem, because it means your diligence stopped one layer above where the IPs actually originate, and your continuity risk sits with a company you cannot name. Ask directly, ask every vendor, and use the pool-overlap test to check the answer you were given.
Not without a stated counting method. Providers define "unique IP" differently — seen in 30 days, seen ever, or reachable through an upstream agreement — and none publish the methodology. The figure that describes your experience is how many distinct exits your own traffic used last month in the countries you requested, which you can measure from your own logs.
Expect hangs rather than clean errors, so put aggressive connect timeouts and a circuit breaker on the gateway hostname before you need them. Keep a second integration configured and tested so switching is a variable change. Verify the second provider does not share the first one's pool by comparing sampled exit addresses across both, over the same window and the same country.
The position this article takes is that you should not accept a sourcing badge
from anybody, and that includes accepting one from us. So do not. Send the
checklist to [email protected] and evaluate the answers with the same
scoring you apply to every other vendor on your list.
Send these questions to sales. Specific answers, or a stated reason there is not one.