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
- Freeze the product version, platform build, test date, account state, network, and test environment before execution.
- Record expected behavior, actual behavior, raw evidence, severity, retest status, and reviewer for every test case.
- Treat “not reproduced” as a bounded observation, never proof that a vulnerability cannot exist.
- Test normal use, failure states, adversarial requests, network transitions, and regression after remediation.
- Keep provider statements separate from our measurements; a claim cannot replace a test result.
- 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.
| Area | Required coverage |
|---|---|
| Platforms | iOS, Android, macOS, Windows, Linux, TV clients, and web dashboard where offered |
| Networks | Wi-Fi, mobile data, IPv4, IPv6, network loss, network switching, captive or restricted conditions where available |
| Connection states | First connect, reconnect, server switch, sleep/wake, app restart, process termination, logout, expired session |
| Tunnel modes | Full tunnel, split tunnel, application and domain exclusions, automatic routing |
| Accounts | Valid, invalid, expired, logged-out, cross-device, and unauthorized request states |
| Builds | Production 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 templates2 · 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.
| Dimension | Sourced as | Ceiling | Default | Top10VPN parity |
|---|---|---|---|---|
Privacy Logging policy, jurisdiction, ownership, read from policies and filings. | Documented | 10 | 24% | 20% |
Security Protocols, kill switch, cipher choices, read from docs and source. | Documented | 10 | 18% | 15% |
Transparency Published audits, canaries, open-source clients. | Documented | 10 | 12% | , |
Server authenticity Latency triangulation from our own probe network, the dataset we will own. | Measured | 10 | 10% | , |
Server locations Counts are the provider's claim; server authenticity is what checks them. | Vendor-claimed | 10 | 7% | 10% |
Streaming A marketing page listing every service on earth. We run no unblock suite. | Vendor-claimed | ≤ 6.5 | 7% | 15% |
Speed Third-party measurements. We did not produce them, so they cannot top the scale. | Documented | ≤ 8.5 | 7% | 15% |
Device compatibility Platforms and app listings, read directly. | Documented | 10 | 5% | 5% |
Usability Setup and interface, read from docs and store listings. | Documented | 10 | 4% | 10% |
Torrenting Port forwarding, kill-switch behaviour, P2P policy from the docs. | Documented | 10 | 3% | 5% |
Additional features Split tunnelling, multi-hop, ad blocking, present or absent, per the docs. | Documented | 10 | 3% | 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.
| Model | How the rules combine | Used by |
|---|---|---|
| Absolute | Start 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 |
| Normalized | Points 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 |
| Composite | A 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.
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.
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.
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.