Analysis of 30 Popular (Paid) Android VPNs

Over the last six years of investigating free VPNs, I’ve developed a comprehensive set of technical tests to identify security and privacy flaws in Android VPN apps.

I most recently ran these tests on the top 100 free Android VPN apps, with disturbing results.

Together with my colleagues, I’ve conducted thousands of tests on paid VPNs over the years as part of our review process, but this is the first time I’ve applied my free VPN testing methodology on leading paid VPNs.

Why now? Two reasons:

1. I wanted to identify any potential safety issues with leading paid VPN services’ Android apps and warn users.
2. It made sense to establish a benchmark to put my free VPN findings in a proper context, so I could begin to quantify the privacy and security gap between free and paid VPNs.

The 30 most popular paid Android VPNs have been installed over 732 million times worldwide.

This is a significant and growing number of people who entrust their sensitive data to paid VPN services and who have the right to expect the very highest standards.

I installed each of these 30 apps on my Android test devices and carried out a series of in-depth technical tests, aiming to cover every important aspect of VPN privacy and security.

Use the links below to jump ahead to an analysis of my findings for that particular area.

• DNS and other leaks
• VPN encryption issues
• VPN tunnel stability
• Risky app permissions
• Risky use of device hardware features
• Data collection and sharing

These topics map closely to the most recent work I did on free VPNs, allowing for easy comparison.

All the VPN apps were downloaded directly from Google Play and installed on entry-level Samsung smartphones. We paid for subscriptions out of our own pocket.

My tests used publicly-available tools, including our own VPN leak checker, along with Wireshark, mitmproxy and others.

I intercepted VPN traffic in a dedicated “clean-room” environment to ensure consistent and accurate data captures.

The test results were largely reassuring.

Only a small number of paid VPN apps were affected by significant security and privacy issues.

It was disappointing however to see that half of the apps tested revealed that a VPN was active to anyone even casually monitoring the connection.

I also identified some areas for general improvement even among the top-rated providers.

Most notable were data leaks that took place under very specific conditions and the use of third-party rather than first-party DNS servers.

I’d also like to see more VPN apps use the very strongest possible protocols and cipher suites for encryption.

The difference with my previous findings, however, was stark.

Unlike the free VPN apps I tested, the paid VPNs did not suffer from encryption failures nor widespread data leaks while their VPN tunnels were much more stable.

While you might expect paid VPNs to be safer and more private than free services, my findings also showed that not all paid VPNs had the same high standards.

A small number of the popular Android VPN apps I tested had issues that their developers failed to address despite my repeated attempts to reach out to them.

To test for data leaks and VPN encryption issues, I used Wireshark to capture network traffic from my Android test devices as I connected to VPN servers and visited our test domains.

I analyzed this capture data for evidence of packets related to my browsing that hadn’t been routed via the VPN tunnel.

I also used this data to audit how each app established its VPN tunnel, looking for security issues as well as any deviations from best practice.

I also used our own VPN data leak testing tools to determine whether DNS requests made while connected to the VPN were resolved as privately as possible.

Data Leaks: Paid vs Free VPN Comparison

Here’s a table showing the results of my latest data leak test results for paid VPNs, compared with my earlier findings for free VPNs.

Flaw	Paid VPNs	Free VPNs
Full DNS leak	0%	9%
Partial DNS leak	23%	2%
Third-party DNS servers	23%	83%
Unencrypted SNI	50%	79%
HTTP data exposure	3%	9%
IPv6 leak	0%	15%
IPv4 leak	0%	3%

It’s very positive to see the lack of major leaks affecting the leading paid VPNs.

There remains room for improvement in certain areas, however, such as encryption of SNI (Server Name Indication) and what I’ve called “partial DNS leaks”, which I explore in more detail in the next section.

DNS Leaks

If a VPN tunnel is configured correctly, almost all traffic should be routed through it.

There should be no traffic visible at all except for what’s generated by essential operating system-level processes or core Android background tasks. This traffic inherently bypasses the VPN to ensure critical updates reach your device, for example.

In practice, though, it’s not uncommon for DNS requests related to your VPN app’s data analytics and advertising to also be routed outside the tunnel.

While technically data leaks, I did not treat them as such for the purposes of this report, as the privacy impact is minimal.

Aside from the above, the only leaked DNS requests I observed were from our leak testing tool.

Those leaks affected the following 7 VPNs.

VPN Name	Developer	Package Name
HMA!	Privax	com.hidemyass.hidemyassprovpn
Private VPN	PrivateVPN	com.pvpn.privatevpn
Mozilla VPN	Mozilla	org.mozilla.firefox.vpn
Privado	Privado Networks	io.privado.android
VyprVPN	Golden Frog	com.goldenfrog.vyprvpn.app
X-VPN	Free Connected	com.security.xvpn.z35kb
Avira Phantom	Avira Operations	com.avira.vpn

This is unusual so I investigated further. I found that the affected VPNs appeared to only leak DNS requests under the following conditions:

1. The web page was already open prior to connecting to the VPN.
2. The open page generated additional DNS requests initiated by JavaScript after the VPN connection was made.
3. The additional DNS requests were made in the first 10-20 seconds immediately following the VPN connection.

Subsequent DNS requests generated by navigating away to other pages on our or other domains routed correctly via the tunnel and were not visible, greatly limiting the extent of the leaks.

These data leaks are unlikely to be limited to DNS queries initiated by JavaScript. This just happens to be what we used to build our our leak test tool.

Modern web pages use many different programming languages to deliver interactive experiences, many of which will generate DNS queries after the initial page load.

A properly configured VPN should terminate all existing network connections to prevent this from happening.

Unencrypted SNI

This type of leak is relatively minor for most people. For certain groups of users, however, there can be serious consequences.

It was also highly prevalent, affecting half the apps (15 VPNs) I tested.

SNI is an extension to the TLS protocol which allows a client to indicate the hostname of the server it’s trying to connect to during the handshake process.

This allows multiple secure sites and services to be served by the same IP address.

SNI data is inherently unencrypted so requires additional steps to be taken to hide it.

The affected VPN apps failed to do this for absolutely all the secure server connections they initiated.

Most crucially, they typically overlooked encrypting SNI for traffic to their own back-end services, such as analytics for example.

To be absolutely clear, the server requests with exposed SNI were made before the VPN tunnel was established, so there’s no suggestion that any tunnels were compromised.

Once the VPNs were actually connected, SNI payloads were no longer visible as they were encrypted as VPN traffic.

Nevertheless, as you can see above, domains clearly related to VPN providers, such as updates.torguard.biz or api.tunnelbear.com, for example, were exposed to anyone eavesdropping on the connection prior to activating the VPN.

Anywhere VPN use is restricted, such as high-censorship countries, or even in schools and workplaces, failing to encrypt SNI payloads can result in serious repercussions for users.

This is most pertinent in a countries like Turkey or Iran where VPNs are effectively banned.

If someone in that country has a VPN installed on their device and unencrypted SNI tips off their ISP then that could cause problems for that person.

It’s also very easy for students to install VPNs on their school devices even with strict restrictions in place.

Again, a simple stray request to a VPN domain could tip off the school network admin, unexpectedly landing that student in trouble, even without actually connecting to the VPN.

Exposed PII

This data leak was limited to a single paid VPN app, FastestVPN.

In a highly disturbing discovery, I observed my email address transmitted in clear text to third-party IP geolocation service IP-API.com.

In the screenshot above you can see my email address, appended with the UNIX timestamp of my sign-in to my VPN account, being used in a custom HTTP header.

This is most likely some kind of session-tracking mechanism.

Personally identifiable information (PII) should never be used like this, even over a secure connection.

Sending it in clear text leaves it completely vulnerable to interception, along with the Authorization: Bearer token also visible in the same packet.

This is very poor security practice and casts severe doubt on the overall security posture of the FastestVPN Android VPN app.

If you’re using the FastestVPN Android app, I recommend uninstalling it immediately.

Third-Party DNS Servers

Your DNS queries reveal a surprising amount about your browsing habits, despite only showing the domains you visit rather than specific pages.

A log of your DNS queries can reveal not just your interests, hobbies and political leanings but also any health or financial concerns, or other private matters.

The timestamps on each DNS query can also provide insights on your daily schedule, such as when you’re awake or asleep, at home or at work, etc.

DNS request data can even be used to infer your location, based on your visits to local websites, or information about the devices on your network.

So for a VPN to be fully effective, it’s crucial that it ensures your DNS queries remain private.

Unfortunately, not every VPN service operates its own DNS servers and instead uses third-party servers to resolve your DNS requests.

To find out what DNS servers your device is using for your current session, you can use our free DNS server checker.

Using a third-party DNS server is certainly better than simply leaking your DNS requests to your ISP’s DNS servers. However, it means that the VPN service must trust that third party not to log your DNS data.

It’s another possible point of failure. What’s more, some third-party DNS servers are better than others.

While definitely worse for privacy than first-party DNS, Google and Cloudflare are generally preferable to less well-known operators.

I found 7 paid VPN apps using third-party DNS servers. This put users’ privacy at greater risk through the lack of oversight over DNS resolution.

Of these, 4 VPNs used Google DNS and 1 used Cloudflare, while 2 used other third-parties.

App Name	DNS Server	Package
VPN.AC	3P Servers	ac.vpn.androidapp
VyprVPN	3P Servers	com.goldenfrog.vyprvpn.app
Astrill VPN	Cloudflare DNS	com.astrill.astrillvpn
Hotspot Shield VPN	Google DNS	hotspotshield.android.vpn
PandaVPN Pro	Google DNS	com.pandavpn.androidproxy
Psiphon Pro	Google DNS	com.psiphon3.subscription
X-VPN	Google DNS	com.security.xvpn.z35kb

The proportion of paid VPNs using third-party DNS services was much smaller than for free VPNs, where 83% failed to resolve their users’ DNS queries themselves.

Almost 30% of free VPNs used DNS servers operated by third parties other than Google or Cloudflare, which is four times as many as paid VPN services doing so.

However given that paid VPNs generate subscription revenue, it’s difficult for any such service to justify this omission on cost grounds.

Hotspot Shield was the only VPN provider to offer an explanation of their use of Google DNS rather than resolving user DNS themselves.

They told me that Google DNS was faster than any solution of theirs would be, adding that their users’ privacy was protected due to the principle of security by obscurity, thanks to how Hotspot Shield dynamically balances traffic across its servers.

IP Leaks

No paid VPN that I tested leaked either IPv4 or IPv6 addresses.

In comparison, a surprisingly high number (15%) of free VPNs leaked IPv6 requests while 3% essentially didn’t work as a VPN, on the basis that they leaked your IPv4 address.

To determine the encryption used by each VPN app, I analyzed network traffic captures to identify the default cipher suite.

My aim was to analyze the typical VPN user experience, so I used the default protocol and server for each app.

If the default was a local server, I switched to an international server to meet the requirements of the leak test tool.

VPN Encryption: Paid VPN vs Free Comparison

Here’s a table showing the proportion of paid VPNs using weaker encryption in various forms, side-by-side with my earlier findings for free VPNs for comparison.

Encryption	Paid VPNs	Free VPNs
AES-128	27%	35%
TLSv1.2	23%	18%
SSLv2	3%	6%
Weaker hashing	0%	81%
Weaker key exchange	3%	41%

Paid VPNs were hugely superior in terms of the algorithms they used for hashing and key exchange. The other results were remarkably similar however.

It’s crucial to point out that, use of SSLv2 aside, none of the above encryption issues means that the affected VPNs are insecure. They could however be more secure.

I found 8 paid VPNs using AES-128 to encrypt your internet connection. This cipher is generally considered “good enough” but it really is the bare minimum.

Given that AES-256 is significantly more secure with no noticeable performance cost for most users, there’s very little reason not to use it.

It’s a similar story with the use of the ageing TLSv1.2 by 7 paid VPNs for their handshake protocol.

This older version of TLS, dating from 2008, remains secure for now. Yet there is no compelling reason not to use the superior TLSv1.3, especially as it’s been available since 2018.

The use of AES-128 and TLSv1.2 was proportionally similar in both paid and free VPN apps.

By contrast, the difference was significantly more marked when it came to the choice of algorithms for hashing and key exchange.

Every paid VPN app used the strongest hashing algorithms, compared to just 19% of free VPN apps.

Psiphon Pro was the only paid VPN to use an arguably sub-optimal key exchange algo, compared to 41% of free VPN apps.

The Psiphon app opted for ecdh-sha2-nistp256 over the newer, faster and potentially more secure Ed25519.

The choice of the SSLv2 protocol is by far the most serious issue. Fortunately, Avira Phantom was the only paid VPN app to use SSLv2, compared to 6 free VPNs.

This 30-year-old protocol is completely obsolete, as it was quickly superseded by SSLv3 then the various versions of TLS that followed.

SSLv2 belongs nowhere near any modern VPN app.

It was therefore highly troubling that over 6% of packets to the VPN endpoint were over this obsolete protocol during my Avira Phantom VPN test session.

Such a high volume of packets suggests that not only was SSLv2 used in the establishment of the VPN tunnel but also actively involved in the encryption and decryption of data.

This is a huge red flag from a security standpoint and a major reason to avoid using Avira Phantom VPN.

Finally, Astrill’s choice of default VPN protocol could be lulling its users into a false sense of security.

Unless you manually select a more secure alternative, Astrill’s Android app connects using its proprietary OpenWeb protocol.

OpenWeb is a great choice for unblocking geo-restricted content because it’s fast and hard to detect. However this comes with potential security trade-offs that aren’t ideal for a VPN client’s default protocol.

OpenWeb is a stateless protocol that uses TCP/WebSocket connections.

Aside from the usual questions marks over any closed-source protocol, WebSocket-based VPN connections are more vulnerable to injection attacks than traditional VPN connections.

OpenWeb also relies heavily on the underlying TLS layer, which can be less resilient in environments where TLS traffic is routinely intercepted, such networks with any kind of content filtering or monitoring in place.

This contrasts with other VPN protocols, which include additional security layers and typically implement their own encryption and integrity checks.

Most of the signs of VPN tunnel instability I detected were very minor.

Only PandaVPN had a clearly abnormal number of TCP Reset (RST) packets (50) for the length of the session.

RST packets close sockets in normal TCP/IP communications. A high volume of these packets suggests network anomalies. This can include congestion, unreliable connections, or misconfigurations, indicating potential instability and vulnerabilities.

Other VPNs only had a handful of TCP RST packets, ranging from a single packet to eight at most. They typically occurred when attempts to establish a VPN tunnel using TLS failed and the app switched to another protocol.

There was significantly less evidence of VPN tunnel instability with paid VPNs compared with free services. A quarter of free VPNs were affected, with an average of nearly 17 RST packets per session.

To ensure I had the most accurate information about the runtime permissions requested by each VPN, I used each app’s Android Manifest file, which is bundled with its source code.

I excluded VPN apps’ use of runtime permissions if they were justified and necessary for a VPN app.

My decisions were based on my own analysis of each VPN app’s functionality and discussions with tech teams at individual VPN providers.

What remains are the proportion of apps that requested the most dangerous Android permissions without sufficient justification.

Risky VPN Permissions: Paid VPN vs Free Comparison

The following table breaks down the proportion of paid VPNs requesting risky permissions by category. The results of my previous free VPN analysis are included for comparison.

Permission	Paid VPNs	Free VPNs
Location	13%	20%
Camera	7%	10%
Read Phone State	3%	9%

While fewer paid VPNs requested risky permissions than free apps, ideally that number would be closer to zero.

Location Tracking Permissions

• ACCESS_COARSE_LOCATION
• ACCESS_FINE_LOCATION
• ACCESS_BACKGROUND_LOCATION

I found 4 paid VPN apps that requested at least one of the above permissions to track your location without sufficient justification.

• Hotspot Shield VPN
• KeepSolid VPN Unlimited
• VyprVPN
• Avira Phantom VPN

It’s quite common for premium VPN apps to request permission to track your location so that they can recommend you the nearest VPN server.

It’s also required by many VPN apps’ implementation of their auto-connect feature for unsecured WiFi networks.

Typically this sensitive data remains on the device and is either used in real-time only or purged after your session.

While Hotspot Shield does require location permissions for its Trusted Networks feature, these permissions also facilitate ad tracking via the Fyber SDK.

The other VPNs listed above may well be requesting to track your location in a safe manner to support core functionality.

However they were either unwilling or unable to confirm this with me, despite multiple requests to do so.

The proportion of free VPN Android apps requesting this type of permission was over 50% higher than in paid VPNs.

Camera

Only TorGuard and FastestVPN requested use of your Android device’s camera without any apparent justification.

Some VPN apps request this permission to make it easier to securely authenticate you, such as giving you the option to scan a QR code.

Others VPN apps with additional functionality, such as password managers, require the camera permission for 2FA.

However, I was unable to determine why TorGuard or FastestVPN required use of the camera. It wasn’t clear from using the apps, nor did either provider respond to my repeated requests for clarification.

In comparison, one in ten free VPN apps requested this dangerous permission that could easily be abused.

Read Phone State

The READ_PHONE_STATE permission allows read-only access to an array of sensitive identifying data about your device and cellular network. This can then be used to track you as you use the internet.

It’s hard to justify why any VPN would need this runtime permission due to the high risk it poses to privacy.

Avira Phantom VPN was the only leading paid VPN to request this permission.

In contrast, 9% of free VPNs requested this permission.

Other Permissions Issues

I also discovered that the HMA! app requested several less common permissions, such access to media files (images, video and audio) and various account management permissions.

After I queried this, the HMA! developers thanked me for bringing it to their attention, describing them as “legacy” permissions relating to a now-obsolete CRM (Customer Relationship Management) system. As a result, the permissions are scheduled for removal in a future app update.

This is certainly a positive development, however it’s a little worrying that such intrusive permissions had been overlooked like this.

The vast majority of potentially risky code in VPN apps relates to third-party advertising.

Most apps that harvest your data do it to grow their business rather than any nefarious purpose.

I excluded from my findings any tracking code or third-party advertising libraries that met our criteria for responsible data practices.

My decisions were based on my years of experience investigating ad tracking in VPN apps, as well as discussions with the VPN providers themselves.

It’s in your best interest as a VPN user for your provider to maintain a strong, profitable user base. This allows them to continue offering a high-quality, secure service.

What you don’t want is for your personal data to be shared with data brokers who may pass it on to third parties with questionable privacy controls.

My analysis is in three parts, each focusing on a separate aspect of third-party data sharing:

1. Risky app source code functions with the required permissions.
2. Advertiser SDKs embedded in the VPN apps.
3. Observable instances of data being shared.

Use the links if you want to jump ahead to that section.

Risky Tracking Code

I decompiled each VPN app using open-source tools and then manually reviewed the results for code functions intended to retrieve sensitive personal data.

I only included instances where that data retrieval did not appear to be necessary for user-facing features and the required permissions were also present.

For example, the use of GPS data to optimize VPN server selection clearly provides a tangible user benefit.

Sharing that data with an advertiser for location-based targeted ads does not.

The risky code I found can be categorized as follows:

1. Location tracking
2. Advertising ID use
3. Sensitive phone data collection

Use the links if you want to jump ahead to the analysis of that category.

VPN Tracking Code: Paid VPN vs Free Comparison

The table below shows the proportion of paid VPN apps whose source code contained functions that posed a potential privacy risk where there was also the required permissions.

The findings are broken down by type of code function and include the most recent free VPN results for comparison.

Code Function	Paid VPNs	Free VPNs
Location Tracking	17%	19%
Advertising ID	14%	72%
Phone Identifiers	3%	9%

Location Tracking Code

I found location tracking code and permissions, beyond what was necessary for core VPN functionality, in the source code of 5 paid VPN apps.

A notable example was the Hotspot Shield app, which included third-party location tracking code as part of its embedded ad-tech. This creates a detailed profile of your device that’s used to target you with ads that follow you around the web.

Jump to the next section on third-party software libraries for more detail about the SDK used to do this, along with Hotspot Shield’s explanation for why they use it.

I also identified location tracking code from Facebook in the paid VPN apps Avira Phantom and KeepSolid VPN Unlimited.

Additionally, HMA!, Avira Phantom, and VPN Unlimited contained their own first-party code for collecting GPS and network location data, though VPN Unlimited claimed to purge this location data.

Elsewhere, Psiphon used the Google Play Services location SDK rather than their own custom implementation, which would have been a safer way to make use of location data within their app as it would allow the Psiphon developers to retain full control of that data.

Overall, the incidence of location tracking code in paid VPNs was similar, if slightly less, than in free services.

Advertising ID

I found that 4 VPN apps contained code for retrieving your unique Google Advertising ID (GAID) that fell outside our definition of responsible advertising.

Your GAID is a long string of letters, like bk9384xs-p449-96ds-r132. It can be used to track your online activity and profile your interests and demographics.

While you can manually reset your GAID in your Android device settings, this is not something the average person is even aware of, let alone does regularly.

X-VPN contains code that collects this unique identifier from your device from several third-party software libraries, most notably from mobile ad networks Vungle and Chartboost.

These networks allow VPN providers to sell ad space in their apps to a huge pool of advertisers but at the cost of sharing user data with those advertisers.

Hotspot Shield also featured similar code, this time in SDKs published by ad tech firms Kochava and Tapjoy, both of whom have run foul of the U.S. Federal Trade Commission.

HMA! also contained similar functionality. This was part of code relating to Huawei, a Chinese firm suspected of being a threat to U.S. national security.

When asked about this, HMA! stated the Huawei ad tracking code was necessary for optimizing campaigns in the Huawei AppGallery. “[Its] use is aligned with industry best practices for targeted advertising,” a HMA! rep told me.

The Huawei ad tracking could arguably be considered responsible advertising, as it’s intended to build HMA!’s user base. However, the controversies surrounding Huawei meant that there was a public interest in disclosing its presence.

After all, no other paid VPNs contained similar code.

Overall, I found paid VPN apps to be significantly lighter on this sort of tracking code compared to free VPN services. Over 70% of free VPN apps featured ad-tech code to retrieve users’ GAIDs.

Sensitive Device Identifiers

Avira Phantom VPN was the only app where I found code to retrieve sensitive device identifiers, such as a device’s IMEI and the cellular network in use, where the necessary permissions were also present.

I found the following method calls for this type of sensitive data in the Avira Phantom app:

• getDeviceId
• getImei
• getNetworkOperatorName
• getMccMnc
• getNetworkType

This information is highly valuable to advertisers and data brokers, many of whom will not offer the level of data protection expected by a premium VPN user.

Unlike a GAID, these identifiers cannot typically be reset with a simple settings change, making them even more sensitive.

For reference, getMccMnc retrieves the device’s Mobile Country Code (MCC) and Mobile Network Code (MNC), which when combined can be used to uniquely identify its mobile network.

See the full list for definitions of all risky code functions.

Other Source Code Concerns

HMA!’s source code revealed just how deeply integrated the VPN app is with the broader Avira product family.

The <queries> tag specifies which other apps HMA! might try to interact with or check for on the user’s device.

Whether this behavior is acceptable or not mainly comes down to individual users’ comfort with a VPN app acting like this.

Advertiser SDKs in VPN Apps

I documented and identified every third-party software development kit (SDK) I found in the source code of each app.

Most SDKs used in the top paid VPNs are completely benign. They typically provide common functionality, such as managing the log-in process for example or facilitating responsible advertising.

Developers embed this type of off-the-shelf code in their apps to avoid having to write code unnecessarily, or to integrate with third party services.

However, I also found 3 VPNs using ad-tech SDKs that fell outside the bounds of what we consider to be responsible.

App Name	Risky SDKs	Package
Hotspot Shield VPN	6	hotspotshield.android.vpn
X-VPN	2	com.security.xvpn.z35kb
VPN Unlimited	1	com.simplexsolutionsinc.vpn_unlimited

Hotspot Shield’s VPN app contained 6 SDKs, more than any other app I tested. The most problematic SDKs from a privacy perspective were those published by companies under a cloud with U.S. regulators.

One of them, data broker Kochava, is accused of violating regulations by selling granular, non-anonymized location data.

Another was mobile ad network Tapjoy, which has previously been ordered to stop misleading consumers about in-game rewards under the terms of its settlement with the FTC.

SDKs from both firms are featured in the Hotspot Shield Android app, along with libraries from Digital Turbine, IronSource and Unity Ads.

Hotspot Shield developer Pango explained that the SDKs were present as a result of operating a single Android app for both free and paid users.

“These SDKs support our Freemium app model. Prior to sharing any data with these third-party SDKs, we secure user consent via GDPR-compliant methods.

“Technically, isolating these SDKs separately for the Free and Premium versions is currently not feasible. Rest assured, however, that user privacy remains a core priority, and data sharing only occurs with the user’s informed permission.”

Pango told me that IronSource was fully disabled for Premium users or where GDPR consent was not given.

However, as shown in the next section, my tests revealed that this was not working as expected. As a result, Pango are now working on a fix which they will deploy with the next app update.

This illustrates a key problem with this kind of ad-tech. Modern apps are complex software. Even when developers act in good faith, as is the case here, a bug can undermine any intended privacy protections.

The other notable SDKs of concern that I found were:

• Vungle (X-VPN)
• Chartboost (X-VPN)
• IronSource (VPN Unlimited)

Each of these software libraries facilitates data collection for targeted ads across browsing sessions and devices.

Observable Third-party Data Sharing

The presence alone of ad-tech and tracking code in a privacy-focused app like a VPN is contentious. Especially so when it’s a paid service.

However, I also wanted to see what personal data was actually being collected and shared in practice, both by third parties and the VPN providers themselves.

To do this, I used the open-source mitmproxy tool to intercept and inspect VPN apps’ HTTPS traffic.

As a result, I was able to analyze the contents of all traffic between the VPN apps and the providers’ own servers, as well as the communication between the VPN software and any external services and advertisers.

Once again, I excluded any data sharing that was secure and facilitated core functionality, such as IP geolocation data lookups for in-app display, or responsible advertising activity.

I encountered certificate pinning much more frequently with paid Android VPNs (33% of apps) than with free VPNs (5%).

This security measure is good for users but it also prevented me from capturing and inspecting the HTTPS traffic of absolutely every VPN app in this study.

Fortunately, I was still able to test those VPN apps whose tracking code I was most interested in.

Another important caveat: VPN sessions conducted under test conditions are not always fully comprehensive.

Certain data sharing processes may not be triggered, for example. Perhaps they require you to connect from a specific physical location or that the VPN is installed on a high-end device.

This could explain why not all tracking code identified in previous sections appears to be active.

Another explanation might be that the code may actually be dormant for the time being, for business or other reasons.

However, this doesn’t mean that that these tracking functions can’t be reactivated at any time.

The following table shows the proportion of paid VPNs engaged in data collection and sharing of various types. The relevant free VPN findings are also included for easy comparison.

Data Sharing	Paid VPNs	Free VPNs
Third-party data collection	7%	71%
Device fingerprinting	3%	37%
IP address	7%	23%
Google Ad ID	3%	61%
VPN provider data collection	7%	30%

The difference between paid and free VPNs in this area is crystal clear.

In my tests, data collection and sharing by paid VPNs paled in comparison with free VPNs, whether with third parties or by the VPN providers themselves.

Third-Party Data Collection

I observed third-party data collection with privacy implications in 2 of the 3 VPNs that contained risky SDKs:

• VPN Unlimited
• Hotspot Shield

The third, X-VPN, is a “freemium” service that shares its free users’ personal data with several third parties. As soon as you upgrade to a paid subscription this sharing immediately ceases.

While keeping your personal data private is always welcome, the ease with which this app behavior is turned off after an account upgrade leaves some lingering doubts.

What happens if something goes wrong with your account renewal without you realizing? Does your X-VPN app immediately revert to the free version with all the significant data sharing that entails?

As an X-VPN user, I might also be wary about the developers quietly adopting a more aggressive commercial strategy, following an acquisition for example, and reactivating those ad-tech SDKs for all users.

It’s not a privacy risk that users of most other paid services even have to think about.

For all three apps, the third parties were the same as those identified in that section.

This type of data collection took place markedly less with paid VPNs than with free VPNs, where it occurred in 71% of apps I tested.

The specific data each VPN app shared is explored below.

Device Fingerprinting

Device fingerprinting is the practice of collecting enough individual data points about a device to track it without the need for advertising IDs.

Each data point, such as screen size or free disk space, is harmless on its own but in aggregate can uniquely identify a device.

I observed 2 paid VPNs share what were effectively device fingerprints with third parties, although one (X-VPN) only did this for its free users.

Hotspot Shield shared this type of data with Kochava, Unity Ads and Tapjoy.

In the screenshot above you can see how a long list of data points about my test device is being sent to Unity Ads. This includes:

• Device manufacturer
• Device model
• OS version
• Language
• Connection type
• Call type
• Screen size
• Screen width/height
• USB connection
• Free disk space
• API level
• CPU count
• ISP
• Wired headset use
• Use of debugging tools
• Rooted status
• Timezone
• Device volume
• Battery level

Unity Ads and IronSource have been merged since 2022 and as you can see highlighted, Unity is using IronSource here as the mediation layer.

What this means is that IronSource is acting as a controller that manages ad requests, using the device fingerprint to help decide which ad network should serve you ads.

This is not to suggest any kind of breach of privacy regulations. In fact, using a mediation layer like this helps with GDPR compliance.

However, the sharing of this kind of detailed data is not what most privacy-conscious VPN users would be comfortable with.

It also shouldn’t be happening at all for paid users. This behavior should hopefully be disabled, for paid users at least, when the app is next updated with a fix for this bug.

X-VPN shared similar lists of data points with Vungle, Chartboost and Facebook for free users only.

Mobile device fingerprinting compromises user privacy as it can be used to track you across the web even when you make the effort to reset your advertising ID.

IP Address

I also observed the same 2 paid VPNs share my IP address with third parties.

Before I upgraded my subscription, X-VPN shared my IP address with Facebook as part of the device fingerprint.

Hotspot Shield shared my IP address with Tapjoy in similar fashion even when logged into a paid account.

While it’s nothing that couldn’t be easily inferred from my IP address, Hotspot Shield also explicitly included my geolocation data in the same server request to Tapjoy.

HMA! also collected my IP address as part of its own marketing segmentation data but did not share it with any third parties.

IP anonymity is so core to why people use VPNs that I decided to include this example even though it relates to attracting new customers.

By contrast, almost a quarter of free VPNs collected or shared IP addresses.

Google Advertiser ID

Your Google Advertiser ID (GAID) is a unique identifier that can be used to track you across the web and serve you personalized ads. While it can be manually reset, this is not something that the average user would typically think to do.

Hotspot Shield was the only paid VPN to share my GAID in a potentially risky manner, in server requests to Kochava, Unity Ads and Tapjoy.

This contrasts with 61% of free VPNs collecting and sharing my GAID.

VPN provider data collection

I observed 2 VPN apps send data to their own servers beyond what was necessary to provide core functionality.

The VPN Unlimited app phoned home with very basic device telemetry, as shown below.

While this behavior was only a minor privacy intrusion, I did not observe it in other paid VPN apps.

HMA! was the other VPN to conduct first-party data collection, outlined above the IP address section.

By contrast, as many as 30% of free VPNs collected user data in this way.

The VPNs included in this study were the 30 highest-ranking VPN apps in the Google Play store where a paid service was the primary offering.

All VPN apps were installed on entry-level Samsung smartphones running stock Android. Test devices were stripped back of all but mandatory core apps that could not be neither uninstalled nor disabled.

Tests were conducted using a combination of Wireshark and mitmproxy, along with other open-source tools.

Network traffic captures were conducted in a custom testing environment on a dedicated LAN to minimize data contamination.

For each VPN, I performed a series of testing steps that included connecting to a VPN server and visiting specific domains and running our publicly-available Top10VPN VPN leak tests.

I copied the APK file for each VPN app to my main testing machine to conduct code reviews in order to ensure app version consistency between all tests.

You can download the full list of VPN apps I tested, which also contains detailed individual test results for each VPN.