Privacy basics · Evaluation

How to read security claims before testing a privacy app

Distinguish open source, automated tests, real-device checks and independent audits before deciding what a privacy tool can be trusted to do.

By V · Published 23 October 2026 · Updated 6 November 2026 · Experimental project notes

Experimental beta. Use non-sensitive test data. Real-phone validation and independent security review are incomplete. Do not rely on these tools for sensitive communications. See what still blocks a wider launch.

A privacy tool should explain its boundaries as clearly as its features. Before trying one, identify what you want to protect, from whom, and what happens if the tool fails. For an experimental project, start with fictional data and a limited question.

Ask what the tool actually protects

Message encryption protects a particular message representation. A network filter changes which connections can pass. Neither automatically protects a compromised endpoint, hides all metadata or replaces safe device access. Define the task before comparing products.

Separate four kinds of evidence

  • Public source: enables inspection; it does not mean someone qualified has reviewed every line.
  • Automated tests: check specified cases under stated conditions; they cannot establish the absence of unknown vulnerabilities.
  • Real-device tests: show outcomes on particular devices and versions, not every operating system or configuration.
  • Independent audit: needs a named scope, date, findings and remediation status. An internal review is not independent.

Match the evidence to the task

Seeing an encrypted package on screen is different from recovering a saved file. A package-format check is different from authenticating a sender. A successful share action is different from confirmed delivery. For each claim, ask which exact step was observed, on which version and device, and what still needs testing. The VVault file-reopening test gives a small example you can report as pass, fail or blocked.

Look for failure behaviour

Ask what happens when a password is wrong, a package is malformed, a connection fails or an app is interrupted. A safe failure should be understandable. Also ask whether old data remains in files, clipboard history or backups after the interface clears.

Read the current limits

For Vellivex, Our approach separates internal checks from outstanding real-phone validation and independent review. VVault has no sender authentication, recovery or forward secrecy. VRelay does not deliver messages through a hosted service. VGuard’s behaviour depends on Android’s VPN service; V Cipher’s physical two-phone workflow needs its own device evidence. Check the current release notes for the scope of each reported result.

Make feedback reproducible

Use a minimal fictional example, record the version and device/browser, and state the exact steps, expected outcome and actual result. Mark the task PASS, FAIL or BLOCKED, and keep the report confirmation reference. A private report is not a promise of anonymity. Keep vulnerability details private through the reporting route. Do not send real keys or private messages as evidence. Good evidence improves a project; absolute claims such as “impregnable” do not.


← All guides · Share test feedback ↗

Keep exploring