What an Android VPN can see about you (and what we don’t)

A VPN provider sits in the middle of your network traffic by design. That position grants visibility, and there is no way around it. The honest question is not “does the provider see anything?” but “what specifically is in their view, what do they technically retain, and how would you verify either claim against their code?” This post walks through that question for the Android VPN model in general and for TuxlerVPN Mobile specifically.

The Android VPN permission model

When you install any VPN on Android, the app requests the system BIND_VPN_SERVICE permission. The first time you tap connect, Android shows a system dialog confirming that the app intends to monitor your network traffic. Granting it does several things:

• The app can call VpnService.Builder to create a virtual network interface and claim routes, usually 0.0.0.0/0 and ::/0, meaning all traffic.
• The OS hands the app a file descriptor for that virtual interface. Outgoing IP packets are read from the descriptor. Incoming packets are written back.
• The app does not gain other privileges. It cannot read other apps’ storage, see your microphone, or escalate to the system. Network is the surface.

What this means in practice: a VPN app’s visibility is bounded by what it explicitly asks for in its AndroidManifest.xml. Every Android app’s manifest is publicly inspectable via the APK on the Play Store, so the permission set is verifiable evidence rather than a marketing claim.

For reference, the permissions TuxlerVPN Mobile asks for are:

• INTERNET
• FOREGROUND_SERVICE and FOREGROUND_SERVICE_SPECIAL_USE
• REQUEST_IGNORE_BATTERY_OPTIMIZATIONS
• com.android.vending.BILLING (for Premium via Google Play)
• ACCESS_NETWORK_STATE
• POST_NOTIFICATIONS
• RECEIVE_BOOT_COMPLETED

What is not on that list is intentional. We do not request READ_PHONE_STATE (which would let us read IMEI on older Androids). We do not request ACCESS_FINE_LOCATION or ACCESS_COARSE_LOCATION. We do not request READ_CONTACTS, READ_SMS, CAMERA, RECORD_AUDIO, or any of the storage permissions. We do not embed Google Play Services for the Advertising ID.

What every VPN provider technically sees at the gateway

Independent of which provider you pick, a VPN gateway is on-path for your traffic and therefore observes:

• The source IP of the inbound tunnel. Your home or carrier IP, or the IP of whatever network you are on.
• The destination IP of every outbound packet. Where the gateway is forwarding traffic to.
• Packet sizes and timing. Even when payloads are encrypted by HTTPS, the size and cadence of TLS records often reveals what kind of activity is happening (a video stream looks different from a chat client).
• TLS Server Name Indication. Until Encrypted Client Hello rolls out broadly, the SNI field in the TLS ClientHello names the destination host in the clear, so the gateway sees example.com even if it cannot read the body.
• DNS queries that exit the tunnel. If the app pushes DNS into the tunnel (as ours does), the gateway-side resolver sees the queries.

There is no software-engineering trick a VPN provider can use to avoid being able to see this. A claim that the gateway sees “nothing” should not be taken at face value. The honest framing is that the gateway sees these things in real time and chooses not to retain them.

What a VPN’s app could collect from the device

A VPN app, like any app you install, can collect data from the device subject to the permissions it holds. The realistic upper bound (what a VPN app could collect if it wanted to) includes:

• A persistent device identifier (e.g., an SSAID, an Advertising ID if Play Services is integrated, or a generated UUID).
• Device manufacturer, model, OS version, app version.
• Network-state changes (tunnel up/down, network type).
• Crash reports (which often include a stack trace and contextual metadata).
• Anything the user types into the app (feedback forms, support messages).
• Any of the permission-gated surfaces above if the app has been granted them.

The gap between “could collect” and “does collect” is where the trust question lives. We answer it with a list, not a slogan.

TuxlerVPN Mobile’s actual collection list

The full record lives in Data Processing Overview and Logging & Retention Data, and the lawful bases live in Privacy Policy §2. To make this post useful as a starting point, here is the same list in shorter form:

• App-instance UUID. Generated locally on first launch. It is the only stable identifier we tie service operations to. There is no email, no name, no phone number, and no Google Advertising ID associated with it on our side.
• Device manufacturer, device model, Android version, app version. Used to debug compatibility issues and to plan compatibility coverage. No serial number, no IMEI, no Android ID.
• Server-region selection. Which country the user picked for this session. Used to route the connection.
• Connection metadata during an active session. Session-only, discarded on disconnect (Privacy Policy §2.6, §8).
• Sentry crash reports. Crash type, stack trace, app version, Android version, device model. Retained per Sentry’s standard schedule, typically 90 days. (Data Processing Overview §5.)
• Google Play purchase token. For Premium subscribers only, used solely for entitlement verification.
• In-app feedback content. When you submit feedback, the message and the app-instance UUID. No name or email is collected.

What we do not have, structurally:

• No email address. We do not require one to use the app, free or Premium.
• No name, phone number, or government-ID information.
• No Google Advertising ID (the SDK is not embedded).
• No browsing history, DNS-query log, or per-session traffic content (Privacy Policy §2.6).
• No persistent connection-metadata log after disconnect.

Why “no email” is a structural property, not a promise

Most VPN providers operate by creating a user account: you sign up with an email, you confirm it, you set a password, you log in to the app. That account is then the join key between everything else the provider stores about you.

TuxlerVPN Mobile does not create an account on first install. The app generates a UUID on the device the first time it runs and uses that UUID to call our backend at apivpn.tuxlervpn.app. There is no signup flow. Premium is purchased through Google Play and the entitlement is keyed off the Play purchase token. We do not separately collect your Play account email.

This is “structural” in the sense that we cannot produce data we never collected. If a court order asked us for the email associated with a UUID, we would have to answer “we have none.” That is the property our Transparency Report framework is set up to measure once the app has launched.

How to verify any of this for any VPN you consider

Three checks anyone can do:

1. Read the manifest. Pull the APK from the Play Store (or use any APK-inspection tool) and look at AndroidManifest.xml. The permission list is ground truth for what the app can ask the OS for. Compare it to what the privacy policy claims.
2. Check the SDK list. Many privacy policies list “third-party SDKs” or “service providers.” Crash reporters, analytics SDKs, and ad SDKs each represent data leaving the app for a different operator. Fewer SDKs is generally a better signal than more.
3. Read the retention table, not the marketing page. The retention table is the bit a regulator can hold the company to. Marketing copy is not.

Our retention table is at Logging & Retention Data. Our SDK list is in Data Processing Overview §5. Our manifest is what ships in the APK.

FAQ

Can the gateway see my passwords or messages?

In the typical case, no. Those travel inside HTTPS, which the gateway cannot decrypt. The gateway sees the destination IP and TLS SNI in real time but does not retain them after disconnect, per Logging & Retention Data.

What about the Sentry crash reports, what’s in those?

Crash type, stack trace, app version, Android version, device model. Sentry is a US-based processor. The data is retained on Sentry’s standard schedule, typically 90 days. The lawful basis is legitimate interest. Source: Data Processing Overview §5.

How is the app-instance UUID different from a Google Advertising ID?

The app-instance UUID is generated locally and is private to TuxlerVPN Mobile. No advertiser sees it, no other app has access to it, and resetting the app deletes it. The Google Advertising ID is a system-level identifier shared across apps for ad attribution. We do not collect it.