Contact

Methodology

How we turn evidence into a number

Every figure on this site traces to a cited primary source, and the arithmetic that produced it is public on this page. Nothing here is a verdict you are asked to trust; it is a calculation you are invited to check.

Preview, not yet human-verified.

The current corpus was gathered and citation-checked by machine. No person has yet confirmed every excerpt against its source, so nothing on the site is presented as recommended. This page describes the method that will govern the reviewed corpus; the method is real today, the human review is not yet done.

1 · No evidence, no score

A fact only reaches a scoring rule if it carries at least one citation to a primary source, a privacy policy, an audit report, a court filing, source code, or a measurement we took ourselves. This is not a guideline we try to follow; a fact with an empty evidence list cannot be constructed in the first place, so it cannot reach a rule.

We never cite a competitor's review site. A domain blocklist fails our build if anyone tries. Ranking VPNs partly on what other ranking sites said about them would launder their conclusions into ours, and their conclusions are the thing we exist to replace.

Facts we have not sourced are represented by leaving the field out, never by a zero and never by an empty citation. The difference matters for the next rule.

Independent security assessment

How we audit a VPN application

This protocol describes the hands-on security assessment used for SingLinkVPN v2.5 and future VPN client audits. It is version-, platform-, environment-, and time-bound: every result belongs to the exact build and test matrix recorded in the report.

Governing principles

  1. Freeze the product version, platform build, test date, account state, network, and test environment before execution.
  2. Record expected behavior, actual behavior, raw evidence, severity, retest status, and reviewer for every test case.
  3. Treat “not reproduced” as a bounded observation, never proof that a vulnerability cannot exist.
  4. Test normal use, failure states, adversarial requests, network transitions, and regression after remediation.
  5. Keep provider statements separate from our measurements; a claim cannot replace a test result.
  6. Publish scope exclusions and unavailable evidence beside the result, not in fine print.

Minimum test matrix

The exact matrix varies by product. A cross-platform audit should cover every supported client that can create a materially different security path.

AreaRequired coverage
PlatformsiOS, Android, macOS, Windows, Linux, TV clients, and web dashboard where offered
NetworksWi-Fi, mobile data, IPv4, IPv6, network loss, network switching, captive or restricted conditions where available
Connection statesFirst connect, reconnect, server switch, sleep/wake, app restart, process termination, logout, expired session
Tunnel modesFull tunnel, split tunnel, application and domain exclusions, automatic routing
AccountsValid, invalid, expired, logged-out, cross-device, and unauthorized request states
BuildsProduction build identifiers and remediated builds; debug-only behavior is excluded unless explicitly tested

Execution procedure

1. Scope, authorization, and asset freeze

Define what is permitted and preserve the identity of everything being tested before touching the product.

  • Written authorization and rules of engagement
  • Product/version/build hashes
  • Platform and device inventory
  • Domains, APIs, dashboard, and excluded assets
  • Test accounts and data-handling rules
  • Start and cut-off times

2. Baseline and attack-surface mapping

Map the connection lifecycle and trust boundaries so tests exercise the real data paths rather than only visible interface states.

  • Authentication and token flow
  • VPN startup and configuration flow
  • API endpoints and request parameters
  • Local storage and diagnostic paths
  • Routing, DNS, tunnel adapter, and reconnection behavior
  • Privileged operations and platform permissions

3. Connection lifecycle and safe failure

Verify that displayed connection state matches the operating system’s actual route and that failures do not silently expose traffic.

  • Connect, disconnect, reconnect, and server switch
  • Loss of local connectivity
  • Server-side interruption
  • App restart and abnormal process termination
  • Device sleep and wake
  • Wi-Fi/mobile transition
  • Automatic recovery without stale routes

4. DNS, IP, IPv6, WebRTC, and route leakage

Observe public addresses, resolvers, ICE candidates, interfaces, and route tables before, during, and after tunnel transitions.

  • IPv4 source-address exposure
  • IPv6 bypass or fallback
  • DNS resolver leakage
  • WebRTC candidate exposure
  • Local-network information exposure
  • Prolonged unprotected traffic after interruption
  • Split-tunnel boundary enforcement

5. Account, session, and authorization controls

Attempt to cross authentication and tenant boundaries using realistic invalid and adversarial requests.

  • Unauthenticated endpoint access
  • Invalid and expired tokens
  • Token invalidation after sign-out
  • Parameter and object-identifier modification
  • Cross-account subscription/data access
  • Session state across devices
  • Dashboard authorization

6. Internal connection and configuration protection

Probe the APIs that provide server, route, certificate, credential, or internal connection material without publishing sensitive data.

  • Requests from non-standard clients
  • Missing, malformed, replayed, and expired authorization
  • High-frequency and automated probing
  • Request signing and freshness controls where used
  • Rate limiting and anomaly blocking
  • Isolation of internal configuration from public endpoints

7. Local data and production-build hygiene

Inspect what the client leaves on the device and what its production diagnostics disclose.

  • Credential and token storage
  • Operating-system secure storage use
  • Logs, crash reports, and temporary files
  • Sensitive configuration remnants
  • Debug endpoints and verbose production logs
  • Unnecessary network-activity or account data

8. Cross-platform consistency

Compare controls across clients because one weaker platform can create the practical bypass for an otherwise sound design.

  • Equivalent leak protection
  • Equivalent session invalidation
  • Equivalent safe-failure behavior
  • Platform-specific permissions
  • Version drift and missing controls
  • Dashboard/client policy consistency

9. Finding validation and severity

Reproduce suspected issues, remove environmental false positives, document prerequisites, and grade impact before reporting.

  • Independent reproduction
  • Minimal proof of concept
  • Affected versions and platforms
  • Exploit prerequisites
  • User and infrastructure impact
  • Evidence preservation without exposing secrets

10. Remediation and regression retest

A finding is closed only after the fixed build is identified, the original issue no longer reproduces, and adjacent controls still behave correctly.

  • Fix and build identity
  • Original proof rerun
  • Negative and boundary cases
  • Cross-platform regression
  • New attack surface check
  • Closed, partially fixed, accepted, or unresolved status

Severity model

Severity combines impact, exploitability, prerequisites, affected scope, and remediation urgency.

Critical
Large-scale sensitive-data exposure, remote code execution, core-system control, complete authentication bypass, or broad VPN traffic exposure.
High
Account takeover, important private-data exposure, unauthorized protected access, traffic bypass, or failure of a core security control.
Medium
Material impact requiring specific conditions or affecting a limited platform, feature, dataset, network, or device environment.
Low
Limited direct impact that weakens defense in depth or exposes non-core technical information.
Informational
No directly exploitable vulnerability, but a concrete security-engineering or hardening improvement.

How a 100-point audit score is calculated

The report must publish the scored checklist and item weights. Each item begins with its assigned points; a reproducible unresolved finding removes the points attached to the affected control according to the report’s declared rule.

A remediated issue earns its points only after a documented retest passes. Untested, blocked, or out-of-scope items cannot silently receive full credit; they must be excluded from the denominator or shown separately.

A result of 100/100 therefore means all scored in-scope items passed in the tested build. It is not a lifetime guarantee, a claim of zero possible vulnerabilities, or an overall provider score.

Evidence and reproducibility requirements

  • Test-case identifier, owner, date, platform, device, OS, application version, and environment
  • Expected result, actual result, reproducibility status, and severity rationale
  • Sanitized screenshots, packet/route observations, request traces, logs, or hashes where safe to publish
  • Build matrix, scoring worksheet, change log, remediation record, and reviewer sign-off
  • Separation between public evidence, redacted security evidence, and confidential material
  • Content hash or immutable archive for public artifacts so later edits are detectable

Mandatory limitations

  • Testing samples behavior; it cannot prove the absence of every vulnerability.
  • Results do not automatically transfer to later versions, untested platforms, different backends, networks, accounts, or configurations.
  • Black-box and grey-box testing cannot verify source-code paths or server operations that were not made available.
  • No-logs claims require operational or infrastructure evidence; client leak testing alone cannot prove them.
  • Unavailable signed reports, worksheets, build matrices, or raw evidence reduce independent reproducibility and must be disclosed.

Reproducible VPN leak-test protocols

The versioned kill-switch, DNS, WebRTC, and IPv6 specifications define the test matrix, evidence requirements, pass conditions, limitations, and blank raw-data format. Protocol pages are not results: no provider receives a pass until completed evidence and reviewer records are published.

Read the protocols and download blank result templates

2 · A gap in our research never lowers a score

If we have no evidence for a dimension, that dimension is excluded from the weighted mean, not scored as zero. Penalising a provider for a hole in our research would quietly reward whichever providers we happened to research least, which is the precise failure the whole model is built to avoid.

The price of this rule is that scores are not automatically comparable, and we pay it in the open. Every dimension carries a coverage fraction, how many of its rules had evidence to act on, and every score carries a scored-weight: an 8.4 scored on 72% of the methodology means 28% had no data, and the page says so beside the number. A dimension with no facts at all scores neither 0 nor 10 but nothing, and drops out.

3 · Where a number came from travels with the number

We do not run a global speed matrix or a streaming unblock suite. Printing a vendor's own throughput figure in the same typeface as a privacy policy we read line by line would erase exactly the distinction that matters, so every score is stamped with how it was sourced. There are four kinds:

Measured
We produced this number ourselves and can reproduce it.
Documented
Read out of a primary document: a privacy policy, an audit report, or source code.
Vendor-claimed
Asserted by the provider. We have not independently verified it, and the score is capped accordingly.
No evidence
We found nothing to score. The dimension is excluded from the weighted mean rather than counted as zero.

Provenance also sets a ceiling. Because we cite others' speed tests rather than run our own, speed tops out at 8.5. Because a streaming claim is a marketing page, not a test we ran, streaming tops out at 6.5. A number we did not earn the right to certify cannot reach the top of our scale, and the cap is shown, not hidden.

4 · The eleven dimensions, and how they are weighted

A provider is scored on eleven dimensions. The default weighting allocates the most weight to what we can independently verify and the least to what we can only read off a vendor's page. Speed and streaming, both vendor-territory here, carry roughly half the weight the industry standard gives them; that weight moves to privacy, transparency and server authenticity.

DimensionSourced asCeilingDefaultTop10VPN parity
Privacy
Logging policy, jurisdiction, ownership, read from policies and filings.
Documented1024%20%
Security
Protocols, kill switch, cipher choices, read from docs and source.
Documented1018%15%
Transparency
Published audits, canaries, open-source clients.
Documented1012%,
Server authenticity
Latency triangulation from our own probe network, the dataset we will own.
Measured1010%,
Server locations
Counts are the provider's claim; server authenticity is what checks them.
Vendor-claimed107%10%
Streaming
A marketing page listing every service on earth. We run no unblock suite.
Vendor-claimed≤ 6.57%15%
Speed
Third-party measurements. We did not produce them, so they cannot top the scale.
Documented≤ 8.57%15%
Device compatibility
Platforms and app listings, read directly.
Documented105%5%
Usability
Setup and interface, read from docs and store listings.
Documented104%10%
Torrenting
Port forwarding, kill-switch behaviour, P2P policy from the docs.
Documented103%5%
Additional features
Split tunnelling, multi-hop, ad blocking, present or absent, per the docs.
Documented103%5%

The Sourced as column names each dimension's characteristic source under the method, not its provenance in today's unreviewed corpus. Server authenticity, speed and usability are the dimensions we intend to measure or read ourselves, but the current corpus holds no evidence for them yet, so they carry no score today, per rule 2.

The Top10VPN parity column reproduces a competitor's published weighting over our evidence. It zeroes transparency and server authenticity, that methodology has no equivalent category, and it is shipped on purpose: it lets you separate “the data disagrees” from “the methodology disagrees.” If you suspect we tuned the weights to reach a conclusion, run the numbers under theirs and see what moves.

The same evidence is also published under three use-case weightings. They are not doorway pages: same data, a different question.

Default (evidence-weighted)
Weights are allocated toward what this site independently verifies. Speed and streaming are vendor-claimed rather than measured here, so they carry roughly half the weight the industry standard assigns them; that weight moves to privacy, transparency and server authenticity, all of which are checked against primary documents or our own probe network.
Top10VPN parity
Reproduces the published Top10VPN category weighting (privacy 20%, streaming 15%, speed 15%, security 15%, server locations 10%, user experience 10%, torrenting 5%, device compatibility 5%, additional features 5%). Transparency and server authenticity are zeroed because that methodology has no equivalent category. Published so readers can see exactly how much of a ranking is the data and how much is the weighting.
Privacy first
For readers whose threat model is surveillance rather than geo-blocking. Logging policy, jurisdiction, published audits and open-source clients dominate; streaming access is worth nothing.
Streaming
For readers unblocking geo-restricted catalogues. Note the honesty cost: this site does not run its own unblock suite, so the streaming dimension is capped at a vendor-claimed ceiling and this ranking is the least independently grounded one we publish.
Torrenting
For P2P users. Weighted toward what actually exposes a seeder: the logging policy, a kill switch that fails closed, and whether port forwarding exists at all. Mirrors Top10VPN's observation that torrenting quality is mostly a function of the privacy and security categories.

One deliberate divergence from Top10VPN: their torrenting score folds their own privacy and security scores back into the dimension. Ours does not, the torrenting weighting already assigns privacy and security their own top-level weight, and folding them in a second time would count the same evidence twice.

5 · Three ways a dimension's rules combine

You cannot check a number without knowing the arithmetic behind it, so which of three models produced a dimension is published beside it.

ModelHow the rules combineUsed by
AbsoluteStart from a base and add signed deductions or credits. Base 10 for the deduction dimensions, base 0 where points accrue.Security, server authenticity, speed, streaming, usability
NormalizedPoints earned divided by points available, but only over the rules that had evidence. This is the ratio that rule 2 quietly inflates, see the limitation below.Transparency, server locations, device compatibility, torrenting, additional features
CompositeA weighted mean of named sub-scores, each itself absolute or normalized, over the parts that scored.Privacy

A score is never a bare number in our data: it carries its model, its ceiling, and every rule that fired with its signed contribution and the evidence ids behind it. A separate, independent implementation reconstructs each headline from only what a review page shows; if a breakdown is ever incomplete, that check fails the build. It means you can disagree with a specific deduction rather than with a vibe.

6 · Privacy is composite, and cannot be bought back

Privacy is the one composite dimension, split into five sub-scores: what data is logged (60%), incident history (20%), jurisdiction (10%), trustworthiness (5%), and privacy-enhancing features (5%). Confining credits to those small parts is deliberate. Under a flat model, a credit for accepting cash could cancel a deduction for retaining payment records, and the clamp at 10 would hide the rest, a provider that logs and one that does not could print the same perfect score.

A weighted mean is still compensatory, and privacy is a safety property, so the dimension is capped at its own logging sub-score plus 1.5. No combination of favourable jurisdiction, transparent ownership and payment options can lift a privacy score more than 1.5 points above what the logging policy alone earns. A provider retaining browsing history indefinitely cannot buy its way out of that with a Panama address.

7 · The published number is an interval, clamped

Renormalising a score over the dimensions we happened to measure is a defensible estimate, but it is not a bound, and the old kind of review site published the estimate as if it were one. So every score carries three numbers, not one.

Floor

What the provider has earned outright, counting everything unmeasured as zero. It can only fall when evidence is removed, which is what makes it safe to rank by.

Headline

The published figure: the renormalised mean, held down so it can never exceed the potential. When the two differ, the page tells you renormalisation over-credited the provider, and by how much.

Potential

The most it could reach if every unmeasured dimension hit its own ceiling, so unmeasured streaming is credited at 6.5, not 10. A guaranteed maximum, not a guess.

Drawn to scale, the bar is the honest width of what we do not yet know. Here is Proton VPN under the default weighting:

provably between 6.88 and 8.88

The shaded band runs floor → potential; the tick is the headline. The clamp is not cosmetic: under the streaming weighting, a provider we hold no streaming evidence on renormalised to 9.9 against a provable maximum of 8.45. The headline holds it at the maximum instead of printing a number no provider could reach.

8 · Ranking is by dominance, not by headline

The only ordering the evidence licenses is this: A ranks above B when A's guaranteed minimum clears B's best possible maximum over everything we have not measured, floor(A) > potential(B). It is a strict partial order, and crucially it cannot be moved by the order in which we happen to research providers. A renormalised average could not say that.

The evidence currently separates at least one pair of providers.

There is no tiebreak. An earlier version ordered ties by how much of each provider we had researched; it has been deleted, because that promoted the providers we knew least about.

9 · What this does not fix, stated plainly

Dominance is not withholding-proof, and we will not claim it is. Deleting a whole dimension's evidence lowers the hider's floor and can never win it a rank. But deleting a single citation inside a normalized dimension can raise that dimension's value, because the divisor counts only the rules that had evidence. This is invariant 2 applied to a ratio: “absent data never lowers a score” becomes “absent data raises a ratio” the moment the denominator shrinks with it.

This is live in the current corpus, not a hypothetical. One provider scores a perfect 10 on additional features at 33% coverage: we sourced the three features it has, and its site returns an error to our fetcher for the pages that would have shown the ones it lacks. A missing page bought a perfect score.

Closing this requires the schema to tell “we looked, and the provider does not disclose”, a scored negative, cited to the page that fails to mention it, apart from “we have not looked,” which is our gap. Until then, the interval and the dominance rule close the renormalisation channel; they leave the citation channel open. The completeness gate closes it only at publication: a provider is publishable only when its scored dimensions have no unassessed gaps, so deleting a citation to inflate a score reopens a gap and blocks the page. That is a gate on what we publish, not a property of the arithmetic, and we would rather say so than overstate the guarantee.

Check our math

Everything above runs on one artifact. The same corpus that renders these pages is offered for download, so you can re-derive any headline, run it under a different weighting, or find the exact citation behind any deduction.

We take no affiliate commissions, sell no advertising, and have no commercial relationship with any VPN provider.