How STACK evaluates privacy and security products
Privacy and security products make claims that are often difficult for users to verify directly.
A provider can say it keeps no logs. A company can publish an audit. A product page can list advanced security features. A corporate website can explain who owns the business.
Those things can all be useful evidence.
But they are not automatically the whole answer.
STACK uses an evidence-first research methodology designed to establish what the available record actually supports, where the limits of that evidence sit, and what those findings mean for the person making a decision.
We do not begin with a preferred conclusion and search backward for evidence to support it.
We start with the question
Different investigations require different kinds of evidence.
A question about ownership is not the same as a question about privacy.
A privacy investigation is not the same as a security assessment.
A feature being available does not tell you whether it is useful.
And a product being technically capable does not automatically make it worth paying for.
That is why STACK begins by defining the decision being investigated.
Our research may ask:
- Who owns and controls this company?
- What information does the service collect?
- How is user data handled?
- What security controls are documented?
- What have independent assessments actually examined?
- Which features are available, and where?
- What does the product cost?
- What changes when a subscription renews or account time is extended?
- What important limitations exist?
- How does one product compare with another?
- Which trade-offs actually matter to the buyer?
Keeping the question clear helps prevent evidence from being used to prove something it was never capable of proving.
We prioritize the strongest available evidence
STACK research draws from a range of public sources.
Depending on the investigation, these may include:
- corporate and registry records;
- legal and regulatory documents;
- published audit and assurance reports;
- technical documentation;
- product and support documentation;
- privacy policies and terms;
- source repositories;
- transparency reports;
- security disclosures;
- direct product or checkout observations;
- app-store information;
- reputable independent technical testing;
- specialist security research;
- credible reporting.
We prefer original and primary material where it is available.
But source quality is not determined simply by whether something comes directly from the company.
A provider may be the best source for confirming that a feature currently exists.
That same provider is not an independent source for proving a broad claim about its own privacy or security.
The value of a source depends on the question being asked.
We distinguish claims from verification
One of the most important principles in STACK research is simple:
A company saying something is true is not the same as that thing being independently verified.
Provider documentation remains valuable evidence.
We simply describe it for what it is.
Where stronger external evidence exists, we use it.
Where it does not, we preserve the distinction.
That means readers may see language such as:
- provider-stated;
- independently supported;
- independently verified within a defined scope;
- historically established;
- conflicting;
- unresolved.
Those distinctions are intentional.
They help show how much confidence the available evidence actually supports.
We respect the scope of evidence
Evidence is strongest when its limits are clear.
For example, the existence of an audit does not necessarily mean that:
- every part of a service was examined;
- every application was tested;
- every privacy claim was reviewed;
- no vulnerabilities were found;
- all findings were independently confirmed as fixed;
- the conclusions still apply unchanged years later.
When using audits and technical assessments, we pay attention to factors such as:
- what was examined;
- when the work took place;
- which product or system was included;
- which version was tested;
- what was excluded;
- what findings were reported;
- whether remediation was documented.
The same principle applies elsewhere.
- A feature documented on one platform does not automatically exist on every platform.
- A historical speed test does not establish current performance.
- A corporate parent does not automatically establish every detail of operational control.
- A privacy policy establishes what the policy says. It does not, by itself, independently prove every underlying technical behavior.
- A source can establish only what it actually demonstrates.
We challenge important findings
Research is not treated as correct simply because a source exists or because a claim initially appears plausible.
Important findings are checked for problems such as:
- unsupported conclusions;
- contradictory documentation;
- outdated information;
- claims that exceed the scope of their evidence;
- differences between product platforms;
- differences between current and historical information;
- provider assertions being mistaken for independent verification;
- gaps that materially affect the reader’s decision.
Where a contradiction matters, we investigate it further where reliable public evidence allows.
Where it cannot be resolved, we say so.
We preserve uncertainty
Not every research question has a clean public answer. That is particularly common in privacy and security research.
- Ownership structures may be only partially visible.
- Technical documentation may not describe every operational control.
- An audit may exclude an important backend system.
- Independent testing may conflict.
- A provider may change a feature without fully updating its documentation.
When the available evidence stops short of certainty, STACK does not quietly bridge the gap with assumption.
We preserve the uncertainty. An unresolved question is not evidence that a claim is false. It means we do not currently have enough evidence to state that it is true with greater confidence.
That difference matters.
We separate current evidence from historical evidence
Privacy and security products change continuously.
- Features are introduced and removed.
- Prices change.
- Apps gain and lose capabilities.
- Ownership structures change.
- Audits become outdated.
- Security incidents occur.
- Infrastructure evolves.
For that reason, STACK distinguishes between what is true now and what was true at an earlier point in time.
Historical evidence can still be important.
It may reveal:
- past incidents;
- previous product behavior;
- how a policy changed;
- how long a problem existed;
- whether a provider responded to an issue.
But historical evidence should not automatically be presented as a current product fact.
Our investigations use research cut-off dates where appropriate so readers can understand the period the evidence describes.
We separate privacy, security, ownership and product capability
These concepts overlap, but they are not interchangeable.
Privacy
Privacy research focuses on questions such as:
- what information exists;
- how it may be linked;
- how long it persists;
- which parties may receive it;
- how easily activity can be connected to an identity.
Security
Security research looks more closely at:
- technical protections;
- infrastructure;
- authentication;
- access controls;
- software design;
- vulnerability history;
- containment and failure resistance;
- independent technical assessment.
Ownership and governance
Ownership research considers:
- operating entities;
- parent companies;
- ownership structure;
- jurisdiction;
- governance;
- control;
- documented corporate relationships.
Product capability
Product research examines:
- what the service actually includes;
- platform differences;
- technical limitations;
- commercial restrictions;
- plan entitlements;
- current availability.
A strong result in one area does not automatically compensate for weakness or uncertainty in another.
We interpret evidence only after establishing it
Research and judgment are separate jobs.
STACK first asks:
What can we establish?
Only then do we ask:
What does it mean?
That distinction is important because the same fact can matter very differently depending on the decision.
For example:
A five-device limit is not inherently good or bad.
It matters if the intended setup requires more than five devices. The absence of port forwarding is not automatically a reason to reject a VPN. It matters if the intended use depends on inbound connectivity.
An advanced privacy feature is not automatically valuable simply because it is technically sophisticated. Its value depends on whether it addresses a problem relevant to the user.
STACK conclusions therefore focus on trade-offs and decision relevance rather than simply counting features or weaknesses.
We do not require every investigation to produce a universal winner
Some decisions have a clear answer.
Others do not.
A product may be stronger for one use case and weaker for another. A comparison may reveal that two services make fundamentally different trade-offs rather than one being universally superior. A product may offer excellent capabilities while still being a poor fit for someone whose requirements fall outside those capabilities.
We treat conditional conclusions as legitimate conclusions.
The goal is not to manufacture a winner. The goal is to make the decision clearer.
Search intent does not determine the evidence
People find STACK because they are trying to answer specific questions.
That means search intent matters to how we organize and explain our research. It does not control the underlying conclusion.
We do not change an evidence-based finding because a simpler answer would make a better headline. We do not force a binary verdict when the evidence supports a conditional one. And we do not omit material uncertainty simply because it makes the answer less convenient.
The investigation comes first. Presentation comes afterward.
We revisit material changes
Privacy and security research has a shelf life.
New information can materially change an earlier conclusion.
That may include:
- ownership changes;
- new audits;
- security incidents;
- product redesigns;
- major pricing changes;
- policy revisions;
- platform changes;
- discontinued capabilities;
- newly available evidence.
Where a material change affects an existing investigation, we aim to update the relevant coverage.
We distinguish between:
- a correction, where something previously published was wrong;
- an update, where the underlying facts changed;
- a clarification, where wording needs additional precision.
You can read more in our Corrections & Updates policy.
What our methodology does not claim
No public research methodology can make every private system fully observable.
STACK does not claim to independently verify every operational detail of every company we cover.
We do not claim that an audit proves everything about a product.
We do not claim that publicly available corporate information reveals every aspect of control.
And we do not claim certainty where reliable evidence does not support it.
Our job is narrower, and more useful:
Establish the strongest defensible account of the available evidence, preserve its limits, and turn it into a decision a reader can actually use.
That is the standard behind every STACK investigation.