2026-06-17 · GetPassive Team · 10 min read

GDPR-compliant consent for bandwidth-sharing SDKs

If you are integrating a bandwidth-sharing SDK into an EU or UK-distributed app, the consent question is not optional. UK GDPR and the EU equivalent require a specific legal basis for processing personal data, plain-language disclosure, an active acceptance, and easy withdrawal. This guide walks through what that actually means for a developer shipping a bandwidth-sharing integration: what the legal basis is, how to draft the disclosure block, what the joint-controller relationship looks like, and how to satisfy data minimisation.

This is not legal advice. It is a developer-friendly summary of the requirements that real production integrations have to meet. If your audience is large or your business is regulated, get a lawyer to review the final text.

The legal basis: consent under Article 6(1)(a)

UK GDPR Article 6 lists the available legal bases for processing personal data. For a background bandwidth-sharing feature, the cleanest legal basis is consent under Article 6(1)(a). The reasons:

Legitimate interests (Article 6(1)(f)) does not fit. The processing is not necessary for the app’s core function; it is an optional revenue model. The balancing test under legitimate interests usually fails.
Contract (Article 6(1)(b)) does not fit either. The user does not need the bandwidth-sharing feature to receive the app’s primary service.
Consent fits. The user actively accepts a specific, informed disclosure about a separable feature, with the right to withdraw.

For the storing or accessing of information on the user’s device, PECR Regulation 6 also applies in the UK (and the ePrivacy Directive equivalent in EU member states). The consent under Article 6(1)(a) covers this as well, provided the disclosure is specific.

What counts as valid consent

UK GDPR Article 7 and Recital 32 set out the conditions:

Freely given. The user must be able to decline without losing access to the app’s primary service. If acceptance is bundled with the entire app being usable, consent is not freely given.
Specific. The consent must be for the bandwidth-sharing feature specifically, not buried in a general T&Cs acceptance with no mention of it.
Informed. Plain language. The user should understand what is being processed, why, by whom, and what their rights are.
Unambiguous indication of agreement. An active choice. Pre-ticked boxes do not work.
Withdrawable. The user must be able to withdraw consent as easily as they gave it, and the withdrawal must be respected immediately.

The model that satisfies all five: a clearly-headed section inside the existing T&Cs, accepted at first launch, with a settings toggle for revocation. The acceptance is active (the user taps Accept). The withdrawal is one toggle. The disclosure is specific to the feature.

The T&Cs disclosure block

Here is a worked example of a compliant disclosure section to drop into existing T&Cs. Adapt it to your wording style:

BANDWIDTH SHARING

This app participates in an opt-in bandwidth sharing
network operated by GetPassive Ltd. If you accept these
Terms, a small portion of your device's idle network
capacity may be used to serve approved business
customers' traffic.

What this means in practice:
- The feature uses your IP address, approximate region,
  a pseudonymous device identifier, and traffic
  metadata (bytes transferred, timestamps).
- It does NOT access your files, contacts, messages,
  photos, or browsing history.
- It runs in the background only when your device is
  online and idle, and yields when your device is under
  load.
- It is for users aged 18 and over only.

You can turn this off at any time in Settings.
Withdrawing is as easy as accepting and stops the
feature immediately. You will not lose access to the
rest of the app.

The integrating developer and GetPassive Ltd are joint
controllers for this feature under UK GDPR Article 26.
A summary of our joint controller arrangement is
available at https://getpassive.io/legal/sdk-consent.html.

The headings, plain language, and direct enumeration of what is and is not processed are the parts that matter for the informed-consent test. A reviewer (regulator or auditor) reading this can tell at a glance what the feature is and what it does.

The joint controller relationship

UK GDPR Article 26 requires that joint controllers determine their respective responsibilities through a transparent arrangement, and the essence of that arrangement must be made available to data subjects. The pattern that works for SDK integrations:

Developer responsibilities. Direct user contact, in-app consent UX, settings toggle, age confirmation where applicable, T&Cs and privacy policy disclosure.
SDK platform responsibilities. Network infrastructure operation, contractual relationships with business customers, anti-abuse monitoring, joint-controller summary publication, joint-controller addendum to the developer agreement.
Shared responsibilities. Honouring data subject rights requests. Either party can be the first point of contact; the other contributes promptly.

The GetPassive Joint Controller Addendum (linked from the SDK consent page) makes these responsibilities explicit. Developers receive it as part of the standard integration onboarding.

Data minimisation

Article 5(1)(c) of UK GDPR requires that personal data be adequate, relevant, and limited to what is necessary. The data categories used:

IP address. Required to operate the network; identifies the device’s point of presence.
Approximate region. Used for demand routing; derived from the IP and stored at country-level granularity.
Pseudonymous device identifier. Used to attribute earnings to the correct developer. Not linked to user account details. Rotates.
Traffic metadata. Bytes transferred, timestamps. Required for reporting and anti-abuse.

Specifically not processed:

No file contents.
No contact lists, messages, photos, or browsing history.
No precise location.
No user account details from your app.

The integration is designed to satisfy data minimisation at the architectural level, not as a policy declaration that depends on developer behaviour.

Data subject rights

Users retain the standard UK GDPR rights:

Right of access (Article 15). The user can request a copy of what is held about them in the bandwidth-sharing scope.
Right to erasure (Article 17). Withdrawal of consent triggers cessation of processing for new data; existing records are purged within the standard retention window.
Right to object (Article 21). The settings toggle is the practical mechanism for objection.
Right to portability (Article 20). Not typically applicable to traffic metadata but available on request.

The developer is the user’s primary contact. The platform supports requests promptly through the joint controller addendum. Privacy contact email: [email protected].

Children and the age limit

The bandwidth-sharing feature is for users aged 18 and over only. Developers must not enable it for children or for users they know, or should reasonably know, are under 18. The mechanism:

Age confirmation as part of the consent flow, either explicit at first launch or inferred from existing verified account data.
If the app’s target audience includes children, the feature should be disabled by default with no opt-in path.
If a user later identifies as under 18, immediately cease processing for that user.

This is a hard limit, not a soft preference. Apps that ship to children’s audiences should not enable the feature.

Practical rollout checklist

Add the disclosure block to your T&Cs in a clearly headed section.
Update your privacy policy with the data categories listed above.
Ensure consent acceptance is active and unambiguous at first launch.
Confirm the user can decline without losing the app’s primary service.
Ship a visible settings toggle for withdrawal. Persist the state.
Confirm age applicability for your audience and add the appropriate gating.
Link to the Joint Controller summary at the SDK consent page.
Record decisions in your data protection documentation. The accountability principle requires a paper trail.

The takeaway

GDPR-compliant consent for a bandwidth-sharing SDK is not magic. It is plain-language disclosure, active acceptance, easy withdrawal, joint-controller transparency, and data minimisation at the architectural level. The pattern fits cleanly into existing T&Cs without a separate consent modal, provided the disclosure is unambiguous and the withdrawal mechanism is visible.

For related reading, see our ethical consent guide and the formal SDK consent page. Privacy contact: [email protected].

FAQ

What is the legal basis for a bandwidth-sharing SDK under GDPR?

Consent under Article 6(1)(a) of UK GDPR (and the EU equivalent), plus PECR Regulation 6 for storing or accessing information on the user’s device. The bandwidth-sharing feature must be explained in plain language and the user must accept it actively, not by default. Withdrawal must be as easy as giving consent.

Is bundling the disclosure into existing T&Cs sufficient?

Yes, when the T&Cs include a clearly headed section describing the bandwidth-sharing feature, the data it uses, the developer’s role, and the third-party processor relationship. The user accepts the T&Cs as a whole, and the SDK reads the consent state. A separate opt-in modal is not required, provided the disclosure inside the T&Cs is unambiguous.

Who is the controller of the personal data?

Joint controllers. Under UK GDPR Article 26, the integrating developer and the SDK platform jointly determine the purposes and means of processing. The GetPassive Joint Controller Addendum defines the responsibilities of each party: the developer handles direct user contact, the platform handles infrastructure operation, both contribute to the lawful processing record.

What data is collected and is it minimal?

IP address, approximate region, a pseudonymous device identifier, and traffic metadata such as bytes transferred and timestamps. No personal files, contacts, messages, photos, or browsing history. The model is built to satisfy data minimisation under Article 5(1)(c) of UK GDPR.

What about under-18 users?

The bandwidth-sharing feature is for users aged 18 and over only. Developers must not enable it for children or for users they know, or should reasonably know, are under 18. The age confirmation can be part of the standard onboarding flow or inferred from existing account data where appropriate.