Data and Privacy
What the Module does with your users' data
One clear position
Before you integrate, this is the privacy posture you’d be adopting – what the Module accesses on your users’ devices, what it can never reach, and the rights it preserves. Written plainly enough to relay to your users, precisely enough for your legal team.
What the Module does
It routes small, read-only requests for public web pages through opted-in devices
When a user opts in, the Module uses a small, capped share of their connection’s spare capacity to fetch public web pages
The kind of content anyone can see by opening a browser
Each opted-in device is one of millions in the network. Each request is small. The Module backs off when the device is busy, so the user’s own experience is unaffected
What the Module accesses
Three things and nothing that identifies your users
That’s it. No personal information, no account data, no contact information
| What | Why |
|---|---|
| The user's IP address | To route web requests through their connection |
| Basic connection info | Whether they're on Wi-Fi or mobile, their general region, and their connection type |
| A device identifierrandom string | A random string that lets the network recognise the device across sessions. Not tied to a name or identity |
What the Module can never reach
The things your users worry about - none of them are reachable
This isn’t a policy promise you have to vouch for. The Module is technically built so these things are out of reach – even if it wanted them.
Their files
Photos, documents, downloads. None of it is accessible.
Browsing history & cookies
What a user does in their browser stays theirs.
Anything typed or seen
No keystroke capture. No screen reading. No usage tracking.
Messages, contacts, calls
The Module has no permission to read any of it.
Your other apps
Their identity
Nothing the Module uses is tied to a user’s name or who they are.
What the requests are for
The same web-fetching anyone does - just at scale
Vetted enterprise partners use the network to access public web pages, for things like:
- AI assistants checking facts on the live web
- Market research platforms tracking prices or news
- Compliance teams monitoring public information at scale declaration
- Financial systems tracking events as they happen
Routed requests originate from your users’ IP addresses. That’s what routing through a device means, and our Privacy Policy says so plainly.
It’s also why the controls above exist: destinations are restricted to permitted public web content, buyers are KYC-verified by Oxylabs, and anomalous traffic is blocked in real time.
Your users aren’t the ones initiating those requests, and their personal identity isn’t provided to the buyer. Their connection simply routes requests to permitted web pages on the buyer’s behalf.
Want to understand who Oxylabs is, how the relationship works, and what happens inside the routing network?
Your users keep control
Every user decides whether it runs and you're expected to honor that
1
They opt in first
The Module never starts until a user has agreed on the consent screen you show them. No consent, no traffic.
2
They can opt out at any time
3
Opting out has to be simple
One toggle. No emails, no support tickets, no waiting periods. Making this easy isn’t optional – it’s a contractual requirement of integrating.
4
They can change their mind
Opting out doesn’t lock a user out. They can opt back in whenever they want.
Your users' rights
The rights your users have
These rights come from GDPR (Europe), CCPA (California), and similar laws elsewhere. They’re honoured whether or not a user’s country specifically grants them – globally, by default
- Know what data is collected and why it is used
- Access a copy of the data the network holds
- Delete the data the network holds about them
- Opt out of data use instantly with the in-app toggle
Where to go for more
That's the end of the plain-language version
The binding documents are below. Your legal team will want these.
