How We Research

Everything on this site is desk research: public documents, read carefully, explained in plain language. This page is the method, so you can judge how much weight an article here deserves.

What counts as a source

In descending order of trust:

• Primary technical standards — the RFC, the NIST or ISO publication, the specification itself. If an article says TLS behaves a certain way, the standard is what it was checked against.
• Regulator publications — licence conditions, technical standards documents, public registers and enforcement notices from the body that issued the licence.
• Testing house documentation — the published scope of what a certification body tests, and the certificate register where one exists.
• The operator’s own documents — terms, privacy notice, security page. Treated as a claim by an interested party, never as verified fact.
• Reporting by named journalists at outlets that publish corrections. Used for events, not for technical claims.

Not sources: press releases repeated without checking, affiliate blogs, forum posts, and anything an AI tool asserts without a document behind it.

The line between checked and claimed

This is the rule that shapes most of the writing here. A claim about an operator’s security is either verifiable from outside the company or it is not, and the article has to say which.

Verifiable from outside: the certificate authority and protocol versions on a public endpoint, whether a licence appears on a regulator’s register and in what status, whether a testing house lists that operator’s certificate, what the published privacy notice commits to.

Not verifiable from outside: whether data is encrypted at rest, how keys are managed, who inside the company can read a verification document, how quickly a patch is applied, whether an internal audit finding was acted on. Where an article touches these, it says “the operator states”, not “the operator does”.

What we refuse to publish

• Security scores or grades. There is no honest way to compress a platform’s security posture into a number from public information, so we do not pretend otherwise.
• Named-operator vulnerability claims. We do not run scans or tests against anyone’s systems, and an untested assertion that a specific company is insecure is both wrong-headed and unfair.
• Statistics without a traceable origin. If a figure cannot be traced to the body that produced it, it does not go in.
• Invented credentials. No certifications, memberships, headcounts, founding dates or testing volumes are claimed for this site that do not exist.

Before an article goes live

1. Every factual claim is traced back to a document, and the document is opened — not the summary of it.
2. Technical terms are defined the first time they appear, because the reader we have in mind holds a casino account and does not work in security.
3. Anything that cannot be checked is reworded as an attributed claim or cut.
4. External links are opened to confirm they still resolve to what the article says they do.

Updates

Standards move and registers change. Articles that depend on a live document — a regulator’s technical standard, a certification scheme, a protocol’s deprecation status — get re-checked when we have reason to think the underlying document has changed, and the page shows the date it was last reviewed. Where an update alters the meaning of what was published, the change is noted on the page rather than made silently; the policy for that is Fixing Mistakes.

The commercial side of the site is kept away from the editorial side. What that means in practice is on Funding and Links.