SC Privacy Desk judges messaging apps, email services, VPNs and browsers on evidence a reader can check: what the encryption protects, who has audited it, what the company keeps, and who can compel it to hand data over. This page explains the criteria we use, how we source breach and privacy news, what we refuse to cover, and how we fix mistakes.
The short version
- We judge tools on published, verifiable evidence. Marketing claims count for very little.
- We care about what a tool protects, what it leaves exposed, and who sees the gap.
- Breach and privacy news comes from official notices, regulators, court and corporate filings, and credible reporting. Anything unconfirmed is labelled that way.
- We do not cover hacking tools, stolen data, or ways to break the law.
- When we get something wrong, we correct it openly.
What we base our evaluations on
We are a new, independent site. We do not claim to have run lab tests on every product or held long-term paid accounts with each service we discuss. Our evaluations rely on material anyone can inspect:
- Published security whitepapers and protocol documentation
- Public source code repositories and their commit history
- Independent audit reports, including their scope and dates
- Privacy policies, terms of service and data retention statements
- Transparency reports and warrant canaries
- Court records, regulatory decisions and public filings involving the company
- Reporting from established security researchers and news outlets
If we describe how a feature works, it comes from these sources. We say so when documentation is thin or contradictory, and we treat a lack of documentation as a finding in itself.
The criteria we apply to every tool
Encryption, and what it actually covers
“Encrypted” can mean very different things. We look at what kind of encryption is used and how far it reaches:
- Encryption in transit protects data on its way to a server, but the provider can still read it once it arrives.
- End-to-end encryption means only the people communicating hold the keys. The provider relays data it cannot read.
- Zero-access or client-side encryption for stored data means the provider holds files or mail it cannot decrypt.
Then we ask the follow-up questions that marketing pages tend to skip. Is end-to-end encryption on by default or hidden in a setting? Does it cover group chats, backups, attachments and voice calls, or only one-to-one text? Are cloud backups encrypted with a key the user controls? What metadata stays visible: who you talk to, when, how often, from which IP address?
Metadata gets a lot of weight from us. A service can encrypt message content perfectly and still record a detailed map of someone’s relationships.
We also favour established, publicly reviewed protocols over custom cryptography. A home-grown scheme that has never been examined by outside cryptographers is a risk, however confident the vendor sounds.
Independent audits
A security audit is only as useful as its scope. When a company says it has been audited, we look for:
- Who did it. A recognised independent security firm or academic team, not the vendor’s own staff.
- What was tested. The client apps, the server infrastructure, the cryptographic design, or a privacy policy check. “No-logs audits” of VPNs usually review configurations and processes at a point in time. They do not prove what happens every day afterwards.
- When. An audit from several years and many major versions ago tells you little about today’s code.
- Whether the report is public. A full report, or at least a detailed summary listing findings and fixes, counts for far more than a press release saying an audit happened.
Repeated audits over time are a stronger signal than one well-publicised review.
Open source code
Open source code lets outside experts check whether an app does what it claims. We note whether the client apps, the server software, or both are published, and under what licence.
Open source is not a guarantee. Code that nobody reviews offers little protection, and you usually cannot confirm that a company’s servers run the code it published. Reproducible builds, which let anyone confirm that the app in the store matches the public source, are a meaningful plus. Closed-source tools are not ruled out automatically, but they need stronger audit evidence to earn the same confidence.
Logging and data retention
We read the privacy policy and the terms of service in full. The marketing page is not enough. We look for:
- What is collected: IP addresses, connection timestamps, device identifiers, payment details, contact lists, usage analytics
- How long each category is kept
- Whether data is shared with third parties, including analytics and advertising partners
- Whether “no logs” is defined precisely or left vague
Real-world evidence matters most. Court cases, police requests and server seizures sometimes show what a provider could actually hand over. A no-logs claim tested by a legal demand outweighs one that has only ever appeared in an ad.
Jurisdiction and legal exposure
Where a company is incorporated and where its servers sit decide which laws can force it to collect or disclose data. We consider:
- Data retention laws that may require logging
- Surveillance and lawful-access powers, including secret orders and gag provisions
- Membership of intelligence-sharing arrangements such as the Five Eyes alliance
- Strength of data protection rules and the courts that enforce them
Jurisdiction is one factor among several. Good encryption design limits what any government can obtain, wherever the company is based. A provider in a privacy-friendly country that stores everything in readable form can still be a poor choice.
Business model
Running servers costs money, so someone always pays. We look at how a tool earns its income:
- Paid subscriptions, where the user is the customer
- Donations or non-profit foundations
- Freemium plans that subsidise free users
- Advertising, data monetisation or opaque funding
Free services that do not explain how they survive get extra scrutiny, especially free VPNs. We also note ownership, including parent companies and acquisitions. A change of owner can change a product’s privacy posture overnight.
Transparency reports and legal process
We check whether a company publishes regular transparency reports showing how many government and legal requests it received and how it responded. We also check whether it has a published policy for handling those requests and whether it notifies users when the law allows. Regular, detailed reports count in a company’s favour. A report that stopped appearing without explanation counts against it.
How the criteria apply by category
Each tool type has its own weak points, so the emphasis shifts.
| Category | What we weigh most heavily |
|---|---|
| Messaging apps | End-to-end encryption by default, group and backup coverage, metadata collection, phone number requirements, open protocol and client code |
| Email services | Zero-access storage, end-to-end encryption between users and with outside providers, what stays unencrypted (subject lines, headers), retention, account recovery design |
| VPNs | Tested no-logs claims, audit scope and dates, jurisdiction, ownership, leak protection, payment and sign-up data required |
| Browsers | Default tracking protection, fingerprinting resistance, telemetry and what it sends, update speed for security fixes, extension risks |
Messaging apps
The questions we ask most often: Can the provider read messages? What does it know about who talks to whom? Does sign-up need a phone number, and is that number visible to contacts? Are backups protected as strongly as live chats?
Email services
Email was never designed for privacy. Even with strong encryption at rest, mail sent to someone on a standard provider usually travels without end-to-end protection, and headers stay readable. We explain those limits plainly so readers know what a “private” inbox can and cannot do.
VPNs
A VPN moves trust from your internet provider to the VPN company. It does not make anyone anonymous. We judge VPNs mainly on whether that trust is earned: independent verification of logging claims, clear ownership, and honest marketing. Services that promise “complete anonymity” lose points for overclaiming.
Browsers
We look at what a browser blocks by default, since most people never change settings. We also look at what it sends back to its developer, and how quickly security patches arrive. Privacy features matter little if the browser falls behind on fixes.
Web3 privacy: extra caution
Public blockchains are permanent and, by default, transparent. When we cover Web3 privacy, we focus on what is exposed on-chain, how wallet activity can be linked to real identities, and what privacy-preserving designs exist.
We do not recommend, promote or name prices for crypto tokens or coins. We do not publish price predictions. We do not cover services designed to launder funds or evade sanctions. Coverage of privacy technology in this space stays educational and focuses on users’ own data.
How we weigh the evidence
No tool scores perfectly on everything, so we explain trade-offs instead of giving a single number. These raise our confidence:
- Strong encryption on by default, covering metadata where possible
- Recent, public, well-scoped independent audits
- Open source code with an active review community
- Claims that have survived legal requests or seizures
- Clear policies written in plain language
These lower it:
- Vague or shifting privacy policies
- Undisclosed ownership or unexplained funding
- Marketing that overstates protection, such as “100% anonymous” or “unhackable”
- Security incidents handled with silence or denial
- Long gaps in updates or audits
How we source breach and privacy news
Where our information comes from
We build news coverage from the most authoritative source available, roughly in this order:
- Official notices from the affected organisation: breach notification letters, security advisories and incident statements.
- Regulators and government bodies. Examples include EU data protection authorities, which must be notified of qualifying personal data breaches within 72 hours under the GDPR, the US Department of Health and Human Services breach portal for health data incidents, and state attorney general notification filings.
- Corporate and court filings. These include US Securities and Exchange Commission disclosures of material cybersecurity incidents, lawsuits and regulatory decisions.
- Credible reporting from established news outlets and recognised security researchers with a record of accurate work.
How we label claims
We tell readers how solid a claim is in the text itself, using clear wording that matches the evidence:
- Confirmed: the organisation or a regulator has acknowledged it.
- Reported: an established outlet or proven researcher has published it with evidence, but the company has not confirmed it.
- Claimed: it comes from a threat actor, an anonymous source, or a forum post, with no independent verification yet.
- Disputed: the company or other credible sources deny it.
Attackers often exaggerate how much data they hold, and early figures change as investigations go on. We update stories as facts firm up and say what has changed.
What we will not publish from breaches
We never link to, host, or explain how to find leaked databases or stolen files. We do not publish personal details of people affected. We will not speculate about the identity of anonymous attackers or leakers. Our focus is what happened, who is affected, and what readers should do to protect themselves.
What we never cover
SC Privacy Desk is about protecting your own privacy within the law. We do not publish:
- Hacking tools, exploit kits, malware, or step-by-step intrusion guides
- Ways to access accounts, devices or networks that are not yours
- Methods for evading law enforcement, sanctions, court orders or lawful investigations
- Doxxing techniques or ways to identify or track private individuals
Privacy and anonymity are legitimate needs for journalists, activists, abuse survivors and ordinary people. Tutorials for committing crimes are not, and we keep the two clearly separate.
Independence
We are an independent site and do not accept payment in exchange for favourable coverage. If we ever use affiliate links, sponsorships or any other commercial arrangement, we will disclose it clearly on the relevant page. A commercial relationship will never change how a tool is assessed against the criteria above.
Keeping evaluations current
Privacy tools change fast. Policies get rewritten, companies get acquired, audits age, and new vulnerabilities appear. We revisit evaluations when something material changes, such as a new audit, a policy update, a security incident, an ownership change or a significant legal case. Pages show when they were last updated so readers can judge how fresh the information is.
Corrections
We aim to be accurate, and we will sometimes fall short. When we find or are told about an error:
- We check the claim against the original sources.
- We fix factual errors promptly.
- For anything beyond a typo, we add a note to the page explaining what was corrected and when.
- We do not quietly rewrite past claims to hide mistakes.
If you spot an error, an outdated policy, or a claim that needs a better source, please contact us through the options listed on this site. Companies whose products we cover are welcome to send documentation that supports a correction. We weigh it by the same standards as any other evidence.