Where shared bandwidth actually goes

Every developer who seriously considers a bandwidth-sharing SDK arrives at the same question, usually about ten minutes in: who is buying this, and what are they doing with it?

It is the right question and it is the one the category answers worst. Most vendor pages say something like "public web data" and move on, which tells you nothing and reads as if there is a reason not to say more.

So here is the long version, including the parts that are uncomfortable.

The short answer

Traffic is relayed for public web data collection: retrieving pages that are already publicly visible, from a residential connection rather than a datacenter one. The buyer is almost always a company that needs to see the public web the way an ordinary person in a particular country sees it.

Five categories cover the overwhelming majority.

Price and availability monitoring

A retailer wants to know what competitors charge. An airline wants to know what fares are showing in Brazil. A brand wants to know whether a distributor is undercutting its agreed pricing.

All of that information is public — it is on a product page anyone can open. The complication is that large sites show different prices to different places, and increasingly refuse traffic that arrives from a datacenter. So a company checking prices from an AWS instance sees either a block page or a price that no real customer would be shown.

This is the largest single slice of demand and the least dramatic.

Ad verification

An advertiser pays for an ad to appear in Poland. They would like to confirm it appeared in Poland, on the site they bought, next to content they approved, and that a bot did not click it.

The only way to check is to look from Poland. Ad fraud is a real and enormous problem, and verification is one of the few things that constrains it. This is one of the more clearly beneficial uses on the list.

Search and SEO measurement

Search results are localised, personalised and continually re-tested. An agency tracking whether its client ranks in Chicago has to look from Chicago, and increasingly has to look from a residential connection to see what a resident sees.

Same shape as ad verification: measurement of a public surface that has become location-dependent.

Market research

The dullest category and one of the largest. Aggregating public listings, tracking product availability, monitoring public sentiment, building datasets about industries. Most of it is unglamorous commercial research that would have been done by hand twenty years ago.

AI training data

This is the contentious one, so let us not bury it.

Some buyers are collecting publicly available web pages to train or evaluate machine learning models. That is a use a lot of people object to, on grounds that have nothing to do with bandwidth and everything to do with how models are built and who benefits.

We are not going to pretend that objection is unreasonable, and we are not going to hide the category in a list of five nicer ones. If you or your users would object to your app's spare bandwidth contributing to that, it is a legitimate reason to say no, and you should say no.

What is permanently blocked

A blocklist enforced on both the device and the relay covers:

• .gov and .edu domains
• Banks and financial institutions
• Card processors and payment endpoints
• Login endpoints and authentication flows
• Sensitive APIs
• Any domain reported for abuse, permanently, once reported
• The user's own local network — no scanning the LAN the device sits on

That last one is worth pausing on, because it is the protection a technically minded user will ask about first. A relay that could reach 192.168.1.1 is a relay that could reach the router, the NAS and the printer. It cannot.

Blocking has to be enforced on both sides. A blocklist that lives only in the client is a suggestion, because the client is on someone else's device and can be tampered with. The relay refuses the same destinations independently, so defeating one does not defeat the other.

The parts that should still make you uncomfortable

If the section above felt like a sales pitch, here are the residual problems. We think they are manageable. We do not think they are zero.

You cannot personally verify every destination. You can verify the blocklist's behaviour — point mitmproxy at a device and watch — and you can read the policy. You cannot audit every request your users' devices ever serve. That is a real limit and anyone claiming otherwise is overselling.

"Public data" is a category with fuzzy edges. A page behind no login is public. A page behind a rate limit is public but not intended to be read at volume. Reasonable people disagree about where scraping stops being reading, and that argument is not settled by anything we do.

Your users are not reading this page. They see a consent screen. However well written, the asymmetry between what you now know and what they agreed to is real, which is why the consent screen has to be honest rather than merely compliant.

The demand side can change. The categories above are what buyers want today. A network's ethics are only as durable as its refusals, which is why ours are written down rather than left to judgement.

What we will not sell traffic for

Stated plainly, because a list of allowed uses is worth less than a list of refused ones:

• Anything requiring a login or credential
• Anything targeting an individual
• Financial services, card processing, or payment flows
• Government and education systems
• Any destination reported for abuse
• Any use whose description depends on the recipient not understanding it

How to decide

1. Read the consent screen your users will see, and read it as a user.
2. Decide whether you are comfortable with the AI-training category, because it is the one most likely to generate a complaint.
3. Check the blocklist claim yourself rather than accepting it.
4. Ask what happens when a destination is reported.
5. If your users are children, on a corporate network, or unusually privacy-sensitive, the answer is probably no, and that is a fine answer.

For what this pays and how it compares with the alternatives, what each model costs your users has the honest menu and what apps make per download has the numbers. Our ethics page is where the commitments above live.