# What Does Consent Look Like in Bandwidth Sharing?
You find a free utility for your PC. A file converter, a cleanup tool, a media player. It does the job. No trial, no watermark, no account. And somewhere in the back of your mind: what is paying for this?
Something always is. Software costs money to build and keep running, and the bill goes somewhere. Ads, your data, a subscription you forget to cancel, or a slice of bandwidth you weren't using. Those are not equally good deals, and the differences matter before you consent to one.
One disclosure first, since it's the kind of thing this post is about. Massive operates a network built on the last of those four models, so we're an interested party. Read what follows as a standard to hold us to rather than one we're proposing for everyone else to meet.
> **Key Takeaways**
>
> - Nearly 80% of consumers would rather receive more ads than pay for websites and apps that are free today (IAB, 2024). The trade itself is not what people object to.
> - Bandwidth is the only one of the four funding models that takes nothing the user was actually using. Filling a 500 Mbps line takes twenty simultaneous 4K streams; most homes run one or two.
> - Control is what creates willingness. Verve found 68% of people feel they have more control over app privacy than two years ago, and 58% became more willing to share as a result.
> - Consenting to share bandwidth is not consenting to share your data, your activity, or your buying intent. Those are separate asks.
> - Consent and control are what separate a trade from a helping-yourself. Remove them and the arrangement doesn't just become unfair, it stops working.
*A two minute walk through the same four tests described below, from the install screen to the uninstall, without naming a single product.*
## What pays for free software?
People want the free-with-something-back deal, and they say so clearly. In 2024, the Interactive Advertising Bureau found that nearly 80% of consumers would rather receive more ads than pay for websites and apps that are currently free ([IAB](https://www.iab.com/news/consumer-privacy-research/), *The Free and Open Ad-Supported Internet*, January 2024).
So the argument was never "should there be a trade." There is always a trade. The argument is about what gets traded, and how well the person on the other end understands it.
Four models do the paying, and each takes something different:
| Model | What it takes | What the user gives up |
|-------|---------------|------------------------|
| Advertising | Attention | Interruption, and usually some tracking |
| Data monetization | Information about you, including buying intent | Privacy, permanently and irreversibly |
| Subscription | Money | Cash, plus another recurring bill to track |
| Bandwidth sharing | Spare network capacity | Nothing they were using, if done right |
The subscription route is under real strain. Deloitte's 2026 survey found 41% of consumers canceled at least one paid streaming service in the previous six months, 47% said they pay too much for the services they use, another 41% said the content wasn't worth the price, and 54% had moved onto ad-supported tiers ([Deloitte](https://www.deloitte.com/us/en/insights/industry/technology/digital-media-trends-consumption-habits-survey.html), *2026 Digital Media Trends*). A small utility asking for a monthly fee is competing against that fatigue.
Source: Deloitte, 2026 Digital Media Trends. Subscription fatigue is why the other three models keep getting revisited.
Advertising and data monetization both take something the user would rather keep. Attention is finite. Information about you, once it has been sold, cannot be recalled. Both are real trades that plenty of people accept knowingly, and there's nothing dishonest about either when it's disclosed. But both are subtractive: the user ends the transaction with less than they started with. That's the sense in which [when it's free, you are the product](https://www.joinmassive.com/blog/when-its-free-you-are-the-product-a-better-way-to-pay) is a fair description of the first two models and a poor description of the fourth.
Bandwidth is the odd one out. Done properly, the user ends the transaction with everything they had.
## Why is there room in a home connection for bandwidth sharing?
Because a household would struggle to use what it already pays for. Netflix recommends 15 Mbps for a 4K stream ([Netflix](https://help.netflix.com/en/node/306)). Budget 25 to be safe and filling a 500 Mbps line still takes twenty simultaneous 4K streams, or forty on gigabit. Most homes run one or two. A shared request is a public page, a few megabytes, roughly one second of one stream.
You would need dozens of concurrent 4K streams to approach the capacity you are already paying for.
The gap keeps widening. [OpenVault](https://openvault.com/openvault-faster-speeds-help-upstream-usage-hit-the-gas/) puts 81% of homes on 200 Mbps or faster, against far slower growth in what they use. People keep paying for capacity they cannot reach. The one exception is a metered plan with a hard cap, where spare capacity and spare allowance are different things.
On the other side, companies need to read public web pages from a home connection rather than a data center: prices by region, ads rendering where they paid for them to, search results by country, public pages for AI systems. None of it requires knowing anything about the person whose connection carried it.
So the deal is clean: the user contributes something they weren't using and gets working software with no ads, no data collection, and no bill. Per device the revenue is small, so it works in aggregate, which suits a utility with a large install base rather than a niche tool.
That's the symbiotic version. If the bandwidth wasn't given, it was taken. Same mechanism, same spare capacity, but one is a trade and the other is helping yourself to somebody's connection.
## What makes the exchange mutual instead of parasitic?
Consent and control are the load-bearing parts of the model, not softening words wrapped around it. The survey data is unusually direct on this.
Verve's 2024 In-App User Privacy Report surveyed 4,001 people in the US and UK. It found 68% agreed they have more control over their app privacy settings than they did two years earlier, and 58% said they had become more willing to share data as a result ([Verve](https://verve.com/press/more-control-drives-more-data-sharing-surprising-in-app-privacy-trends-revealed-by-verve/), *2024 In-App User Privacy Report*, September 2024). More control produced more willingness, not less. The [IAB](https://www.iab.com/news/consumer-privacy-research/) found the same shape in 2024: around 85% said it matters to them that a service tells them specifically what is shared and lets them see and delete it.
Consent is normally discussed as a tax on the business, a friction you accept because regulators require it. These two findings say the opposite. The clearer the disclosure and the more real the control, the more people agree. Burying the disclosure doesn't buy you a cheaper yes. It buys you a yes that evaporates the moment anyone looks at it, from a user who would probably have said yes anyway if you had asked properly.
Which is why taking the bandwidth instead of trading for it is also bad business. Supply assembled from people who never really agreed can vanish the instant it's explained to them, and it invites exactly the regulatory attention that ends business models. Supply from people who knowingly agreed is stable, because nothing about it needs to stay hidden.
**The short test:** would the user be surprised? If explaining the arrangement to the person whose connection is carrying the traffic would come as unwelcome news, you already know what kind of arrangement it is. Everything below is a way of checking that without having to ask them.
## Test 1: Was it told up front, with nothing pre-ticked?
The user has to make the choice, which means they have to see it. The disclosure appears at install, on its own screen, before anything runs, in plain words. Not folded into a license agreement. Nothing pre-selected. The user reaches out and chooses it.
The commercial case for that comes before the legal one. A pre-ticked box doesn't produce a more willing supply base, it produces a larger one that is worth less per head, because none of it survives contact with an explanation. Every user acquired that way is a user who will feel misled the day they find out, and the IAB data says most of them would have agreed anyway if asked plainly. You are trading a durable yes for a fragile one and paying a reputational premium for the privilege.
The law happens to agree, which is a useful confirmation rather than the reason. In *Planet49* (Case C-673/17), the Court of Justice of the European Union ruled that a pre-ticked checkbox a user could untick cannot amount to valid consent ([CJEU](https://curia.europa.eu/juris/liste.jsf?num=C-673/17), *Planet49*, 1 October 2019). Consent has to result from the user's active behavior. The GDPR text is blunter: silence, pre-ticked boxes, and inactivity do not constitute consent.
The US arrives at the same place by a different road. Section 5 of the FTC Act reaches deceptive practices. Burying a material term where a reasonable person won't find it, then treating the click as agreement, sits squarely inside that.
## Test 2: Can the user turn it off?
Control isn't a one-time event at install. It's ongoing, which means the user has to be able to change their mind without asking permission. Sharing gets an on/off switch in the app's own settings, reachable in a few clicks.
Under Article 7(3) of the GDPR, withdrawing consent has to be as easy as giving it. The European Data Protection Board treats easy withdrawal as a precondition of validity, and flags any flow where reversing takes many more clicks than agreeing did ([EDPB](https://www.edpb.europa.eu/system/files/documents/2023-02/edpb_03-2022_guidelines_on_deceptive_design_patterns_in_social_media_platform_interfaces_v2_en_0.pdf), *Guidelines 03/2022 on Deceptive Design Patterns*, adopted February 2023). The FTC made the same point expensive in September 2025, when Amazon agreed to pay $2.5 billion to settle claims over enrollment and cancellation flows the agency alleged were designed to be hard to reverse ([FTC](https://www.ftc.gov/news-events/news/press-releases/2025/09/ftc-secures-historic-25-billion-settlement-against-amazon), September 2025).
Be precise about what the switch does and doesn't promise. In most bandwidth-for-software arrangements the trade is conditional. Turn sharing off and the software may ask you to turn it back on to keep using it, because the sharing is what's paying for it. That's a fair deal to offer, and an honest thing to say plainly. It is not the same as keeping the software for free with sharing disabled, and any product blurring those two is telling you something about itself.
## Test 3: Is it consent to bandwidth, and only bandwidth?
Agreeing to share a connection is not agreeing to share yourself. This is the test most worth being pedantic about, because it's where an honest arrangement and a data-collection product can look identical on the install screen and be nothing alike underneath.
What's being borrowed is a slice of capacity while the machine isn't calling on it. What is not being offered, and what a bandwidth agreement gives nobody any claim on:
- **Your browsing history.** What sites you visit is yours.
- **Your files and communications.** Nothing on the machine is in scope.
- **Your activity.** What you do on your own computer is not part of the trade.
- **Your personal information.** Name, contacts, accounts, identifiers.
- **Your buying intent.** What you're shopping for, comparing, or about to purchase is one of the most commercially valuable things about you, and it is precisely the thing a data-monetization product exists to capture. A bandwidth agreement should get nowhere near it.
Purchase intent is what the data economy actually trades in, so "we only take a little data" from a product that also touches your browsing is not a smaller version of the same deal. It's a different deal in a costume.
Hold the two mechanisms side by side. Bandwidth sharing moves *other people's* requests for public pages through your connection. Data monetization sends information about *you* to someone else. One uses a resource, the other uses a person. Software can honestly do the first without ever doing the second, and a product that quietly does both while disclosing only the first has not obtained consent for what it's doing.
So the scope statement has to be one sentence, specific, and load-bearing.
As our own worked example: Massive's [published position](https://www.joinmassive.com/consent) is that companies pay to read public web pages from a home connection rather than a data center, and that the network "collects only what running the network requires and never browsing history, file contents, or personal communications." The same page publishes what the network is used for and what it is not used for, in two side-by-side lists. Asking any provider for both is a reasonable thing to do, and a provider that can't produce them hasn't thought the question through.
## Test 4: Uninstalling has to actually remove it
Uninstalling is the least ambiguous thing a person can do. It means: I'm done, take it off my machine. An arrangement that survives it was never really under the user's control.
So when the app goes, the sharing goes with it. No leftover service, no scheduled task, nothing still running afterward, nothing that quietly reinstalls on the next boot. The user's hardware returns to being entirely theirs, which is the state it was in before they agreed and the state they're entitled to return to.
This is the easiest of the four to verify and the one most worth checking. Install in a clean virtual machine, capture the running services and scheduled tasks, uninstall, capture again, and diff the two. Anything still resident is the answer.
We built the network in that order, and it shows in what we're comfortable being asked. Massive started as an app monetization product, where people traded a slice of idle compute for premium features they'd otherwise have paid for. That made the consent screen the product surface from day one, rather than a compliance layer added once the supply already existed.
Every IP in the network is opted in through that SDK. The network is SOC 2 audited, GDPR compliant, and AppEsteem certified, with a full audit trail from source to request. Ask us for the report dates; that's a fair thing to be asked for.
## How do you tell which kind of network you're looking at?
Whether you're a person deciding to install something or a company deciding whose network to buy, the four tests turn into six checks. Test 1 splits in two, because being told and not being pre-ticked are separate failures, and traceability gets its own row since it's the only one that covers what you can't see yourself. What separates a good answer from a weak one is usually whether it points at an artifact or at a sentence in a policy.
| Check | What to ask for | What a weak answer sounds like |
|--------|-----------------|-------------------------------|
| Told up front | A recording of the actual first-run install | "It's covered in our terms" |
| Nothing pre-ticked | The same recording, showing the control's default state | "Users accept during onboarding" |
| A reachable switch | The path to the setting, counted in clicks | "They can contact support" |
| Bandwidth, not data | Written scope, plus the permitted and blocked use lists | "We're fully GDPR compliant" |
| Clean uninstall | Your own before-and-after diff on a clean machine | "Standard uninstaller" |
| Traceability | How a request traces back to a device that agreed | "We audit our supply regularly" |
These checks have limits, and pretending otherwise would be its own kind of dodge. The install-screen question only reaches apps a provider is willing to name, and the uninstall check only reaches builds you can actually get hold of. Neither covers a partner nobody discloses, which is why the traceability question in the last row carries more weight than it looks like it does.
[See what consent looks like](https://www.joinmassive.com/consent) [Compare providers](https://www.joinmassive.com/blog/how-to-choose-a-proxy-provider)
## Frequently Asked Questions
### What actually moves through my connection?
Requests for public web pages, and nothing off your machine. It's a bounded arrangement, and the bounds are the thing to check. Does the software say plainly what it takes, does it let you switch it off, and does it leave completely when you uninstall it?
### Does bandwidth sharing slow down my internet?
It shouldn't, because the capacity being used is capacity going spare. A month of average household traffic, 767.4 GB in 4Q25 (OpenVault), would clear in about three and a half hours at 500 Mbps, so the headroom is substantial. A well-behaved implementation works inside that headroom and yields when you need the line.
### Why don't developers just charge for the software instead?
Many try, and run into subscription fatigue. Deloitte's 2026 survey found 41% of consumers had canceled a paid service in the previous six months and 47% felt they were paying too much. For a small utility, a recurring fee is a hard sell against a free alternative.
### Is bandwidth sharing legal?
With informed consent, yes, in the US and the EU alike. The exposure comes from how consent is obtained. The CJEU held in *Planet49* (2019) that pre-ticked boxes cannot be valid consent under the GDPR, and Article 7(3) requires withdrawal to be as easy as opting in. In the US the same conduct is reached as a deceptive practice under Section 5 of the FTC Act.
### What exactly am I agreeing to share?
Spare network capacity, and nothing else. A bandwidth agreement gives no claim on your browsing history, your files, your activity on the machine, your personal information, or your buying intent. If a product asks to share your connection and also collects information about you, those are two separate things and it owes you a separate, explicit yes for the second.
## The short version
Free software gets paid for somehow, and people are broadly fine with that. Nearly 80% say they would rather trade something than pay. The honest question is what you ask them to trade, and whether they understood the question.
Spare bandwidth is the cleanest answer available. It takes nothing the person was using, touches nothing about them, and costs them no money. That makes it capable of being genuinely mutual in a way the other three models can only approximate.
Capable of, not guaranteed to be. Slip the consent in and the same arrangement stops being a trade: the bandwidth is no longer given, it's taken, out of hardware whose owner never really agreed. The mechanism is identical. What changed is that somebody stopped being in control of their own machine.
Told up front, nothing pre-ticked, a switch you can reach, and a clean uninstall. That's what it looks like when free software is paid for honestly.
Further reading: [the benefits of paying with idle resources for free apps](https://www.joinmassive.com/blog/the-benefits-of-paying-with-idle-resources-for-free-apps) and [how Massive approaches compliance and security](https://www.joinmassive.com/blog/massive-compliance-and-security).
## Sources
- Interactive Advertising Bureau, [*The Free and Open Ad-Supported Internet: Consumers, Content, and Assessing the Data Value Exchange*](https://www.iab.com/news/consumer-privacy-research/), published 29 January 2024, retrieved 2026-08-24
- Verve, [*2024 In-App User Privacy Report*](https://verve.com/press/more-control-drives-more-data-sharing-surprising-in-app-privacy-trends-revealed-by-verve/), 4,001 respondents in the US and UK, published 11 September 2024, retrieved 2026-08-24
- Deloitte, [*2026 Digital Media Trends*](https://www.deloitte.com/us/en/insights/industry/technology/digital-media-trends-consumption-habits-survey.html), Center for Technology, Media & Telecommunications, survey of 3,575 US consumers, published March 2026, retrieved 2026-08-24
- OpenVault, [*Broadband Insights Report 4Q25*](https://openvault.com/openvault-faster-speeds-help-upstream-usage-hit-the-gas/), published 17 February 2026, retrieved 2026-08-24
- Court of Justice of the European Union, [*Bundesverband der Verbraucherzentralen v Planet49 GmbH*, Case C-673/17](https://curia.europa.eu/juris/liste.jsf?num=C-673/17), judgment of 1 October 2019, retrieved 2026-08-24
- European Union, [*Regulation (EU) 2016/679 (GDPR), Article 7(3): conditions for consent and withdrawal*](https://eur-lex.europa.eu/eli/reg/2016/679/oj), in force 25 May 2018, retrieved 2026-08-24
- European Data Protection Board, [*Guidelines 03/2022 on Deceptive Design Patterns in Social Media Platform Interfaces*](https://www.edpb.europa.eu/system/files/documents/2023-02/edpb_03-2022_guidelines_on_deceptive_design_patterns_in_social_media_platform_interfaces_v2_en_0.pdf), version 2.0 adopted February 2023, retrieved 2026-08-24
- U.S. Federal Trade Commission, [*FTC Secures Historic $2.5 Billion Settlement Against Amazon*](https://www.ftc.gov/news-events/news/press-releases/2025/09/ftc-secures-historic-25-billion-settlement-against-amazon), press release, 25 September 2025, retrieved 2026-08-24
- Massive, [*What consent looks like*](https://www.joinmassive.com/consent), retrieved 2026-08-24