1. Purpose
This SDK & Peer Network Transparency document explains how Infatica’s SDK-enabled peer network is intended to operate, how peer participation is disclosed, how consent and opt-out are handled, and what information is processed for peer network governance.
This document is designed for Trust Center publication and may also be referenced from partner agreements, customer agreements, privacy notices, data protection addenda, app-store review materials, platform-review responses, and security questionnaires.
2. What the SDK / peer network is
Infatica’s SDK-enabled peer network is a consent-based mechanism through which eligible end-user devices may participate as network peers supporting connectivity and data routing capabilities for Infatica commercial services, including residential and mobile proxy services.
The SDK may be integrated into partner applications by approved publishers. End users who are presented with the approved disclosure and consent flow may opt in to participate. Only users who have provided the required consent or opt-in through an approved mechanism may participate as peers.
Infatica determines which eligible opted-in devices are used as active network nodes. Infatica is not required to use every eligible device and may exclude devices based on geography, network quality, compliance, security, abuse-prevention, technical, operational, or business criteria.
3. Participation model
Peer participation must be disclosed, voluntary, and revocable. Partner applications must not activate SDK participation before the approved consent screen or disclosure flow is presented and the user has completed the required opt-in action.
| Requirement | Minimum position |
|---|---|
| Disclosure before activation | The user must see an approved notice explaining SDK participation before activation. |
| Consent / opt-in | The user must explicitly opt in or otherwise provide the consent required by applicable law and approved partner documentation. |
| No forced bundling | SDK participation must not be bundled with required app features in a way that makes consent non-voluntary. |
| Opt-out availability | The user must be able to withdraw participation through the partner application settings, app interface, uninstall process, support process, or other approved mechanism. |
| Partner compliance | Partners must comply with applicable privacy laws, app-store rules, platform policies, and Infatica partner requirements. |
4. Approved consent screen and partner requirements
Partners integrating the SDK must present the approved opt-in screen or approved alternative consent language before activating SDK participation. Partners must not modify the consent language, screen, or SDK behavior without Infatica’s prior written approval.
The approved consent flow should explain, in clear language:
- that the partner application includes Infatica SDK functionality
- that participation may allow the device to contribute limited network bandwidth as part of the Infatica peer network
- what benefit the user receives, if any, in exchange for participation
- that participation is voluntary
- how the user can opt out or withdraw consent
- what data is processed for SDK participation
- where the user can read the applicable privacy notice and terms
| Consent artifact | |
|---|---|
| Standard consent screen text | The partner application must present clear opt-in language explaining that the application includes Infatica SDK functionality, that participation is voluntary, that the device may contribute limited network bandwidth as part of the Infatica peer network, and that the user may opt out or withdraw consent at any time. |
| Consent screen diagram | The approved consent flow should be documented by the Partner and made available to Infatica upon request, including screenshots or equivalent evidence showing the user notice, opt-in action, and opt-out path. |
| Partner privacy policy language | The Partner’s privacy policy must disclose the integration of the Infatica SDK, the purpose of SDK / peer network participation, the categories of data processed, the voluntary nature of participation, and the available opt-out or withdrawal mechanism. |
| Terms of Service link | The partner application must provide users with access to the applicable Infatica terms, privacy notice, and any partner-specific terms governing SDK / peer network participation. |
| App-store disclosure language | Where required by app-store, platform, or applicable policy requirements, the Partner must disclose SDK / peer network functionality in the app-store listing, privacy section, permissions disclosure, or equivalent user-facing notice. |
| Consent evidence retained | The Partner and/or Infatica should retain reasonable evidence of consent, withdrawal, participation status, and relevant consent-flow versioning for compliance, audit, partner-management, and dispute-resolution purposes. |
The exact consent screen, screenshots, app-store wording, and partner privacy-policy language may vary by Partner application, platform, jurisdiction, and approved SDK implementation. Partners must not activate SDK / peer network participation unless the applicable notice, consent, and opt-out requirements have been implemented.
5. Opt-out, withdrawal, and network peer consent revocation
Users may revoke SDK / peer network participation at any time through the approved opt-out mechanism made available in the relevant partner application. Once withdrawal is received and processed, the device should no longer be designated as an active peer for new network participation, subject to technical propagation and operational constraints.
Partner applications must promptly remove or disable the user’s designation as an Infatica network participant when the user withdraws through the app or another approved mechanism.
| Revocation item | |
|---|---|
| Primary opt-out method | Users may revoke SDK / peer network participation through the opt-out control, settings, consent-management interface, or other withdrawal mechanism made available in the relevant partner application. |
| Secondary opt-out method | Where app-based opt-out is unavailable or the user wants Infatica to review Infatica-controlled records, the user may submit a privacy request through Infatica’s applicable privacy request process. |
| Propagation time | Withdrawal is processed in accordance with the applicable technical and operational process. The device should no longer be designated as an active peer for new network participation after the withdrawal is received and processed, subject to technical propagation and operational constraints. |
| Post-withdrawal device status | The device should be removed or excluded from active SDK / peer network participation for future sessions, subject to implementation by the relevant partner application and Infatica’s network governance controls. |
| Historical records retained | Historical records may be retained where reasonably necessary to evidence consent, withdrawal, participation status, partner compliance, network integrity, abuse prevention, security, legal compliance, and dispute resolution. |
| Deletion request route | Users may request deletion, restriction, or review of Infatica-controlled records through Infatica’s applicable privacy request process, subject to verification, applicable law, technical feasibility, and retention exceptions. |
| Escalation contact | Requests should be submitted through Infatica’s applicable privacy request process or the contact channel published in the relevant privacy notice, Trust Center, or partner application. |
6. Data processed for SDK / peer network
The SDK / peer network may process limited technical and operational data necessary for consent management, peer eligibility, network connectivity, routing governance, fraud prevention, abuse prevention, security, partner payments, DAU calculation, support, and compliance.
| Data category | Purpose |
|---|---|
| IP address | Routing, country/region inference, network eligibility, fraud/abuse prevention, DAU rules. |
| Connection metadata | Network status, timestamps, availability, connection duration, activity status. |
| Device/network metadata | Limited technical metadata required for SDK operation and abuse prevention. |
| Partner application identifier | Partner integration governance, attribution, partner payments, compliance. |
| Consent status | Verify opt-in and participation eligibility. |
| Withdrawal status | Exclude withdrawn users/devices from participation. |
| Country/region information | Geo-level routing and DAU/payment calculations. |
| Bandwidth / traffic volume metadata | Operational measurement, billing/payment, abuse prevention. |
| DAU / activity calculation records | Partner earnings calculation and auditability. |
| Security / abuse logs | Network integrity, complaint handling, abuse prevention. |
7. Data the SDK is not intended to collect
The SDK is not intended to collect, store, or transmit the following categories of data from the host device:
- browsing history
- application content from the host app or other apps
- messages, contacts, photos, files, or local user content
- precise GPS location
- IMEI, advertising ID, or persistent device fingerprint identifiers, unless expressly disclosed and approved in a specific implementation
- payment credentials, passwords, authentication tokens, or financial account credentials
- special category data or children’s data
8. Traffic routing and peer protections
The peer network is intended to route limited customer requests through eligible opted-in peer devices under Infatica’s network governance. Operational activation may depend on consent status, availability, connectivity, power, Wi-Fi or network state, quality, region, traffic volume, security, abuse-prevention, and other criteria configured by Infatica and/or the relevant Partner.
| Traffic item | |
|---|---|
| When a peer device may be used | A peer device may be used only where the user has opted in or otherwise validly enabled participation, the partner application has implemented the approved consent and opt-out flow, and the device meets applicable operational criteria such as availability, connectivity, quality, region, traffic-volume, security, and network-governance requirements. |
| Whether peer can inspect customer traffic content | Peer users and partners are not authorized to inspect, access, use, modify, or disclose customer traffic content. Traffic routing is managed under Infatica’s network governance and technical controls. |
| Whether customer can see peer-level identifiers | Customers may receive limited technical information necessary to use the service, such as proxy type, location or session-related service parameters. Customers are not intended to receive personal identifiers of individual peer users or unnecessary peer-level data. |
| Whether traffic is encrypted in transit | Infatica applies technical safeguards designed to protect traffic in transit where appropriate and supported by the relevant protocol, service configuration, and customer implementation. |
| Traffic volume limits | Traffic volume, bandwidth usage, routing eligibility, session behavior, and operational thresholds may be limited or adjusted based on service plan, network quality, peer protection, abuse prevention, security, partner requirements, and network-governance controls. |
| Peer device exclusion / blocklist process | Infatica and/or the relevant partner may exclude, disable, restrict, or block a peer device from participation where required for opt-out, consent withdrawal, abuse prevention, security, compliance, technical quality, partner governance, or legal reasons. |
| Abuse detection controls | Infatica may use monitoring, traffic-pattern analysis, domain/category controls, rate limits, risk-based restrictions, blacklist/whitelist logic, suspension, blocking, and other controls to detect, prevent, investigate, and respond to abuse, fraud, unlawful activity, security threats, or policy violations. |
9. Partner obligations
Partners integrating the SDK must:
- provide legally sufficient notices and obtain all required consents or opt-ins before SDK activation
- present only the approved consent screen or approved alternative language
- not modify, reverse engineer, interfere with, disable, or misrepresent the SDK
- make opt-out controls available in the partner application
- promptly remove withdrawn users from SDK participation through the approved mechanism
- include required Infatica references, privacy notices, and terms links in the application and applicable app-store sections
- comply with privacy laws, app-store rules, platform policies, and partner documentation
- cooperate with Infatica in responding to platform, privacy, security, abuse, or user concerns
- update SDK versions within the timeframes required by Infatica partner documentation
- not integrate competing or functionally similar SDKs where prohibited by the applicable partner agreement
10. Audits, PUA classifications, and platform concerns
Background-traffic SDKs can receive Potentially Unwanted Application (PUA) classifications or platform-review questions even where the software operates legitimately. Infatica treats PUA classifications and platform concerns as serious matters and may engage with antivirus vendors, app stores, platforms, and researchers to explain the SDK behavior, consent model, security posture, and audit results.
If a partner integrates the SDK without proper disclosure or consent, Infatica may revoke partner access, remove the affected SDK instances from the network, suspend partner payments, and terminate the partner relationship where permitted by the applicable agreement.
| Audit / transparency item | |
|---|---|
| Independent SDK audit reports | Audit reports or summaries may be made available to qualified reviewers upon reasonable request, where completed and approved for disclosure, subject to confidentiality, scope, security, and commercial restrictions. |
| SDK Safety & Transparency Center | Infatica may publish SDK safety, consent, opt-out, partner requirements, audit summaries, and platform-review materials through the Trust Center or other dedicated transparency resources. |
| PUA escalation contact | PUA classifications, antivirus concerns, or software-review questions should be submitted through Infatica’s applicable Trust Center, security, or platform-review contact process. |
| Platform reviewer contact | App-store, platform, browser, antivirus, or compliance reviewers may contact Infatica through the applicable Trust Center or platform-review request process. |
| Security researcher contact | Security researchers may submit SDK, website, dashboard, API, or infrastructure security concerns through Infatica’s applicable security reporting or Trust Center process. |
11. Relationship with Privacy Policy, DPA, and AUP
The Privacy Policy explains Infatica’s processing of Personal Data, including SDK / peer network data where applicable. The Data Protection Addendum explains Infatica’s controller role model and data protection commitments. The Acceptable Use Policy explains customer and reseller restrictions, abuse prevention, and prohibited activities on the network.
If the SDK / peer network information in this document changes, Infatica should update this document, the Privacy Policy, applicable partner documentation, and any Trust Center references to avoid inconsistent disclosures.
12. Contacts
| Purpose | Contact |
|---|---|
| SDK / platform partner inquiries | — |
| Privacy / data subject requests | — |
| Security reports | — |
| Compliance documentation | — |
| Partner management | — |
