How I Test

Preventive Privacy publishes two kinds of writing, and they're held to two different standards. Most pieces are hands-on reviews, where I actually install and live with a product instead of rewriting a vendor's feature list - that means I will always use the product and provide real, hands-on experience to you. The rest are explainers, deeper pieces that take apart how something works, like how a VPN routes your traffic under the hood or why a particular breach happened at the protocol level, not just the headline level. This is something that I am highly passionate about and I do sincerely hope that I can rely the earned knowledge to you. This page covers how both are done: the machines and test cases behind the reviews, the sourcing standard behind the explainers, what counts as a pass or a fail, and how money never decides a verdict. If anything I publish contradicts what's written here, the article is wrong and I want to know about it, feel free to reach out to me anytime!

I'm a software engineer by day, six-plus years as a Java backend developer building production systems in fintech, retail, and online gaming. That background is the reason this site exists and the reason the work goes deeper than "I clicked around for ten minutes." I can read a TLS handshake, a privacy policy, or a CVE writeup and tell you what it actually means. I bring that same habit to both jobs: with a product, I take it apart and find what works and what doesn't; with a topic, I dig until I understand it well enough to explain it plainly.

The short version

• I test on two real machines I use every day, plus disposable virtual machines for anything risky.
• Every test is dated and pinned to a specific product version and OS build.
• I hunt down the loudest real-world complaints about a product and try to reproduce them myself.
• Explainers are built on primary sources - RFCs, CVE entries, vendor security advisories, and I'm clear about what I verified myself versus what I'm summarizing.
• A product is judged only on how it performs. Affiliate payouts never touch the verdict, and the best-paying product on the market gets panned here if it earns it.
• If I haven't tested something, or can't verify a claim, I say so. I never describe behavior I didn't see or assert something I couldn't source.

My test environment

I run everything across two physical machines and disposable VMs.

Windows machine. Windows 11 (I note the exact build in each review, since antivirus and security behavior changes between Windows feature updates). This is also a daily-use machine, which matters: it's where I notice the system-tray nagging, the boot-time slowdown, and the upsell popups that only show up after a week, not in a fresh ten-minute trial.

Linux machine. Ubuntu. Used for tools with Linux clients, for cross-platform sync testing, and for network-level checks where I want a clean, scriptable environment.

Disposable virtual machines. For anything I don't want touching a real machine, I use VirtualBox VMs with a clean snapshot taken before each test. I revert to the snapshot between runs so every test starts from a known-good state. I use these for:

• Installing antivirus and security suites from scratch, so I can measure install friction and uninstall cleanliness without polluting my daily setup.
• Anything involving suspicious files, test malware, or detection checks.
• Reproducing a reader's or forum-reported problem in a controlled way.

The split is deliberate. The daily-driver machines capture the lived-in experience that a trial never shows you. The snapshot VMs capture the clean-slate behavior (first install, first scan, full uninstall) that you can't measure honestly once a machine is already cluttered.

What I actually check, by category

The specifics differ per product type. Here's the core checklist I work through for the main categories I cover.

Antivirus and security suites

• Install friction. How long it takes, what it tries to bundle, whether it forces a reboot, whether it nags for an account or upsell before it'll protect you.
• Detection. I use the EICAR standard anti-malware test file (a harmless industry-standard file every engine is supposed to flag) to confirm real-time protection actually fires, and I watch how the product reacts and what it tells the user.
• Quarantine and recovery. What the quarantine flow looks like, whether I can restore a file, and whether it's clear or confusing.
• False positives. I keep a small set of legitimate developer tools and scripts that less mature engines sometimes flag, and I check whether the product cries wolf on safe software.
• Performance cost. Boot-time impact and CPU/RAM use during a full scan, measured on the same machine with and without the product installed.
• Uninstall cleanliness. After removal, I check for leftover files, services, and registry entries. Security software that won't fully leave is a real mark against it.
• The week-later test. Nagging, popups, dark-pattern renewal pricing, and upsells that only appear once you've settled in.

Password managers

• Account setup and the master-password / recovery flow (including what happens if you lose the master password).
• Importing from a browser or another manager, and how much breaks in the process.
• Autofill reliability across Firefox and Chrome, on both desktop and mobile.
• Sync speed and correctness across devices and platforms.
• Password generator behavior and any breach/health reporting it offers, cross-checked against reality.
• Export: can you get your data out, and in what format. Lock-in is a downgrade.

VPNs

• Connection time and stability across several servers.
• Real speed: I run the same speed test on the same connection before and after connecting, to multiple server locations, and report the actual delta rather than the vendor's claim.
• DNS and IP leak checks using standard leak-test tools, with the VPN connected, to confirm traffic isn't leaking outside the tunnel.
• Kill switch: I force-drop the connection and verify the kill switch actually cuts traffic instead of silently failing open.
• A plain-language read of the logging and jurisdiction claims, including what a "no-logs" policy does and doesn't promise.

Identity protection and breach tools

• What the tool actually checks, not what the marketing implies. I cross-reference breach findings against Have I Been Pwned and known public breach data.
• Alert latency: how fast it tells you about something it should have caught.
• Dashboard clarity and whether the recommended actions are genuinely useful or just filler.

Verifying real-world complaints

Marketing tells you what a product wants you to believe. Angry users tell you where it actually breaks. Before and during a review I read through Reddit threads, vendor support forums, and app-store reviews to find the loudest recurring complaints about a product, then I try to reproduce them myself.

When I test a reported problem, I record whether I could reproduce it, on which OS and version, and under what conditions. Sometimes the complaint is real and current. Sometimes it was fixed two versions ago. Sometimes it only happens in a specific setup. I'll tell you which, instead of repeating a forum rumor as fact. If I can't reproduce something, that goes in the review too.

What counts as a pass or a fail

I grade against what the product promises to do, not against perfection. Three outcomes:

• Pass. The core promised function works reliably across repeated runs, with no dealbreakers. Minor annoyances are noted but don't sink a pass.
• Conditional. It works, but with a meaningful caveat: only on one platform, only after a workaround, or with a flaw you need to know about going in. I'll spell out the condition.
• Fail. The core function is unreliable, a security claim doesn't hold up under testing (a VPN that leaks, a kill switch that fails open, an antivirus that misses the EICAR file), or the product does something user-hostile enough to outweigh what it does well.

A few concrete examples of what tips something into a fail: a "no-logs" VPN whose kill switch leaks your real IP when the connection drops; a password manager you can't export your own data out of; an antivirus that leaves running services behind after you uninstall it. These aren't nitpicks. They're the difference between a tool protecting you and a tool you only think is protecting you.

How I research the explainers

Not everything here is a product review. A good chunk of the site is explainers: pieces where I pick something I want to understand properly, spend a few weekends on it, then write the version I wish someone had handed me. There's no product to install, so "firsthand testing" doesn't apply the same way. These pieces get held to a different standard instead.

• Primary sources over secondary summaries. I go to the source that actually defines the thing: the RFC for a protocol, the official CVE and vendor advisory for a vulnerability, the spec or the security whitepaper rather than a third party's recap of it. When I cite a claim, I link the source so you can check it yourself.
• I separate what I verified from what I'm summarizing. If I tested something to confirm it for the piece, I'll say so and show it. If I'm explaining something I'm confident about but didn't reproduce, I'll frame it as that rather than dressing a summary up as a demonstration.
• I verify by doing, where it's practical. A lot of security topics can be confirmed on my own machines rather than taken on faith. If I'm explaining how a VPN can leak DNS, I'll actually capture it leaking and show the result. If I'm explaining a handshake, I'll watch the real packets. That hands-on habit is the same one behind the reviews, just pointed at a concept instead of a product.
• Diagrams are mine. Where a drawing explains it better than a paragraph, I make the diagram myself to match the specific point, rather than lifting a generic one. If a diagram simplifies something, I say what it's leaving out.
• Plain language, no hand-waving. The goal is that you finish the piece actually understanding the mechanism, not just trusting that I do. If I can't explain a step clearly, that usually means I don't understand it well enough yet, and the piece waits until I do.
• AI-assisted, but a person does the thinking. I'll be upfront: I use AI in writing these, the way I'd use a search engine or a rubber duck, to find sources faster, pressure-test an explanation, or tighten a rough draft. What it doesn't do is the part that matters. The verification, the understanding, and the opinions are mine, and I don't publish a sentence I couldn't defend or an explanation I don't actually understand. The line isn't whether a tool was involved, it's whether a real person actually worked the problem. If a piece reads like it could've been generated by someone who never did, it isn't worth publishing.

When an explainer gets something wrong, I correct it in place and note what changed. These pieces are the ones I most want to get right, because they're the ones people learn from.

How money is kept out of the verdict

This is the part most review sites are vague about, so I'll be specific.

• Testing comes first, money second. I run the tests and lock my notes and verdict before any affiliate decision is made. The verdict is written against the evidence, then I check whether an affiliate program even exists.
• Payout never changes the score. A product that pays me nothing can absolutely win a recommendation. A product with the most generous affiliate payout in its category can absolutely get panned. If the best-paying option is also the worst product, the review will say the worst product is the worst product.
• No vendor preview, no vendor edits. No company sees a review before it's published, and no company gets to request changes after. If a vendor disputes a finding with evidence, I'll re-test and correct the record publicly, but that's a correction, not an edit for their benefit.
• Affiliate links are marked and disclosed. Where a review links to a product I earn a commission from, that link is tagged as sponsored and disclosed both at the link and in the footer. The disclosure is there so you can weigh it. The testing above is there so you don't have to.
• Free licenses and trials. Most of what I test runs on free tiers or standard trials. If I ever use a vendor-provided license, I disclose it in that review, and it changes nothing about how the product is graded.

The simple rule: if removing every affiliate link from this site would change a single verdict, the site is broken. It won't, because the verdicts aren't for sale.

Versions, dates, and re-testing

Security software changes fast, and a review that doesn't tell you when it was written is half useless. So:

• Every review records the test date, the product version, and the OS build it was tested on.
• When a product ships a major version, I re-test the parts that matter and update the review with a fresh date.
• If something I recommended gets worse, the recommendation changes. These reviews are living documents, not monuments.

Found a problem with my testing?

If you've used a product I've reviewed and your experience doesn't match mine, I genuinely want to hear it. Reader reports are how I find the edge cases my own setup doesn't hit, and reproducing a reader's problem is one of the most useful tests I run. Send it over, tell me your OS and version, and I'll try to reproduce it.