Free Android VPN Security Flaws: 100 Apps Tested

I tested the 100 most popular free VPNs in the Google Play store and found significant security and privacy flaws affecting Android apps that have been installed over 2.5 billion times worldwide.
Free Android VPN Security Flaws header illustration
Simon Migliano

I’ve spent the last couple of months testing the 100 most popular free Android VPN apps, which have 2.5 billon worldwide installs between them.

I analyzed the masses of results generated by those VPN tests to create this research report that’s intended to help you avoid using potentially unsafe free VPNs that compromise your privacy and security.

See the full list of the 100 VPNs I tested, including developer names and addresses, installs and other Play Store listing details.

Key Findings: Android VPN Security Testing

  • VPN encryption failures: More than one in ten free VPN Android apps suffered encryption failures, ranging from total exposure of internet activity to leaking details of websites visited.
  • Leaky VPNs: Almost 90% of free VPN Android apps suffered some kind of leak, including 17 VPNs leaking more than DNS request data.
  • VPN tunnel instability: Over half of VPNs showed signs of VPN tunnel instability.
  • Weaker encryption: Over a third (36%) of VPNs tested had less than optimal encryption. Only 20% were observed to use the strongest hashing algorithms.
  • Risky permissions: Almost 70% of VPN apps tested request at least one privacy-risking permission, such as location tracking (20%) and scanning for installed apps (46%).
    • Proprietary code: Over half (53%) of VPNs tested contained at least one function and the matching permission in their own source code that posed a potential risk to user privacy.
    • Third-party software libraries: 80% of VPNs contained software libraries featuring at least one such function and matching permission.
    • Bytedance & Yandex: 15 VPNs contained code within software libraries created by TikTok developer Bytedance that posed a potential privacy risk, along with the necessary permissions. For Yandex, this was 11 VPNs.
  • Third-party tracking code: 84 VPNs apps tested contained software development kits (SDKs) from marketing or social media platforms. 16 VPNs contained 10 or more of these SDKs.
  • Privacy risks related to device hardware: Almost a third (32%) of VPNs tested declared use of devices’ features and sensors that raised red flags from a privacy perspective, such as cameras (15 VPNs) or location-tracking hardware, including GPS (14 VPNs).
  • Third-party data collection: I found evidence of 71 VPNs sharing personal data with third parties such as Facebook, Yandex, and data brokers like Kochava, including device fingerprints (37 VPNs) IP addresses (23 VPNs), and unique tracking IDs (61 VPNs)
  • Suspected malware: Almost one in five (19%) of VPN apps tested were flagged as malware by anti-virus scanners
  • Data Safety labels: 93 VPNs had discrepancies between their privacy policies and Play Store listing labels.

Identifying Potentially Unsafe VPNs

This is the biggest piece of VPN research I have ever done but
I believe there’s a pressing need for it due to the frequent surges in demand for VPN that we regularly see around the world, as governments restrict their citizens’ access to the internet.

The number of free VPN users has increased at least tenfold since I began seriously investigating the dangers of free VPNs in 2018.

The 100 most popular free Android VPNs had around 260 million total installs in 2018. Today, that number exceeds 2.5 billion.

I installed each of these 100 free VPN 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.

Click or tap on the links below to jump ahead to an analysis of my findings for that particular area.

The results of these tests allowed me to not only identify each individual VPN’s security and privacy flaws but also to map out the current state of this significant part of the VPN industry.

I installed the VPNs one-by-one onto very basic, entry-level Samsung smartphones that had been stripped of all but the most basic stock apps.

I then conducted the tests using a variety of publicly-available tools, including our own VPN leak checker, along with Wireshark, mitmproxy and others.

The author of this research,'s Simon Migliano, testing the free VPN apps included in this report

The author of this research,’s Simon Migliano, testing the free VPN apps included in this report.

I intercepted network traffic from the VPN apps in a dedicated “cleanroom” environment to ensure the cleanest possible data capture for our analysis.

The results were alarming.

Significant numbers of these VPN apps put our privacy and security at risk due to serious encryption failures and data leaks.

Half of the VPN apps I investigated contained functions in their source code that were a potential risk to privacy, along with the necessary permissions to run them.

My findings confirm how the majority of free VPN apps put our privacy at risk by sending our personal data directly to third parties, including controversial firms like Bytedance and Yandex.

The challenge faced by free VPN providers is how to cover the cost of providing a VPN service without subscription fees coming in to pay for it.

Worse, those overheads increase as a VPN becomes popular and requires more servers to accommodate its growing user base. That’s not even taking into consideration any development costs or back-office support.

While it’s little surprise then that most free VPN providers rely on advertising or monetizing their user data to cover costs and hopefully turn a profit, it’s fundamentally at odds with the whole purpose of a VPN.

I always recommend paying whatever you can afford for a VPN, even if it’s a cheaper service, as it means the provider doesn’t need to find other ways to make enough money to keep the lights on.

If any kind of monthly fee is out of the question, it is possible to get a good free VPN if you do your research, but it will inevitably just come with some trade-offs, such as a data cap or limited servers.

VPN Leaks and Encryption

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.

  • VPN encryption failures: 11 free VPN Android apps suffered encryption failures in my tests, ranging from total exposure of internet activity to leaking details of websites visited.
  • Weaker encryption: Over a third (36) of VPNs tested had less than optimal encryption, while only 19 used the strongest hashing algorithms. 11 apps did not use the strongest algorithm for PRF.
  • Weak handshakes: Almost a quarter (23 VPNs) failed to always use the latest TLSv1.3 protocol to initiate the VPN tunnel. Six of them used the obsolete SSLv2, which is deprecated as it is insecure.
  • Leaky VPNs: 88 VPNs suffered some kind of leak:
    • 17 VPNs suffered multiple leaks (IPv4, IPv6, DNS or WebRTC)
    • 83 VPNs leaked DNS requests
    • 79 VPNs failed to send all traffic through the tunnel, as evidenced by visibility of requests with exposed domain names via SNI
  • VPN connection instability: 24 apps experienced more than 16 VPN connection resets on average per (brief) session. Over half (53 apps) displayed signs of VPN tunnel instability.

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.

Video walkthrough of the leaks and encryption testing I carried out on the VPN apps in this research

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

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

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 and 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 as the default app setting.

Screenshot of the attempted use of TLSv1 by HTTP Injector (SSH/UDP/DNS) VPN Android app

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
  • Tomato VPN
  • Urban VPN
  • 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”
  • 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
  • Phone Guardian VPN com.distimo.phoneguardian
  • Ultimate VPN
Screenshot of Top10VPN leak tool showing IPv6 leak in VPN Pro

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
  • (93 million)

  • VPN Proxy Master
  • (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 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

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
  • VPN: The Privacy Guard
  • 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 which they used to show me my geolocation data.

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

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

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 sent rather than received similar information to the following URL on the IP address.

The content on 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

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, 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.

Risky Android Permissions

Next up are my key findings about how many free VPN apps request the various Android permissions that pose a potential privacy risk.

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

Over two thirds (69) of the VPNs I tested request at least one high-risk permission that’s arguably not absolutely necessary in this kind app:

  • Location tracking: 20 VPNs request to track your location.
  • Access to most sensitive data: 9 VPNs request the READ_PHONE_STATE permission.
  • Ad tracking: 82 VPNs have permission to retrieve your unique ad tracking ID.
  • Scan device for installed apps: 46 VPNs request permission to scan the apps on your device.
  • Use of camera: 10 VPNs request permission to use your device’s camera.

Here’s those key findings as a bar chart to make it easier to compare the number of VPNs requesting these risky permissions.

Chart showing the number of free VPN Android apps that request permissions with the highest risk to privacy

Chart showing the number of free VPN Android apps that request permissions with the highest risk to privacy.

The chart labels refer to the following specific Android permissions:

  • Ad tracking: or ACCESS_ADVERTISEMENTS_ID for accessing advertising IDs to enable user tracking and targeted ads across apps and devices.
  • Scan installed apps: QUERY_ALL_PACKAGES for retrieving data about other installed apps, potentially misused by ad SDKs.
  • Location tracking: ACCESS_COARSE_LOCATION (approximate location), ACCESS_FINE_LOCATION (precise GPS location), or ACCESS_BACKGROUND_LOCATION (continuous tracking in the background).
  • Camera: CAMERA for using the device’s camera.
  • Sensitive data access: READ_PHONE_STATE for accessing phone number, call status, network information, and device identifiers like IMEI and IMSI.

While not all apps use the functionality implied by their permissions, the mere presence of these high-risk permissions raises privacy concerns.

Granting unnecessary permissions leaves users vulnerable to potential misuse or future app updates that introduce undesirable features.

Notably, 76 VPNs declared, enabling unrestricted ad tracking, while just 6 others requested the ACCESS_ADVERTISEMENTS_ID permission that has some limitations.

Nearly half (46 VPNs) requested QUERY_ALL_PACKAGES for scanning installed apps, which can potentially be exploited by ad SDKs.

One in five (20 VPNs) requested location tracking permissions, with 16 enabling precise GPS tracking and 5 allowing continuous background tracking.

One in ten (10 VPNs) requested camera access, and 9 requested READ_PHONE_STATE for accessing sensitive device and network data like phone numbers and IMEI/IMSI identifiers.

Risky Android Source Code

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.

  • Proprietary code: 54 VPNs contained at least one function in their own first-party source code along with the matching Android permission that together posed a potential risk to your privacy.
  • Third-party software libraries: 80 VPNs contained software libraries (SDKs) featuring at least one privacy-risking function and requested permission to run it.
  • Bytedance & Yandex: I found 19 VPNs containing risky code within SDKs developed by these controversial firms, that also requested the relevant permissions.

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 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 (7 risky functions)
  • Kaspersky (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.

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

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, 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, 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

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[1]

Under Russian laws, the government and intelligence agencies may have the authority to access user data held by Russian companies like 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
  • Lantern VPN org.getlantern.lantern
  • TLS Tunnel com.tlsvpn.tlstunnel
  • VPN – fast proxy + secure
  • Wolf VPN com.wolf.vpn
  • VPN – fast secure vpn proxy

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.[3]

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

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 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.

External Trackers

The key findings from my analysis of the use of external tracker SDKs by free VPNs, such as those from social media and adtech firms are in the box below.

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

I identified 67 different software development kits (SDKs) from marketing or social media platforms in 84 VPN apps.

  • 48 VPNs contained 3 or more tracking SDKs. 16 VPNs contained 10 or more such code.
  • 5 external trackers on average in every free VPN Android app.
  • 20 VPNs contained Bytedance or Yandex software libraries: 8 VPNs contained SDKs from both firms while a further 5 VPNs contained Yandex code only and 7 VPNs contained Bytedance code only.

As you can see in this chart, the third-party tracker SDKs I found most frequently during my analysis were from Google, Facebook and Unity Ads.

Chart showing the 10 most commonly found third-party tracking SDKs in free VPN Android apps

Chart showing the 10 most commonly found third-party tracking SDKs in free VPN Android apps.

As the developers of Zoog VPN told me when I asked why they incorporated SDKs like AppsFlyer into their app, the free VPN market is unfortunately so competitive that it’s very difficult for them to survive without the kind of mobile attribution data that this intrusive technology offers them.

Other notable SDKs I found included:

  • Russian social media platform VK (11 VPNs)
  • Huawei (9 VPNs)
  • MyTarget (9 VPNs)
  • US adtech firm Tapjoy (5 VPNs)
  • Russian adtech platform Appodeal (5 VPNs)
  • Data broker Kochava (2 VPNs)

Third-party tracking SDKs in Android VPN apps put users’ data privacy at significant risk.

These SDKs collect sensitive user data like device identifiers, locations, and browsing activities for targeted advertising, undermining VPNs’ purpose of protecting online privacy and anonymity.

The collected data can potentially be exposed to malicious actors, as well as ad networks and data brokers.

Many SDKs operate opaquely, obscuring data collection extent and involved parties, raising misuse or unauthorized access concerns.

By integrating these SDKs, VPN providers betray users’ trust, facilitating data collection and potential exposure instead of safeguarding it as expected.

It’s shocking that almost half the tested free VPNs contained at least 3 advertising SDKs.

Even when VPN apps, like Windscribe for example, only use Amazon and Google SDKs for functionality like taking payments, there remains a privacy risk due to these companies’ general tracking and data practices.

Risky Hardware Use

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.

Almost a third (32%) of VPNs I looked at declared use of device features and sensors that raised red flags from a privacy perspective, including:

  • Camera, including auto-focus: 15 VPN apps.
  • Location, including GPS: 14 VPN apps.
  • Sensors, including gyroscope and proximity: 14 VPNs.
  • Microphone: 7 VPNs.

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.

Data Sharing

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.

  • Third-party data collection: 71 VPNs shared personal data with at least one third party. VPNs shared with two other third parties on average, with 25 VPNs sharing with a greater number of third parties than that.
  • Device fingerprinting: 37 VPNs shared device fingerprint data with third parties such as Facebook, Yandex or adtech firms like Vungle.
  • IP address: 23 VPNs shared users’ real IP addresses with third parties such as Google or adtech firms like Ironsource and Unity.
  • Google Advertising ID: 61 VPNs shared this unique identifier with third parties such as Facebook, Yandex or data brokers like Kochava.
  • VPN provider data collection: 30 VPN apps were found to send some form of user data to their own servers, including 4 VPNs which logged device fingerprints.

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.

Video walkthrough of the network traffic analysis I carried out on the VPN apps in this research

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

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 domain as part of a video ad request.

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

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

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 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

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

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 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 device fingerprint being sent to Unity Ads

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

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).

Variance in Data Sharing Findings

The primary source for my data-sharing findings was my own manual traffic analysis.

However, I also scanned each VPN APK file using VirusTotal and documented the ad tracking domains contacted by each app that were included in the scan results.

For transparency, here’s how the results varied between the two approaches.

VirusTotal’s automated scans found 6 VPNs refrained from contacting ad trackers, while I observed one of those 6 contact Google.

In about a third of apps, I observed contact with more third-party trackers than VirusTotal showed. Results matched for 14 VPNs.

For the remaining half, VirusTotal found that apps contacted more trackers than I observed myself, sometimes significantly more.

Speedy Quark VPN contacted 39 trackers according to VirusTotal as opposed to the 5 that it contacted in my tests, including,, (Bytedance), and others.

This variance likely stems from real-time bidding behavior of demand-side platform SDKs integrated in VPNs, contacting numerous ad domains to bid on opportunities and share user data.

Malware Flags

Here are the key findings from virus scans I conducted on 100 free Android VPN apps.

To see the full findings, download the Google Sheet.

  • Suspected malware: Almost one in five (19%) of VPN apps tested were flagged as malware by anti-virus scanners.
  • Suspicious domains & IP addresses: 18% of VPN apps contacted internet domains flagged as suspicious. 13 VPNs contacted IPs flagged in this way.

I scanned the APK files of the 100 VPNs in this study with VirusTotal, a powerful virus scanning tool that leverages over 70 antivirus and security vendors’ databases and detection engines.

While VirusTotal can produce false positives due to inherent limitations of antivirus technologies, it was instructive to use it on such a large cohort of VPN apps.

The following 19 VPNs had at least one, and sometimes more than one, malware warning in their VirusTotal results.

I am not claiming that these VPNs are actually malware, rather that they simply displayed sufficient behaviors and characteristics to be flagged as such by AV software.

  • org.freevpn
  • com.ambrose.overwall
  • com.beanstudiohq.vpn
  • openvpn.vpn
  • com.evozi.injector
  • com.bitdefender.vpn
  • com.wolf.vpn
  • vpn.ukraine_tap2free
  • app.jumpjumpvpn.jumpjumpvpn
  • com.brocode.uvpn
  • com.vpncity
  • antivirus.virus.cleaner.clean.vpn.booster

The most frequent malware designations were:

Malware Name Flagged in (apps)
Win32.Troj.Admob.a 8
Phishing.Generic-HTML.Save.u 5
Android.Troj.Unknown.a 1
Dropper.Shedun.Android.239430 1
TROJ_GEN.R002V01JR23 1
Trojan.LockScreen.Android.8376 1

These designations were almost entirely generic, however, including the most common instance of potential malware.

The exact nature of threat posed by the Win32.Troj.Admob.a designation is not clear, beyond that it has been flagged as a potential trojan by the virus scanners.

While the designation suggests it could be a false positive triggered by the presence of the AdMob library, there were many apps where the presence of this common Google advertising library did not trigger this malware flag.

The generic Phishing.Generic-HTML.Save.u designation is used by some AV vendors to identify potential phishing attempts delivered through HTML files when the kit can’t be precisely identified but exhibits typical phishing characteristics.

Most of the others are generic designations for trojans used by various AV vendors.

The exception was Dropper.Shedun.Android.239430, a variant of the Shedun Android malware family known for dropping additional malicious payloads on infected devices.

These malware flags should be viewed with low confidence, as most of them were only identified as such by a single vendor.

However, it’s concerning that almost one in five VPNs share sufficient characteristics with malware that they trigger warnings from AV tools.

VirusTotal flagged 18 VPNs for contacting domains and 13 VPNs for contacting IP addresses considered suspicious.

Most domain flags related to, a subdomain of GIF vendor Tenor.

Though its purpose is unclear, it may be a content delivery network (CDN) for GIFs.

However, it raises questions why many free VPNs contact this subdomain without displaying GIFs.

Other flagged domains include:


Domains may be flagged for malicious activities, suspicious traffic patterns, poor reputation, or data exfiltration.

The suspicious IP addresses seem innocuous, but some concerning contacts were observed, like (Facebook CDN) and IPs assigned to Yandex. Other IPs likely flagged due to abuse for hosting malware or phishing.

Misleading Data Safety Labels

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.

My analysis of Data Safety labels on the Play Store revealed widespread discrepancies with VPN apps’ privacy policies.

  • Misleading Labels: 93 VPN apps had inaccurate Data Safety labels, with:
    • 75 VPNs misrepresented data collection practices.
    • 64 VPNs misrepresented data sharing with third parties.
    • 32 VPNs misrepresented security practices.
  • Unsupported “No Data Sharing” Claims: 65 VPNs claimed no data sharing in their labels, but only 20 privacy policies confirmed this.
  • Unsupported “No Data Collection” Claims: 32 VPNs claimed no data collection in their labels, but only 2 privacy policies confirmed this.

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.


I selected the 100 VPN apps for inclusion in this report based popularity via their ranking in the Google Play Store and number of global installs.

I installed each VPN app on a test device running stock Android that had been stripped back to mandatory core apps only that could not be uninstalled or disabled.

I captured apps’ network traffic using Wireshark and mitmproxy as 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 and malware scans in order to to ensure app version consistency between all tests.

I conducted malware scans using VirusTotal.

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

The authors of all our investigations abide by the journalists’ code of conduct.