Is Bandwidth Sharing GDPR-Compliant?
Short answer: bandwidth sharing can be operated in a GDPR-compliant way, but compliance depends on how you disclose it and obtain consent — not on the SDK alone. This page explains the consent requirement in plain terms and where your responsibilities as the developer begin. It is general guidance, not legal advice.
The consent requirement in plain terms
GDPR does not ban bandwidth sharing. What it requires is that people understand what happens on their device and agree to it. If a user has genuinely opted in and the disclosure is clear, honest and specific, you are on solid footing. The problems arise when sharing is silent, buried, or bundled in a way a reasonable person would not expect.
In practical terms, compliant bandwidth sharing rests on a few principles that apply to any processing on a user's device:
- Lawful basis — you need a valid reason to process, most commonly the user's informed consent.
- Transparency — users should be told, in plain language, that idle bandwidth may be shared and for what purpose.
- Specific and informed — the disclosure names the activity clearly; it isn't hidden inside unrelated boilerplate.
- Freely given — the user isn't coerced, and can decline or change their mind.
- Withdrawable — opting out later must be as easy as opting in.
GetPassive is built to make meeting these principles straightforward: it runs only after the user has opted in, shares idle bandwidth only, and can be switched off by the user at any time.
How consent is handled (your T&Cs / privacy policy disclosure)
This is the most important thing to understand, and it's where GetPassive differs from an ad SDK. GetPassive does not ship an in-app consent popup. Consent and disclosure are handled through your own Terms & Conditions and privacy policy, as a plain-English statement that idle, unused bandwidth may be shared while the app is running.
Why this model? You already own the legal relationship with your users through your T&Cs and privacy policy. Layering a second, generic pop-up on top tends to confuse users and fragments your disclosures. Instead, you add a clear line to the documents users already agree to — written in language they can understand — and the SDK only launches after the user has accepted.
A good disclosure typically covers:
- That the app shares a portion of the device's idle / unused bandwidth.
- The purpose in plain terms — supporting legitimate business demand for accessing publicly available web content.
- That it does not access personal data, files, accounts, or browsing.
- That the user can opt out at any time, and how.
You control the exact wording so it fits your product, your jurisdiction, and your existing policies. Because you write it, you can align it with the rest of your compliance documentation rather than working around a fixed template.
What data is and is not processed
Under GDPR, the scope of processing matters enormously — the less personal data involved, the lighter the obligations. GetPassive is deliberately narrow: it relays idle bandwidth and nothing more. It is a standalone binary (around 2MB) that runs as a background process; it is not an analytics or data-collection tool.
| Processed / used | NOT processed |
|---|---|
| A share of idle, unused network bandwidth on the device | The user's personal data or profile information |
| Basic operational signals needed to relay traffic and pause on metered/cellular connections | Files, photos, messages, or documents on the device |
| Country-level location context (used for earnings tiering) | App accounts, credentials, or logins |
| The user's own browsing history or activity |
What it does not do: it does not read, collect, or transmit the user's personal data, and it does not touch their files, accounts, or browsing. It pauses automatically on metered or cellular connections so it never spends a user's mobile data. The source is available for security review, so you and your own reviewers can verify these claims rather than take them on trust.
Your responsibilities as the developer
Because you own the user relationship, GDPR responsibilities sit largely with you as the app developer (you are the data controller for your users). GetPassive is designed to make these easy to meet, but the following are yours to own:
- Disclose it clearly. Add a plain-English statement about bandwidth sharing to your T&Cs and privacy policy before enabling it.
- Obtain valid consent. Ensure users agree to those terms, and only run the SDK after they have opted in.
- Honour opt-out. Make it straightforward for users to stop sharing; GetPassive lets the user opt out at any time, and you can also switch it off remotely.
- Keep disclosures current. If your product or policies change, keep the wording accurate.
- Respect local law. GDPR is the baseline in the EU/UK; some regions add their own requirements. When in doubt, take your own legal advice for your jurisdiction and audience.
This page is general guidance to help you ask the right questions — it is not legal advice, and it cannot promise a specific outcome for your app. Nobody can honestly guarantee any integration is risk-free; what you can do is stay firmly on the right side of the line by being opt-in and transparent.
How GetPassive supports your compliance
GetPassive is built consent-first, so the technical defaults line up with what GDPR expects. The design does much of the heavy lifting; you supply the disclosure and consent through your own terms.
- Opt-in by design. The background process only launches after the user has consented via your T&Cs — never silently.
- Idle bandwidth only. It relays a share of unused bandwidth and does not read personal data, files, accounts, or browsing.
- Pauses on metered/cellular. It won't consume a user's mobile data, reducing the chance of unexpected impact on the user.
- User and developer control. Users can opt out at any time; you can switch it off remotely across your installed base.
- Source available for review. Your security and legal reviewers can inspect exactly what it does before you ship.
- Legitimate demand only. Bandwidth supports partner businesses accessing publicly available web content — market research, ad verification, brand protection, SEO monitoring, price comparison, and cybersecurity.
- No ads. It's an ad-free way to monetise, so you're not layering tracking-based advertising on top of your users.
On the commercial side, earnings use country tiers and depend on where your opted-in users are, how long their devices stay active, and how much eligible bandwidth is available. Payouts are monthly via Stripe Connect or USDC (CoinGate) once your approved balance reaches the $10 minimum. Cross-platform support covers Android (aarch64/armv7/x86_64), iOS, and desktop (Windows/macOS/Linux), and you can integrate from native, React Native, or Flutter.
Ready to review the details? See the docs at docs.getpassive.io, apply at getpassive.io/#apply, or email [email protected].
FAQ
Is bandwidth sharing legal under GDPR?
Yes, bandwidth sharing can be operated in a GDPR-compliant way. GDPR does not prohibit it; it requires that users are told clearly what happens on their device and that they consent. If sharing is opt-in and disclosed in plain language, you are on solid ground. This is general guidance, not legal advice — for your specific product and jurisdiction, consult your own legal counsel.
How do users consent to bandwidth sharing with GetPassive?
Consent is handled through your own Terms & Conditions and privacy policy as a plain-English disclosure that idle, unused bandwidth may be shared while the app runs. GetPassive does not ship an in-app consent popup — you add the disclosure to the documents your users already agree to, and the SDK only launches after they have opted in.
What personal data does GetPassive collect?
GetPassive relays only idle, unused bandwidth. It does not read, collect, or transmit the user's personal data, files, accounts, or browsing. It uses country-level context for earnings tiering and basic operational signals to relay traffic and pause on metered or cellular connections. Because it processes so little personal data, your GDPR obligations stay lighter — and the source is available for security review so you can verify this.
Who is responsible for GDPR compliance — me or GetPassive?
As the app developer, you own the relationship with your users and act as the data controller, so the disclosure and consent responsibilities are yours: add a clear statement to your T&Cs and privacy policy, obtain consent, and honour opt-outs. GetPassive supports this by being opt-in by design, sharing only idle bandwidth, pausing on metered/cellular, and giving both users and you the ability to switch it off.
Can users opt out of bandwidth sharing after they've agreed?
Yes. GDPR expects withdrawal to be as easy as giving consent, and GetPassive is built for that — a user can opt out at any time. As the developer, you can also switch the SDK off remotely across your installed base if you need to.
Does GetPassive guarantee my app will be GDPR-compliant?
No honest provider can guarantee that, because compliance depends on how you disclose and obtain consent, plus your jurisdiction and audience. What GetPassive provides is a consent-first, idle-bandwidth-only, source-reviewable foundation that makes staying compliant much more straightforward. Treat this page as general guidance and take your own legal advice for your specific case.
Monetise your app the transparent way
GetPassive turns idle, opted-in bandwidth into recurring monthly revenue — no ads, consent-first, and source-reviewable. Payouts are monthly via Stripe Connect or USDC once your approved balance reaches the $10 minimum. Read the docs at docs.getpassive.io, apply at getpassive.io/#apply, or email [email protected].
Apply for early access