How to Choose a Privacy Service: What to Look At, Not the Marketing
There are hundreds of privacy services on the market, and nearly all of them promise the same thing — "fast, reliable, private." Which technical and organizational signs actually matter, and how can you check them yourself in 15–20 minutes without relying on the slogans on the homepage?
Why you need a privacy service at all
A privacy service (VPN) encrypts traffic between your device and the server you connect to. This closes off the most vulnerable segment of the path — the local network: a home router, a café with open Wi-Fi, a hotel or airport access point. The owner of such a network, or someone connected to the same one, can under certain conditions see or tamper with unencrypted traffic; a VPN makes the contents of the connection unreadable to intermediate nodes. For more on the risks of open networks and how to reduce them without a VPN, see our piece on protecting your data on public Wi-Fi.
A separate concern is the privacy of the connection itself to work or personal resources — for example, when an employee needs secure remote access to a company's internal services, rather than an open channel through the ISP.
The encryption protocol — where to start checking
A service's technical characteristics are defined first and foremost by the protocol it's built on. One of the modern benchmarks is WireGuard: according to the protocol's official specification, it implements a simplified variant of the Noise framework (Noise_IKpsk2_25519_ChaChaPoly_BLAKE2s), uses Curve25519 for key exchange, ChaCha20-Poly1305 as a single authenticated encryption scheme, and BLAKE2s for hashing. An important detail: the protocol doesn't support negotiating algorithms "on the fly" — the set of cryptographic primitives is fixed, which simplifies independent code audits compared to protocols where the cipher is chosen dynamically.
A compact codebase (WireGuard's is an order of magnitude smaller than classic protocols) isn't a marketing detail — it's a practical advantage: less code to check for bugs, and a smaller attack surface. AmneziaWG and similar implementations are forks of the same protocol, tuned for specific use cases, but their cryptographic foundation is shared.
What to ask a service before you pay
- Which protocol is used by default, and can you switch to an alternative.
- Does the developer publish the source code of the client apps — open code can be checked, closed code has to be taken on trust.
- Has the service gone through an independent technical audit, and is a report published, even in abbreviated form.
Logging policy and jurisdiction
"No logs" is a phrase almost everyone writes, but it means different things for different services. Worth distinguishing: connection logs (time, traffic volume, source IP) and activity logs (which addresses were visited). The absence of the latter is the minimum bar for trust, but even that needs to be checked against the specific wording of the privacy policy, not a homepage slogan. A good sign is when the policy directly lists which technical data is collected to run the service (for example, to calculate billing) and explicitly excludes traffic content and browsing history. A vague or entirely absent public policy is reason for caution, regardless of anything else. For an example of specific, non-promotional wording, see our privacy policy and the security and protocols page.
Account and password — basic hygiene that's often skipped
A strong channel-encryption protocol alone won't help if the account in the service's dashboard is compromised through a weak password. The current NIST digital identity guidelines (SP 800-63B) explicitly shift the focus from password complexity to password length: for single-factor authentication, a minimum of 15 characters is recommended, and organizations should not impose mandatory rules like "must include a digit and a special character" — they don't meaningfully improve strength and make it harder for users to remember the password. The standard also no longer requires forced periodic password changes absent signs of compromise.
The practical takeaway: a long passphrase generated and stored in a password manager is stronger than a short "complex" password held in your head. Choosing the manager itself is a separate topic, covered in our piece on choosing a reliable password manager. Where possible, you should also enable two-factor authentication for the service's dashboard — a separate barrier, unrelated to the traffic-encryption protocol.
Kill switch and behavior on disconnect
The tunnel drops for every service at some point — when switching networks, when a phone goes to sleep, when a server is overloaded. The question is what happens at that moment: if the app simply falls back to a regular connection without warning, traffic briefly goes out unencrypted, directly. A kill switch blocks all traffic until the tunnel is restored — worth checking in the app settings before you rely on the service for anything sensitive, not after.
Devices, platforms and real-world speed
A hands-on test matters more than the list of supported platforms on the website: install the app on the device you'll actually use (phone, laptop), and evaluate connection stability over several days of ordinary use, not a five-minute test run. The difference in latency and speed between lightweight protocols like WireGuard and older, heavier implementations is usually most noticeable on mobile networks with an unstable signal — thanks to fewer handshake checks and lower CPU load on the device.
If a service offers a trial period, that's a good way to check everything above on your own terms rather than from the website description. HamikVPN, for example, uses a WireGuard-based protocol and offers trial access through signing up in the dashboard, so you can evaluate connection stability on your own device before paying for a plan.
Checklist: what to check in 15 minutes before choosing
- Open the protocol page on the service's website — is a specific protocol named (WireGuard and its derivatives are a good benchmark), or is the wording vague?
- Read the privacy policy in full and find the section on logs — not a paragraph of general phrases, but a specific list of what isn't collected.
- Check for a kill switch in the app settings and turn it on manually if it's off by default.
- Set a long, unique password for your dashboard using a password manager, and enable two-factor authentication if it's available.
- Test the app on a real device over several days, rather than judging by a single speed measurement.
- Check current pricing and payment terms — for example, on the pricing page — before paying for a long period.
- Check whether the device you actually use most often is supported — for Android, do this via the app download page.
Bottom line
No single item on this list replaces the others: an open protocol without a clear logging policy doesn't give the full picture, and a fair policy paired with weak cryptography is also a half-measure. The combination of verifiable technical details — protocol, data policy, disconnect behavior, real-world performance on your own device — is more reliable than any promise on a homepage. For more on digital hygiene and privacy, see the articles section.