Free Android VPN Security Flaws: 100 Apps Tested

The following are my key findings from the VPN tests relating to encryption, DNS and other leaks, and VPN tunnel reliability.

You can also download the Google Sheet containing the full findings.

For these tests, I used Wireshark in my own custom testing environment (thanks to JP Jones for his help setting this up) to capture and analyze network traffic from my Android test device as I connected to each VPN and visited our test domains.

I also used our own IP geolocation and VPN leak tools to supplement my analysis.

Before we dive into the deeper analysis, this short video I made gives a quick overview of this part of the research that should make the rest of this section easier to digest.

VPN Encryption Failures

I’ve listed the 11 VPN apps that suffered encryption failures in the table below.

Tap the Expand Table button for a full-screen view and scroll to see the full details.

I detected failures that ranged from a complete failure to encrypt internet traffic to the exposure in clear text of DNS requests.

Whatever the type of encryption failure, my test results suggest that these 11 VPNs each pose a very high potential risk to user privacy.

No encryption: VPN Satoshi was the only app to completely expose my browsing activity during my tests.

In the screenshot below taken from Wireshark you can see that not only is the name exposed of the test domain I visited but also the specific URL and the HTML contents of the page itself.

Screenshot of the contents of a HTTP packet captured from a session using VPN Satoshi while it was connected, showing unencrypted details of a web page I visited.

Browser DNS requests: The other 10 VPNs in the table leaked DNS requests relating to websites I visited during my tests.

As you can see in the Wireshark screenshot I’ve shared below, anyone monitoring my activity while I was using any of these VPNs, such as an ISP or network administrator, would be able to determine which domains I visited and when.

Screenshot of DNS requests from browsing activity leaking from the VPN tunnel created by VPN Private Android app.

AVG and Tenta, two private browsers with integrated VPNs, only exposed a subset of DNS requests related to tests performed by our leaks tool.

Despite running the leak tests via the apps’ “secure” browsers, as opposed to Chrome, DNS requests to iptools-6.top10vpn.com and dnstest6.top10vpn.com and were exposed. I didn’t find any other exposed DNS requests in my tests of these two apps.

Both apps employ the secure DNS over TLS (DoT) protocol and it’s possible this may be failing for IPv6, causing it to fallback to normal DNS, which is sent over a plaintext connection.

This is much less dangerous than the more wide-ranging encryption failures experienced by the other VPN apps in the table.

However given that this edge case has not been addressed, there’s a question mark about what other activity might be exposed in the course of normal usage.

For more findings around DNS and other leaks, jump straight to that section.

Weaker Encryption & Handshakes

The two most concerning VPNs in terms of encryption were HTTP Injector and Phone Guardian.

HTTP Injector functioned unreliably, sometimes changing my IP address and sometimes not.

In the screenshot I’ve shared below, you can see how the HTTP Injector app also repeatedly attempted to initiate the VPN tunnel using the outdated and insecure TLSv1 before switching to TLSv1.3.

TLSv1 dates back to 1999 and was formally deprecated in 2021.

Note that the SNI can be obfuscated in the app UI, with facebook.com as the default app setting.

Screenshot of the attempted use of TLSv1 by HTTP Injector VPN Android app.

Phone Guardian advertises itself as a VPN but it doesn’t really behave like one.

It neither hid nor changed my IP address, nor did it encrypt the majority of my internet traffic.

Instead, Phone Guardian only encrypts HTTP sites when you connect to untrusted WiFi networks.

Unfortunately, this means the details of any HTTPS websites you visit remain exposed via DNS lookups and SNI in HTTPS handshakes.

While Phone Guardian works as intended, it’s very easy to be misled into believing you are being protected in the same way as a normal VPN.

More broadly, I found that at least 35 VPNs encrypted traffic using algorithms that, while neither insecure nor “broken”, could be considered sub-optimal as they were 128-bit rather than the stronger 256-bit encryption.

I found something similar with the implementation of PRF (Pseudo-Random Function) in the cipher suite of 11 VPNs. These VPNs used AES-128-CBC for PRF rather than the stronger HMAC-SHA2-256.

I also identified 16 VPNs that always used TLSv1.2 as the handshake protocol, plus another 2 VPNs that used it some of the time.

While use of TLSv1.2 remains acceptable, especially if it is manually configured to remove support for vulnerable cipher suites, this version of the protocol is nearing the end of its life and has been superseded by the faster and more secure TLSv1.3.

Given how free VPNs are often used to hide sensitive internet activity in high-censorship regions, it’s disappointing to see so many that fail to adopt the most secure forms of encryption.

Most problematic however were the four VPNs that I found using SSLv2 as the handshake protocol to establish a VPN tunnel.

This obsolete protocol is almost 30 years old and was quickly superseded by SSLv3 and since then by the various versions of TLS.

The four VPNs using this vulnerable protocol were:

• Thunder VPN com.fast.free.unblock.thunder.vpn
• Tomato VPN com.ironmeta.security.turbo.proxy.vpntomato.pro
• Urban VPN com.urbanvpn.android
• VPN Ukraine vpn.ukraine_tap2free

I identified two other VPN apps using SSLv2, albeit in a different and unusual manner.

After establishing a VPN tunnel using TLS, I observed the following apps make additional connections to VPN servers on different IPs to the tunnel endpoint using the obsolete protocol.

• “VPN – fast secure vpn proxy” com.optimizer.booster.fast.speedy.phone.smooth
• VPN Monster free.vpn.unblock.proxy.vpnmonster

I observed the apps sending and receiving hundreds of packets over these insecure connections.

Leaky VPNs

As well identifying leaks via Wireshark, I also used our own VPN leak tool to test for IP, DNS and WebRTC leaks.

Download the data sheet to see the full details of how each VPN app was affected.

Using our tool, I found that 15 VPNs leaked my IPv6 address, an example of which you can see in the screenshot below.

This includes 3 VPNs that leaked both the IPv4 and IPv6 addresses of my connection.

The three VPNs that leaked my IPv4 and IPv6 addresses were:

• Tomato VPN com.ironmeta.security.turbo.proxy.vpntomato.pro
• Phone Guardian VPN com.distimo.phoneguardian
• Ultimate VPN com.open.hotspot.vpn.free

Screenshot of Top10VPN leak tool showing IPv6 leak in VPN Pro.

IPv6 leaks are just as dangerous as IPv4 leaks. Websites and applications will have access to your real location, and your ISP will know your internet history.

The five most popular VPNs that leaked my IPv6 address were:

• Turbo VPN free.vpn.unblock.proxy.turbovpn

(335 million installs)

• WiFi Map io.wifimap.wifimap

(116 million)

• VPN – Super Unlimited Proxy com.free.vpn.super.hotspot.open

(93 million)

• VPN Proxy Master free.vpn.unblock.proxy.vpn.master.pro

(84 million)

• Turbo VPN Lite free.vpn.unblock.proxy.turbovpn.lite

(68 million)

I found that 83 VPNs leaked DNS requests from my test devices.

By that I mean any DNS requests made while using any of these 83 VPN apps are serviced by a third-party rather than by the VPN provider.

As a result, that third-party, whether it’s Google, Cloudflare or some random ISP, knows every site you visit, massively compromising your privacy in the process.

Almost half (40) of leaking VPNs used Google for to handle DNS request and 14 used Cloudflare.

While the majority of these DNS-leaking VPNs (72 apps) did not send DNS requests related to browsing activity outside of the VPN tunnel, many did fail to route DNS requests to their own servers and failed to send HTTP communication to ad trackers or analytics services through the tunnel.

The screenshot below shows examples of that type of DNS leak.

Note that 10.5.0.1 is the address of my default DNS server. If you use this method to check whether your VPN is leaking then expect to see the IP address of your ISP’s DNS servers or of your router.

Screenshot of DNS leaks captured from HotBot VPN session.

Some of the most downloaded VPNs that suffered DNS leaks were:

• Turbo VPN: 335 million installs
• SuperVPN: 250 million installs
• Secure VPN: 166 million installs
• Psiphon Pro: 141 million installs
• Kaspersky VPN: 117 million installs

I also captured packets from 79 VPNs that had domain names visible in their SNI (Server Name Indication) fields.

This exposed SNI information, which included domains for the VPN services I was using, their third-party trackers, and the websites I had visited, was evidence of traffic that should have gone through the VPN tunnel and not been visible in this way.

The leaking of these packets from the tunnel undermined my privacy while using these VPNs, exposing my activity to anyone monitoring my connection.

There were 5 VPNs where I observed this kind of leak but did not detect any other DNS, IP or WebRTC leak.

• Avira Phantom VPN: Fast VPN com.avira.vpn
• Bitdefender VPN: Fast & Secure com.bitdefender.vpn
• F-Secure FREEDOME VPN com.fsecure.freedome.vpn.security.privacy.android
• hide.me VPN: The Privacy Guard hideme.android.vpn
• Unblock Websites — VPN Proxy com.master.unblockweb

VPN Tunnel Instability

I detected abnormally high numbers of TCP Reset (RST) packets in test sessions with 25 VPNs, averaging nearly 17 resets per session despite my test sessions typically only lasting for just over a minute.

While RST packets close sockets in normal TCP/IP communications, the high volume suggests network anomalies like congestion, unreliable connections, or misconfigurations, indicating potential instability and vulnerabilities.

Furthermore, I also found signs of tunnel instability through out-of-order TCP packets, TCP Window Full packets, and wrong sequence number ESP packets in 53 VPNs.

HTTP Data Exposure

I discovered that several VPNs exposed sensitive information about me in responses to HTTP requests that were not encrypted.

Four VPNs received personally identifiable information (PII), including my real IP address, in unencrypted HTTP/JSON responses from ip-api.com which they used to show me my geolocation data.

Here’s a screenshot of one of these unencrypted responses.

Screenshot unencrypted of HTTP/JSON response received by WiFi Map VPN containing PII, including my real IP address.

This practice is insecure and poses a privacy risk.

Given that only the free version of the ip-api service, which is not intended for commercial use, is not encrypted, it’s likely that the VPNs in question are exposing their users’ data for the sake of $14 a month.

The only alternative is that these VPNs have failed to use to the correct endpoint. We will never know whether this is a deliberate choice or simply incompetence.

The affected VPNs were:

• Turbo VPN Lite free.vpn.unblock.proxy.turbovpn.lite
• Speedy Quark VPN com.speedy.vpn
• VPN Proxy Master com.freevpn.unblock.proxy
• WiFi Map io.wifimap.wifimap

Another app, VPN Proxy Speed com.supervpn.vpn.free.proxy sent rather than received similar information to the following URL rufjskls.shop/report.php on the 104.21.12.129 IP address.

The content on rufjskls.shop as per this screenshot indicates that it’s operated by VPN provider.

Screenshot of content on domain that received requests from VPN Proxy Speed containing PII .

Four more VPNs (WiFi Map VPN, Turbo VPN Lite, TLS Tunnel, and “VPN – fast secure vpn proxy”) sent telemetry about my test device, such as make, model and OS, unencrypted over HTTP in User-Agent strings.

While the privacy risk is relatively low, unencrypted data transmission indicates lax security practices that could manifest more seriously elsewhere. This data could also compromise privacy if combined with other personal information.

Individual VPN Traffic Anomalies

I also found notable anomalies in individual VPNs’ traffic that raised privacy and security concerns.

Thunder VPN, which has over 91 million installs worldwide and was highlighted earlier in this report for using the obsolete SSLv2 protocol, had and issue around unusual numbers of what initially appeared to be DNS records.

I detected multiple packets containing an abnormally high number of questions, answer resource records (RRs), authority RRs, and additional RRs. The packets do not appear to be valid DNS queries, so port 53 is potentially being used for as a side data channel to the VPN Server.

Elsewhere, I discovered that Pawxy VPN (1.1 million installs) exchanged bt-dht (distributed bittorrent discovery protocol) packets with 178.71.31.82, a Russian IP address operated by Rostelecom, despite the app being connected to a French VPN server at the time.

This was a major red flag as I had no bittorrent client installed on my test device nor was any such functionality advertised on the Pawxy app.

In the box below are the detailed key findings from the privacy-focused analysis I did on the Android source code of each of the 100 VPN apps in this study.

I’ve made a distinction between proprietary code written by the VPN developers themselves and code from third-party software libraries with user tracking functionality, such as those published by social media and adtech firms.

You can also download the Google Sheet containing the full findings.

Identifying Risky Android VPN Code

While permissions alone raise privacy concerns, user privacy is only practically at risk if corresponding functions are present in the app’s source code.

To identify this risky functionality, I reviewed each VPN’s source code and documented instances of Android classes and methods that could access personal data or enable user tracking. I mainly focused on code related to:

• Location tracking
• Retrieving the Google Advertising ID
• Collecting device telemetry data

I prioritized high-risk code where the corresponding Android permission was also present in the app manifest. However, I also documented all other instances of privacy-risking code, even when the app did not request the necessary permissions to execute it.

The risks of tracking code without permissions

Omitting certain permissions can suppress unwanted third-party library functionality but there are still privacy risks when the code is present:

• Developers could add permissions in future updates to activate dormant tracking capabilities.
• Apps frequently change ownership, with no privacy guarantee from new owners.
• Any tracking code poses a risk if developers decide to maximize data sharing with advertisers amid economic pressures.

A better privacy approach is for VPN developers to use libraries without privacy-risking code or write more proprietary code themselves.

From this comprehensive perspective, 96 of the 100 tested VPNs contained code that could potentially impact privacy, regardless of current permissions.

BeePass, Urban VPN, Leaf VPN and Hide My IP were the only apps with no detected privacy-risking code at all.

Proprietary vs third-party ad tracking code

My analysis differentiated between proprietary (developer-written) and third-party code:

• Proprietary risky code implies intentional privacy undermining by developers.
• Third-party risky code is more ambiguous, as ad/marketing SDKs are commonly used to monetize free apps, but at a privacy cost.

While modern development relies heavily on third-party libraries, the focus was on advertising/marketing SDKs whose sole purpose is user data collection and tracking for targeted ads.

Third-party adtech is how most VPN providers are able offer a free product and still make money — but it comes at a very high cost to our privacy.

How Many Free VPNs Contained Tracking Code?

Proprietary code: Over half (53) of the VPNs I analyzed contained at least one proprietary function that posed a privacy risk and requested the necessary permission.

Third-party code: Over three quarters of VPNs (80) of the VPNs contained at least one third-party function and corresponding permission that risked user privacy.

While the presence of third-party tracking code suggests data collection and sharing, it is not definitive proof on its own.

Jump ahead to the section where I intercepted and analyzed network traffic for evidence of this in practice.

Free VPNs with the Most Risky Code Functions

Proprietary code: I found Kaspersky VPN & Antivirus com.kms.free had the most proprietary code functions (5) that could put user privacy at risk, where the corresponding permissions were also requested:

• getResources().getConfiguration() – the Kaspersky VPN app used this method call to retrieve the mobile country and network codes (MCC & MNC) of our test device.
• getAdvertisingIdInfo
• getInstalledPackages
• getDeviceId()
• ContactsContract.Contacts.lookupContact

For definitions of the functions identified in this section, you can refer to the report’s supporting documentation.

No other VPN in this study had as many different functions in its first-party source code that could put your privacy at risk.

I identified another 3 VPNs that featured 3 different risky functions in their first-party code, where the corresponding permissions were also requested:

• VPN – Fast Secure Proxy com.starnest.vpnandroid
• YA VPN com.odelance.ya
• VPN Vault com.starnest.vpnandroid

Third-party code: I found 7 VPNs whose third-party code contained 5 or more different code functions that put user privacy at risk, where the corresponding permission was also requested.

I typically identified multiple instances of these risky functions in each VPN app, across various SDKs.

TLS Tunnel com.tlsvpn.tlstunnel had the highest number of different risky functions (9).

I found the AdvertisingIdClient.getAdvertisingIdInfo method call in 10 third-party tracker SDKs used by TLS Tunnel, including AdColony, Amazon, Bytedance, Google Ads, myTarget and Bid Machine.

Other high-risk functions I found in my analysis of TLS Tunnel included:

• getNetworkOperatorName()
• getInstalledPackages
• getSimOperator()
• getSimOperatorName()
• getNetworkCountryIso()
• getMccmnc()

Other VPNs where I found excessive third-party tracking code included:

• VPN Vault com.appsverse.avvpn (7 risky functions)
• Star VPN org.sanctuary.superconnect (7 risky functions)
• AVG Secure Browser com.avg.android.secure.browser (7 risky functions)
• Kaspersky com.kms.free (6 risky functions)
• Symlex VPN app.kismyo.vpn (6 risky functions)
• JumpJumpVPN app.jumpjumpvpn.jumpjumpvpn (5 risky functions)
• YA VPN com.odelance.ya (5 risky functions)

Location Tracking Code

Proprietary Code: I found 13 VPNs which had first-party location tracking code along with the corresponding permissions.

There are several different location tracking permissions in Android so to make it easier to see what each of these apps is doing, I’ve broken out what permissions they request in this table.

Click on the Expand Table button for a fullscreen view and scroll to see all apps’ data.

While the presence of first-party location-tracking code in many VPN apps may often be benign in intent, it still risks compromising user privacy.

Windscribe, for example, told me that their app requires location permission and code to retrieve WiFi network names (SSID), as part of a feature that disables the VPN automatically on trusted networks.

This feature, also found in some other popular VPNs, is certainly convenient but can actually be abused as part of the SSID Confusion attack that targets a new WiFi vulnerability that we have recently made public.

The developers told me that Windscribe also uses ACCESS_MOCK_LOCATION for the app’s GPS spoofing feature.

In Psiphon the getLatitude and getLongitude methods appear to be used primarily for connecting users to the nearest, fastest VPN server.

Similarly, in Adguard VPN, these methods retrieve geolocation data for dynamic server selection based on the user’s location and language preferences. Since we tested this VPN, newer versions have removed this functionality.

However, regardless of the minor user experience gains, collecting this data inherently undermines privacy.

This is especially true if the geolocation data is logged, as appears to be the case with Touch VPN.

The following code snippet shows how the app stores latitude and longitude data in a JSON-friendly format.

Screenshot of Touch VPN source code showing storage of geolocation data.

I also found that Touch VPN stores the ASN, country, city and postal code geolocation data points.

Third-party code: I found 16 VPNs which had location tracking code within an external SDK along with the corresponding permissions. I’ve listed them in the table below.

Click on the Expand Table button for a fullscreen view and scroll to see all apps’ data.

While VPNs like Psiphon Pro and Power VPN that only use third-party code to collect approximate (city-level) location pose a relatively low risk from a privacy perspective, it’s still not ideal.

On the other hand, I identified 12 VPNs that contained third-party tracking code designed to collect precise location data, along with the necessary permissions to run it.

Worse, 3 popular VPNs – Kaspersky, VPN Proxy Master, and Betternet – with over a quarter of a billion installs combined, featured third-party code and permissions to track location even when running in the background.

Kaspersky collects location data via Facebook and Huawei SDKs, neither known for privacy.

VPN Proxy Master is even more concerning, containing permissions and location tracking code from Bytedance, Yandex, Google Ads, and ad tech firms from India and Singapore.

Betternet collects location via Amazon Ads, Google Ads, and AdColony SDKs, concerningly using the Protocol Buffers library typically used for large datasets.

Another 61 VPNs contained third-party location tracking code but do not currently request the necessary permissions to run it.

Advertising ID Tracking

Proprietary code: I found 31 VPNs using the getAdvertisingIdInfo method from the AdvertisingIdClient class to retrieve my unique Google Advertising ID, with the corresponding permission in place.

While it’s possible to reset this identifier by digging deep into a device’s privacy settings, most users are unlikely to do so regularly.

A VPN collecting your Google Advertising ID is a major privacy concern, as this unique identifier allows companies to track your online activity and behavior across apps and websites for targeted advertising purposes.

By obtaining this identifier, VPN providers can potentially build extensive profiles about your interests and internet usage, undermining the very privacy they are supposed to protect.

One app, Private VPN com.privates.secure.fast.browser, contained this function in its own first-party code but did not request permission to execute it.

Third-party code: Almost three quarters of VPNs (71) had the code and permissions to retrieve your Google Advertising ID and – by extension – share it with external advertising or marketing platforms.

When an ad tracker SDK collects this identifying data instead of the VPN provider itself, there are added privacy risks.

Third-party SDKs typically share data widely, increasing potential for breaches or misuse, with little transparency on how data sharing and profiling occurs.

I found two VPNs, Symlex VPN app.kismyo.vpn and Private VPN com.privates.secure.fast.browser, that featured the getAdvertisingIdInfo function but did not request the necessary permissions to run the code.

App Scanning

Proprietary code: I found 22 apps with the getInstalledPackages code, which scans for installed apps, and its corresponding QUERY_ALL_PACKAGES permission.

This is typically used to make configuring split tunneling more convenient, as otherwise apps routed via the normal network would have to be manually defined rather than toggled on or off from a list.

Nevertheless the privacy risks around scanning for installed apps are plain.

The presence of any sensitive apps related to sexuality, dating, mental health, or addiction, for example, would be confirmed and potentially logged by the VPN developer.

Some of the most popular VPNs with this functionality included:

• SuperVPN com.jrzheng.supervpnfree
• Psiphon Pro com.psiphon3.subscription
• X-VPN com.security.xvpn.z35kb

I identified another 8 VPNs with similar first-party code that did not request the necessary permissions, raising questions about its presence, including popular apps like Turbo VPN (335 million installs).

Third-party code: I found 9 VPNs with the necessary permission and third-party code to scan for installed apps.

The risks increase significantly when this data is collected via a third-party SDK like myTarget, a Russian adtech platform owned by Mail.ru.^[1]

Under Russian laws, the government and intelligence agencies may have the authority to access user data held by Russian companies like Mail.ru Group, potentially compromising user privacy in ways that threaten life and liberty.

The following 7 VPNs contain myTarget code and the required QUERY_ALL_PACKAGES permission for app scanning:

• Planet VPN com.freevpnplanet
• Free VPN Super con.hotspot.vpn.free.master
• Lantern VPN org.getlantern.lantern
• TLS Tunnel com.tlsvpn.tlstunnel
• VPN – fast proxy + secure free.vpn.proxy.secure
• Wolf VPN com.wolf.vpn
• VPN – fast secure vpn proxy com.optimizer.booster.fast.speedy.phone.smooth

Other SDKs featuring this code included the Israeli advertising platforms Ironsource (2 VPNs) and StartApp (1 VPN).

Windscribe has similar third-party code and the permission to run it within the open-source StrongSwan SDK, a library used for creating VPN connections with the IPSec protocol.

While this is clearly an appropriate SDK for a VPN use, avoiding the collection of installed app data would be preferable.

I found a further 11 VPNs that contained third-party app scanning code but did not request the necessary permission to run it.

Sensitive Data Access

Proprietary code: I found 4 VPNs with first-party code that collects various sensitive device identifiers, where the corresponding READ_PHONE_STATE permission was also requested.

I’ve listed them in a table to make it easier to see what individual data points each VPN is coded to collect.

There was one other app, iTop VPN, where I found similar proprietary code but without the corresponding permission.

Third-party code: I also found 8 VPNs with the necessary READ_PHONE_STATE permission and third-party code that collects detailed device identifiers.

As you can see in the table below, all the VPNs that collect this data via first-party code (listed in the previous table above) also collect it via third-party SDKs.

Click on the Expand Table button for a fullscreen view and scroll to see all apps’ data.

As you can see in the table, I identified 3 VPNs with the necessary permission and third-party code to collect Device IDs and IMEI numbers.

This is a clear privacy risk, as these unique identifiers make it trivial to track you across the internet.

While the other data points in the table may seem innocuous alone, they’re considered sensitive enough to be protected by the “dangerous” READ_PHONE_STATE permission.

The more of these data points an app collects, the greater the privacy risk.

I identified a further 78 apps containing third-party code intended for sensitive data collection protected by the READ_PHONE_STATE permission, but did not request the permission itself.

Bytedance & Yandex

Chinese TikTok developer Bytedance is likely to be forced to divest its U.S. assets due to national security concerns.

Russian search giant Yandex, now based in the Netherlands, has historically had ties to the Russian government.

These ties are likely to become closer following the announced sale of its Russian assets to a consortium of Russian investors in February 2024.^[2]

A major data leak at the company in August 2023 also raises cybsersecurity concerns.^[3]

Given that VPNs are tightly restricted in both China and Russia, it’s a major red flag for any free VPN to contain source code from companies within those jurisdictions, especially should their independence be in doubt.

In the table below I’ve listed the 20 VPNs that featured privacy-risking code from one or both of those companies, where the corresponding permission was also requested.

Click on the Expand Table button for a fullscreen view and scroll to see all apps’ data.

The worst offender for utilizing Bytedance code to collect personal data was TLS Tunnel. The app contained multiple instances of four code functions that collected protected device data, along with the necessary permissions.

These functions included:

• getNetworkOperator()
• getSimOperator()
• getAdvertisingIdInfo

Another 5 VPNs contained 2 instances of similar Bytedance code and 9 VPNs had a single instance.

Four VPNs collected location data via the Bytedance SDK:

• VPN Proxy Master free.vpn.unblock.proxy.vpn.master.pro
• Free VPN by Free VPN .org org.freevpn
• WiFi Map io.wifimap.wifimap
• VPN: Private and Secure VPN openvpn.vpn

VPN Proxy Master also collected location data via the Yandex SDK, the only VPN to do so via that library.

I found a single VPN (VPN Proxy Master) with more than one instance of Yandex code that collected personal data where the corresponding permission was present, whereas the remaining 10 VPNs had a single instance.

Next are the key findings from my audit of the Android Manifest files of the 100 VPN apps in this study, where I looked for all self-declared use of device hardware that’s not usually appropriate for a VPN app.

You can also download the Google Sheet containing the full findings.

I broke down the individual hardware declarations of each of the 32 VPNs that made them in this table.

Click on the Expand Table button for a fullscreen view and scroll to see all apps’ data.

While it’s something any privacy-conscious user would prefer to avoid, it’s no mystery why a VPN app would declare use of GPS, as location tracking is a common, if unwanted, feature of modern mobile marketing.

Another more benign reason that is some VPN apps try to connect you to the fastest server, which is normally the one geographically closest to you.

It’s much less clear why I found so many <uses-feature> declarations for the use of my device’s camera, microphone and various sensors.

There is no valid reason for a typical VPN to use these hardware features.

It’s possible that the <uses-feature> declarations may have arisen from the use of third-party libraries that rely on specific hardware features.

However, another possibility is that they are as a result of obfuscated or undocumented functionality.

Whatever the reason, it’s not something that should be shrugged off with and certainly puts me off from using these VPNs myself.

Let’s turn to the key findings from the network traffic analysis I carried out on the 100 VPNs in this study.

I focused on two types of personal data collection:

1. First-party, i.e. data collected by the VPN providers themselves
2. Third-party, i.e. data shared directly with advertisers and marketers.

For VPN-by-VPN findings, download this Google Sheet with full details.

Network Traffic Analysis Demonstration Video

In this short video, I give a walkthrough of how I performed my network traffic analysis and an overview of what I found.

As you can see in the video, I used mitmproxy to intercept HTTP/HTTPS traffic from each VPN after it was installed on a clean test device.

I reviewed requests to the VPN providers’ own servers and to those of third parties, along with the responses received, documenting any that contained personal data like IP addresses or Google Ad IDs.

A few VPNs had implemented certificate pinning for additional security, and thus couldn’t be fully tested.

As with my source code analysis, I treated first- and third-party data sharing separately.

How Many Free VPNs Collected & Shared Data?

Third-party: I observed that almost three quarters of VPNs (71) sent some sort of personal data to third-party advertisers or data brokers while connected.

I identified 33 entities receiving personal data, ranging from tech giants to the less well-known, such as data brokers like Kochava, and analytics platforms, such as AppsFlyer.

These entities use this data to track us across the web and target the ads they show us based on what we do online.

Chart showing the distribution of free Android VPN apps based on how many third-party entities they share personal user data with.

The chart shows how 59 VPNs shared personal data with 1-3 third-party trackers, while 12 VPNs shared with 4 or more trackers.

First-party: I found that at least 29 VPNs collected some sort of personal user data and sent it to their own servers. Some VPN apps could not be analyzed and so that number could be higher still.

I put together a table to show the VPNs where I detected this practice.

Click on the Expand Table button for a fullscreen view and scroll to see all apps’ data.

IP Address Tracking

I excluded VPNs that sent my IP address to a third-party API or to their own servers to look up my geolocation data to show me in-app, as the privacy impact is negligible.

Third-party: However, I found 23 VPNs sent my real IP address to third-party trackers, most frequently Google.

Exceptions included ClearVPN (which sent my IP address to customer messaging service OneSignal), Super VPN (shared it with mobile ad platforms IronSource and Unity Ads), and NotVPN (IronSource).

This screenshot shows how Mouse VPN sent my real IP address to Google’s googlevideo.com domain as part of a video ad request.

Screenshot of network traffic capture from Mouse VPN as it sends my real IP address to Google.

Other VPNs sent my IP address to DoubleClick, Google’s ad platform that uses personal data for targeted ads.

It is particularly egregious for a VPN to share your IP address as it undermines the fundamental purpose of using a VPN, which is to hide this information.

First-party: One app, Star VPN, as shown in the screenshot below, sent not only my real IP but also the IP address of my VPN connection to its own servers.

This did not appear to be done in order to show me my geolocation data.

Screenshot of network traffic capture showing IP Address collection by Star VPN.

The screenshot also shows Star VPN sending various details about my device, such as my ISP, AS number, country, model, language, and a unique identifier to its report.camel-vpn.net domain.

This is a major privacy red flag, and I’d strongly recommend against using any VPN that collects such data.

Advertising ID Tracking

Third-party: I found 61 VPNs that sent my test device’s unique advertiser ID to third-party trackers.

In this screenshot from Turbo VPN, the app is sending my Google Ad ID, i.e. the string starting 1a07af37 (redacted), via a POST request to ads.inmobi.com.

Screenshot of network traffic capture from Turbo VPN showing my unique advertising ID being sent to the third-party InMobi ad tracker.

First-party: I found 5 VPNs that included my Google Ad ID in requests to their own servers:

• Speedify – 12.5 million installs
• Unblock Websites — VPN Proxy – 6 million installs
• VPN Vault – 3 million installs
• HotBot VPN – 1.5 million installs
• Zoog VPN – 0.6 million installs

The Zoog VPN developers told me that they use the Google Ad ID as a unique ID to prevent users from abusing their service and creating multiple accounts without requiring email-based account registration.

Whatever the intent, using Google Ad IDs in this way introduces a risk to privacy. It allows tracking and creating profiles that link your activity across different services.

This contradicts the main purpose of using a VPN, which is to enhance privacy and anonymity.

Device Fingerprinting

Third-party: I found that over a third of VPNs (37) sent a detailed fingerprint of my test device to third-party trackers.

Unity Ads was the most common recipient from 12 VPNs, followed by data brokers AdColony (7 VPNs) and Vungle (6), Facebook (5), Yandex (4), and marketing platform Amplitude (3).

This screenshot shows how Speedy Quark VPN sent a fingerprint of my device to configv2.unityads.unity3d.com that included a long list of data points, such as device make/model, language, OS, screen size/resolution, time zone, connection type, cores, Android fingerprint, battery, free space, USB connection, volume, ad ID, ISP, and even headset use.

Screenshot of network traffic capture from Speedy Quark VPN showing a device fingerprint being sent to Unity Ads.

Together, these attributes create a unique fingerprint to identify and track my device across websites/sessions without traditional identifiers like cookies or IP addresses, enabling persistent tracking.^[4]

Even if I were to clear my cookies or browse in private mode, this wouldn’t obscure my device fingerprint.

This data can be sold to data brokers for advertising, analytics, or other purposes, often without our awareness or consent.

First-party: I found 4 VPNs that sent a fingerprint of my device to their own servers.

This screenshot shows the data points about my device collected by VPN 360 co.infinitysoft.vpn360 (8.8 million installs).

Screenshot of device fingerprinting performed by VPN 360 and sent to its own servers.

These personal data points about my device that the app collected include:

• Screen width and height
• WiFi
• Operating system
• Whether the device has NFC
• Presence of cellular functionality
• Screen resolution
• Device manufacturer and model
• ISP
• SIM card country
• Device language
• Build number

You can also see other numerical identifiers and timestamps that are sent in the same request.

While some VPNs may fingerprint devices to analyze users for product improvements, there’s a risk that this valuable data could be sold to third parties.

Basic Telemetry

First-party: Almost two thirds of the VPNs (19 apps) that sent user data to their own servers limited themselves to basic telemetry about me and my device, defined as general data points like device model, operating system, country, language, time zone, etc.

While collecting no user data at all is best practice, this kind of data collection carries the lowest privacy risk.

However, the more data points collected, the greater the privacy risk, blurring the distinction with device fingerprinting.

Notably, apps like Urban VPN phoned home with basic telemetry (as noted in the table above) without using the usual methods outlined in the source code review.

These data points may have been collected using the very common getResources().getConfiguration() function.

This function is typically used to collect device configuration data like screen size and orientation to allow apps to display correctly, despite the huge array of Android devices they may be running on.

It doesn’t even require permission to run as it is not sensitive on its own.

However, the potential for other uses of this data remains.

Third-party: Over half of the VPNs (56) I analyzed shared basic device telemetry with at least one third party, many with more than one ad tracker.

Some, like Betternet VPN, shared it with as many as 5 partners.

The most popular recipients were Google (39 VPNs) them Facebook (17 VPNs) and Yandex (9 VPNs).

I compared the information submitted by developers and displayed in the Data Safety section of the Play Store listing of their VPN apps with their full privacy policies. The following are my key findings from this analysis of 100 VPNs’ Data Safety labels.

Of the 100 free VPN apps I analyzed, only 5 had Data Safety labels on the Play Store that accurately reflected their privacy policies.

For 2 VPNs, I wasn’t even able to access their privacy policies to verify the labels.

Alarmingly, my findings reveal that free Android VPN apps exhibit less transparency in their Data Safety labels than general apps like TikTok and Facebook.

Mozilla’s analysis found 80% of top apps had inaccurate labels, but my research reveals an even higher rate of inaccuracy among free Android VPNs – apps specifically marketed for privacy.

Data collection discrepancies

I identified 57 VPNs whose Data Safety labels failed to disclose personal data collection practices mentioned in their policies.

For example, Betternet com.freevpnintouch, with 80 million installs, claimed to only collect “Device or other IDs” in its label.

However, its privacy policy details collection of account info, billing data, usage data, device diagnostics, and VPN-specific data.

I also identified 20 VPNs listing personal data collection in their labels that wasn’t mentioned in their privacy policies, further adding to the confusion.

While increased transparency is positive, significant discrepancies between Data Safety labels and privacy policies leave consumers uncertain about apps’ true data collection practices.

Data sharing discrepancies

I discovered that 43 VPNs had labels that failed to disclose data sharing practices outlined in the apps’ privacy policies.

Only 20 out of 65 VPNs that claimed “no data sharing” in their labels made the same claim in their privacy policies.

Contradictions often involved sharing aggregated user data with service providers, as well as sharing data with advertising, marketing, and analytics platforms.

I also identified 21 VPNs listing data sharing in their labels that wasn’t mentioned in their privacy policies, further compounding the confusion.

Security practice disclosures

Interestingly, I found 20 VPNs that disclosed additional security practices in their labels that were not outlined in their privacy policies.

In contrast, 12 VPNs had labels missing relevant security information specified in their policies.

For example, Psiphon’s com.psiphon3.subscription label mentioned independent security reviews and data encryption in transit, but its privacy policy lacked any such details.

Should the labels be accurate, then these are of course very commendable security practices. Their omission from privacy policies, however, casts doubt on the overall reliability of these crucial documents.

What Was Missing?

The following table breaks down some of data collection missing from VPN app Data Safety labels by category.

Click on the Expand Table button for a fullscreen view and scroll to see all apps’ data.

As shown in the table, I identified 25 VPNs that failed to disclose location data collection in their Data Safety labels. This includes the collection of IP addresses, as they are considered to be geolocation data under laws such as the California Consumer Privacy Act (CCPA).

I also found 15 VPNs that should have had labels relating to financial and billing information, and 2 VPNs that failed to mention access to the device camera.

Furthering the sense of confusion for users, only 4 of the 25 VPN apps whose labels failed to reflect the location data collection disclosed in their privacy policies actually requested the relevant permissions.

As revealed in my Permissions analysis above, I identified 19 VPNs with location permissions. However, only 5 VPNs disclosed the collection of location data in their Data Safety labels.