Back to Documentation

Privacy & Security Whitepaper

Public Document • Documentation

Complete explanation of PVTLNK's zero-knowledge architecture and privacy protections

Related Document: Encryption Architecture Guide

Technical deep dive into our cryptographic implementation

🔒 PVTLNK Privacy & Security Whitepaper

Version 2.2 Last Updated: November 2nd 2025

Executive Summary

PVTLNK is a privacy-first URL shortener built on zero-knowledge architecture. This whitepaper explains how we achieve complete anonymity and world-class security without storing any personal data. Even we, the developers, cannot identify users or access their data.

Core Promise: Your identity, location, and activity remain completely private - protected by cryptography, not promises.

0.5 Key Terminology (Glossary)

To understand PVTLNK’s security, these terms are essential:

Term Definition Role in PVTLNK
Zero-Knowledge A system where one party can prove a piece of information is true to another, without revealing the information itself. Proves your password/username are correct without transmitting or storing them.
Commitment Hash The cryptographic output of your password + nonce, used to authenticate you. The single, un-reversible value stored on our server to verify your login.
Deterministic Nonce A “number used once” that is generated consistently (deterministically) from your hashed username. Ensures that your commitment hash is always the same when you log in, while preventing dictionary attacks.
Key Stretching (PBKDF2) A technique that intentionally slows down the hashing process (via 100,000+ iterations) to drastically increase the time and cost of a brute-force attack. Protects the commitment hash by slowing down any attempt to guess the underlying password.
SHA-256 A cryptographic hash function that converts any input into a unique, fixed-length 256-bit (64-character) output. Used to hash usernames (for nonce) and IP addresses (for anonymization). It is mathematically one-way.

1. How Zero-Knowledge Authentication Works

The Problem with Traditional Authentication

Traditional systems require trust:

  • You give them your email address
  • They store your password (hashed, but still tied to your email)
  • They can identify you and link your activity to your identity
  • If their database is breached, your email and account history are exposed

Our Solution: Commitment-Based Authentication

Important Clarification:

We ask for a username during signup (not an email address), and your username never leaves your browser and is never transmitted to our servers. We never store your username or your password. We never ask for or collect email addresses.

How It Works:

Step 1: Commitment Creation (Client-Side)

When you create an account, your browser creates a cryptographic commitment:

  1. You enter username and password in the signup form
  2. Username Hash: Your username is hashed client-side only using SHA-256 - this happens in your browser
  3. Nonce Generation: A deterministic nonce is generated from your username hash (ensures consistency for login)
  4. Commitment Generation: A commitment hash is created from your password + nonce using PBKDF2 (100k iterations, all in browser)
  5. Transmission: Only the commitment hash and nonce are sent to our server - your username never leaves your browser

Commitment Creation Process Flow

What We Receive:

  • ❌ NOT your username - it never leaves your browser
  • ❌ NOT your password - it never leaves your browser
  • ✅ 64-character hex string (commitment) - cannot be reversed to password
  • ✅ 64-character hex string (nonce) - cannot reveal your username

What Happens to Your Username:

  • ✅ Used only in your browser to generate nonce
  • ✅ Never transmitted to our servers
  • ✅ Never stored in our database
  • ✅ Exists only in browser memory during signup/login

Technical Detail (simplified):

Username → SHA-256(username) → Nonce Password + Nonce → PBKDF2(password + nonce, 100k iterations) → Commitment

Step 2: Authentication (No Password Transmission)

When you log in:

  1. Your browser recreates the commitment using the same process
  2. We compare the commitment hash you send with what’s stored
  3. If they match, you’re authenticated

Key Security Property:

  • Even if someone intercepts your signup/login request, they only see commitment hashes - they cannot determine your username or password
  • Your username exists only in your browser’s memory - it’s never transmitted or stored
  • This is why we can say “we never store your username” - it literally never reaches our servers

Why This Is Secure

Mathematical Security:

  • SHA-256 is a one-way function - mathematically impossible to reverse
  • There are 2^256 possible commitment hashes (more than atoms in the observable universe)
  • Even with quantum computers (theoretical), SHA-256 remains secure for decades

Practical Security:

  • No password in database: Traditional attacks don’t work
  • No username in database: No way to identify you
  • Brute force impossible: 2^256 possibilities with PBKDF2 key stretching (100k iterations)
  • Dictionary attacks useless: No password database to crack

2. Data We Do NOT Store

Verified: Zero Personal Identifiers

Data Type Stored? Why We Don’t Need It
Username ❌ NO Authentication uses commitments, not usernames
Email Address ❌ NO Never collected or stored
Password ❌ NO We store commitment hashes, not passwords
Name ❌ NO Not required for service functionality
Phone Number ❌ NO Not required for service functionality
Physical Address ❌ NO Not required for service functionality
Credit Card Numbers ❌ NO Stripe handles all payment data
Billing Address ❌ NO Stripe handles all payment data
Precise IP Address ❌ NO IPs are hashed with SHA-256 before storage
Device Identifiers ❌ NO User agents are anonymized

What We Actually Store

User Account:

  • commitment - 64-character hash (cannot be reversed)
  • nonce - 64-character hash (cannot reveal username)
  • anonymized_id - Generated identifier (e.g., user_123_a1b2c3d4)

Links:

  • Short codes and destination URLs
  • Expiration dates and click limits
  • No association with personal identifiers

Analytics (Privacy-First):

  • hashed_ip - SHA-256 hash of IP + server salt (cannot be reversed)
  • country - 2-character ISO code only (e.g., “US”, “CH”)
  • city - Filtered (set to null if unknown/invalid)
  • user_agent - Anonymized (browser/OS/device type only, no versions)

Payments:

  • stripe_customer_id - Stripe’s anonymous customer ID
  • stripe_subscription_id - Stripe’s subscription ID
  • No payment card details - Stripe handles all payment information

3. Can Traffic Be Intercepted?

Protection Against Traffic Interception

All traffic is encrypted with TLS 1.3 (the latest standard):

What TLS/SSL Protects

✅ Encryption in Transit:

  • All data between your browser and our server is encrypted
  • Intercepted traffic appears as random gibberish
  • Even if someone intercepts network traffic, they see only encrypted data

✅ Certificate Verification:

  • Your browser verifies our SSL certificate
  • Prevents man-in-the-middle (MITM) attacks
  • Warns you if certificate doesn’t match

✅ Perfect Forward Secrecy:

  • Each connection uses unique encryption keys
  • Compromising one connection doesn’t compromise others
  • Past traffic cannot be decrypted even if keys are compromised

What Even Intercepted Traffic Reveals

If someone intercepts your network traffic, they can see:

  • ✅ That you visited pvtlnk.com
  • ✅ The destination URL of your short link (when clicked)
  • ❌ NOT your username (never transmitted)
  • ❌ NOT your email address (we never ask for it)
  • ❌ NOT your password (never transmitted)
  • ❌ NOT your commitment hash (encrypted in TLS)
  • ❌ NOT your account activity (encrypted in TLS)

Example: If someone intercepts your signup request:

  • They see: Encrypted TLS data (random-looking bytes)
  • They don’t see: Your email, password, or any personal information
  • Even if they decrypt TLS: They only see a commitment hash (cannot be reversed)

Additional Protection: Timing Analysis Resistance

Even traffic analysis is limited:

  • ✅ All authentication uses the same endpoint (can’t distinguish users)
  • ✅ Commitment hashes are the same length (can’t identify users)
  • ✅ No unique identifiers in URLs or headers
  • ✅ Session tokens are random (cannot be linked across requests)

4. Can Accounts Be Reverse Engineered?

Reverse Engineering Protection

From Database Access

Scenario: Someone gains full access to our database.

What They See:

  • Commitment hashes (64-char hex strings)
  • Nonces (64-char hex strings)
  • Anonymized IDs (e.g., user_123_a1b2c3d4)
  • Hashed IPs (64-char hex strings)

What They Cannot Do:

  • ❌ Cannot determine your username - commitment hash cannot be reversed
  • ❌ Cannot determine your email - we never ask for it
  • ❌ Cannot determine your password - commitment hash cannot be reversed
  • ❌ Cannot link accounts to identities - no personal identifiers
  • ❌ Cannot reverse IP hashes - SHA-256 is one-way
  • ❌ Cannot identify you - all data is anonymous

Why It’s Impossible:

  • SHA-256 is mathematically one-way - reversing is computationally infeasible
  • 2^256 possible hashes - brute force would take longer than the universe’s lifetime
  • No rainbow tables possible - each hash is unique due to salting

From Code Analysis

Scenario: Someone analyzes our source code (open source or leaked).

What They Learn:

  • How commitment hashing works
  • Database schema (what columns exist)
  • API endpoints

What They Cannot Do:

  • ❌ Cannot reverse existing commitments - still requires 2^256 brute force
  • ❌ Cannot identify users - no personal data to match
  • ❌ Cannot decrypt past data - encryption keys are separate
  • ❌ Cannot create rainbow tables - IP hashing uses server-specific salt

Security by Design: Even with complete code knowledge, existing data remains secure.

5. Cryptographic Security Explained

SHA-256: Why It Cannot Be Reversed

SHA-256 is a cryptographic hash function designed to be one-way:

Properties:

  1. One-Way Function: Easy to compute hash, impossible to compute input from hash
  2. Avalanche Effect: Tiny input change = completely different output
  3. Deterministic: Same input always produces same output
  4. Collision Resistant: Practically impossible to find two inputs with same hash

Example:

``` Input: “hello” SHA-256: “2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824”

Input: “hello “ (one space added) SHA-256: “d9014c4624844aa5bac314773d6b689ad467fa4e1d1a50a1b8c99d47ef831bb3f” ```

Completely different outputs - no way to determine original from hash.

Security Level:

  • 256-bit security (2^256 possible outputs)
  • Even with a billion computers trying a billion hashes per second, it would take longer than the universe’s age to brute force

Salting: Protection Against Rainbow Tables

IP Hashing with Salt:

Without Salt (vulnerable):

IP: 203.0.113.42 Hash: SHA-256(203.0.113.42) = "a3f5b9c2..."

With Salt (secure):

IP: 203.0.113.42 Salt: Server secret key (unique per server) Hash: SHA-256("203.0.113.42_#{server_secret}") = "b7d2e8f1..."

Why Salt Matters:

  • ✅ Prevents rainbow table attacks (pre-computed hash tables)
  • ✅ Server-specific hashing (can’t compare across servers)
  • ✅ Even with hash, cannot reverse without salt (which is secret)
  • ✅ Same IP on different servers = different hash

Why Switzerland Matters

PVTLNK is hosted on Exoscale servers in Switzerland.

Swiss Federal Data Protection Act (FADP):

  • ✅ Strong data protection laws (similar to GDPR)
  • ✅ Requires explicit legal basis for data processing
  • ✅ Strong penalties for privacy violations
  • ✅ Independent supervisory authority

Switzerland vs. Other Jurisdictions:

  • ✅ Not part of Five Eyes - no automatic data sharing with surveillance alliances
  • ✅ No Cloud Act jurisdiction - US laws don’t automatically apply
  • ✅ Strong privacy culture - banking secrecy tradition extends to data protection
  • ✅ GDPR-equivalent - while not EU member, maintains equivalent standards

Benefits

  1. Stronger Legal Protections: - Swiss privacy laws among strongest in world - Data processing requires legal justification - Independent enforcement authority
  2. No Automatic Data Sharing: - No automatic sharing with foreign governments - Data requests must follow Swiss legal process - Strong judicial oversight
  3. Exoscale Credibility: - Swiss cloud provider (subject to Swiss law, not US Cloud Act) - Committed to GDPR and Swiss privacy compliance - Data stored in Switzerland = Swiss jurisdiction

Important Note: Swiss hosting provides legal protections, not absolute anonymity. Law enforcement can still request data with proper legal process per Swiss law. However, Swiss privacy laws are among the strongest globally.

7. Anonymous Payment Processing

How Payments Work Without Identity

Traditional systems:

  • Require email address (we don’t!)
  • Link payment to email (we don’t!)
  • Can identify you through payment records

Our system:

  • No email required
  • Anonymous Stripe customers
  • Payment linked only to anonymous identifiers

Stripe Integration

  1. Anonymous Customer Creation: - Stripe customer created without email address (we don’t have your email anyway!) - Description: “Anonymous customer for CommitmentUser {anonymized_id}” - Metadata contains only our anonymous identifiers
  2. Payment Card Handling: - Cards entered directly into Stripe’s secure form - Card numbers never reach our servers - We only receive Stripe customer ID (anonymous)
  3. What Stripe Knows: - Stripe may collect payment information per their Terms of Service - However, Stripe customers are not linked to email addresses in our system - Connection between payment and account exists only through anonymous identifiers

Result: Even if Stripe has payment data, it cannot be linked to your PVTLNK account identity because we don’t store your username, email, or any identifying information.

8. IP Address & Location Privacy

IP Anonymization Process

Step 1: Temporary Use for Geolocation

  • Your real IP is used temporarily (in-memory) to determine country
  • Geolocation service provides country-level data

Step 2: Immediate Hashing

  • IP is immediately hashed with SHA-256 + server salt
  • Original IP is discarded (never stored)

Step 3: Storage

  • Only the hash is stored (64-character hex string)
  • Hash cannot be reversed to original IP

IP Anonymization Flow

Example:

Your IP: 203.0.113.42 Geolocation: Country = "US" (temporary) Hash: SHA-256("203.0.113.42_#{server_secret}") = "b7d2e8f1a3c5..." Stored: Hash + Country code ("US") Original IP: Discarded (never stored)

Location Data Minimization

What We Store:

  • country - 2-character ISO code only (e.g., “CH”, “US”)
  • city - Filtered (set to null if unknown/invalid)

What We Do NOT Store:

  • Precise coordinates (latitude/longitude)
  • Street addresses
  • Postal codes
  • Precise time zones

Privacy Impact: Country-level data provides useful analytics without compromising privacy. You cannot be identified from country-level data alone.

9. User Agent & Device Privacy

User Agent Anonymization

Before Anonymization:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36

After Anonymization:

Chrome Windows Desktop

What is Removed:

  • Specific version numbers
  • Build numbers
  • Device-specific identifiers
  • Browser engine versions

What is Kept:

  • Browser family (Chrome, Firefox, Safari, etc.)
  • Operating system family (Windows, macOS, Linux, iOS, Android)
  • Device type (Desktop, Mobile, Tablet)

Purpose: Provides useful analytics (browser/OS usage trends) without creating device fingerprints.

10. Session Security

How Sessions Work

Session Creation:

  • Session ID generated using cryptographically secure random number generator
  • Session data encrypted with server secret key
  • Session stored in encrypted cookie

Session Rotation:

  • On Authentication: Session ID regenerated to prevent fixation attacks
  • On Privilege Escalation: Session ID regenerated when gaining admin access
  • Old session invalidated immediately

Session Encryption:

  • All session data encrypted before transmission
  • Uses server secret key (128+ characters)
  • TLS provides additional encryption in transit

Protection Against Attacks

Session Fixation: ✅ Protected

  • Session ID rotated on authentication
  • Cannot reuse old session ID after login

Session Hijacking: ✅ Protected

  • Session cookies encrypted
  • TLS prevents interception
  • Session tokens random and unpredictable

Session Replay: ✅ Protected

  • Session tokens include timestamps
  • Expired sessions rejected
  • Session rotation prevents reuse

11. Even We Cannot Access Your Data

Developer Inaccessibility

With full database access, we cannot:

  1. Identify Users: - Commitment hashes cannot be reversed to usernames - No usernames or email addresses stored to match - No way to link account to identity
  2. Access Payment Information: - Payment cards stored in Stripe (not our database) - We only see anonymous Stripe customer IDs - No billing addresses or payment details
  3. Determine Precise Location: - IP hashes cannot be reversed - Only country-level data stored - Cannot determine city or address
  4. Track Your Activity: - Cannot link account to specific IPs (IPs are hashed) - Cannot fingerprint devices (user agents anonymized) - Cannot create browsing profile

What We CAN See (Limited, Anonymous Data)

Aggregate Statistics Only:

  • Total number of users (not who they are)
  • Total number of links (not who created them)
  • Subscription tier distribution (not which users)
  • Country-level traffic distribution (anonymized)

We CANNOT See:

  • Which specific user did what
  • Your username or identity
  • Your email address (we never ask for it)
  • Your payment details
  • Your precise location
  • Your browsing patterns

12. Security Measures Summary

Encryption

In Transit:

  • ✅ TLS 1.3 (latest standard)
  • ✅ All traffic encrypted (HTTPS only)
  • ✅ Perfect Forward Secrecy
  • ✅ Certificate pinning (via browser verification)

At Rest:

  • ✅ Database encrypted (Exoscale instance disk - AES-256)
  • ✅ Backups encrypted (stored on same encrypted instance disk)
  • ✅ Instance disk encryption automatic (Exoscale default)
  • ✅ Credentials encrypted (credentials.yml.enc)
  • ✅ Session data encrypted

Cryptographic Security

Hash Functions:

  • ✅ SHA-256 for all security-critical hashing (IP anonymization, nonce generation, visitor fingerprinting)
  • ✅ PBKDF2 client-side (100,000 iterations) for commitment generation - key stretching slows brute force by 100,000x
  • ✅ BCrypt for link password protection (adaptive hashing)
  • ✅ No weak algorithms (MD5, SHA1 eliminated)

Why PBKDF2 for Commitments?

  • PBKDF2 is a Key Derivation Function designed specifically for password-derived keys
  • 100,000 iterations provide key stretching (100,000x slower than simple hashing)
  • Industry best practice for commitment schemes
  • NIST-recommended (SP 800-132)

See Encryption Architecture Guide for comprehensive explanation of all encryption methods, why we chose each one, and why our architecture is superior to traditional systems.

Salting:

  • ✅ All security-critical hashes use salts
  • ✅ Server-specific salt for IP hashing
  • ✅ Prevents rainbow table attacks

Application Security

Attack Prevention:

  • ✅ CSRF protection (all forms protected)
  • ✅ SQL injection prevention (parameterized queries)
  • ✅ XSS protection (Content Security Policy with nonces)
  • ✅ CSP violation reporting (real-time XSS detection)
  • ✅ Session fixation prevention (session rotation)
  • ✅ Rate limiting (brute force protection)

Headers:

  • ✅ Content Security Policy (CSP) with nonces
  • ✅ CSP violation reporting endpoint
  • ✅ Strict Transport Security (HSTS)
  • ✅ X-Frame-Options (clickjacking protection)
  • ✅ X-Content-Type-Options (MIME sniffing protection)
  • ✅ Referrer-Policy (no-referrer - maximum privacy)
  • ✅ Permissions-Policy (blocks fingerprinting features)
  • ✅ Cross-Origin security headers (COEP, COOP, CORP)
  • ✅ Expect-CT (Certificate Transparency monitoring)

13. Attack Scenarios & Protections

Scenario 1: Database Breach

Attack: Attacker gains access to database.

What They Get:

  • Commitment hashes (cannot be reversed)
  • Nonces (cannot reveal usernames)
  • Hashed IPs (cannot be reversed)
  • Country codes (too vague to identify users)

What They Cannot Do:

  • ❌ Identify users (no usernames, emails, or personal data)
  • ❌ Access accounts (commitments cannot be reversed)
  • ❌ Reverse IP addresses (hashed with salt)
  • ❌ Link activity to identities (no identifiers)

Protection Level: ✅ COMPLETE - Even with full database access, users remain anonymous.

Scenario 2: Network Traffic Interception

Attack: Attacker intercepts network traffic (MITM).

What They See:

  • Encrypted TLS data (random-looking bytes)
  • Domain name (pvtlnk.com)
  • Certificate information

What They Cannot See:

  • ❌ Your username (never transmitted)
  • ❌ Your email (we never ask for it)
  • ❌ Your password (never transmitted)
  • ❌ Commitment hashes (encrypted in TLS)
  • ❌ Session data (encrypted in TLS)
  • ❌ Any personal information

Even If TLS Broken:

  • Commitment hashes still cannot be reversed
  • No personal identifiers in plaintext
  • Session tokens random and unpredictable

Protection Level: ✅ COMPLETE - TLS encryption + zero-knowledge architecture provides defense in depth.

Scenario 3: Code Analysis / Reverse Engineering

Attack: Attacker analyzes source code (open source or leaked).

What They Learn:

  • How commitment hashing works
  • Database schema
  • API endpoints

What They Cannot Do:

  • ❌ Reverse existing commitments (still requires 2^256 brute force)
  • ❌ Identify users (no personal data in code)
  • ❌ Decrypt past data (encryption keys separate)
  • ❌ Create rainbow tables (server-specific salts)

Protection Level: ✅ COMPLETE - Security by design; code knowledge doesn’t compromise data.

Scenario 4: Insider Threat (Developer Access)

Attack: Developer attempts to access user data.

What They Can Do:

  • Access database
  • View all stored data
  • Run queries

What They Cannot Do:

  • ❌ Identify users (commitments cannot be reversed)
  • ❌ Access accounts (commitments cannot be reverse-engineered)
  • ❌ Link activity to identities (no personal identifiers)
  • ❌ Determine locations (IPs hashed, only country-level data)

Protection Level: ✅ COMPLETE - Zero-knowledge architecture means even developers cannot access user data.

14. Why This Is More Secure Than Alternatives

vs. Traditional Systems

Traditional Systems:

  • Store your email address
  • Can identify you
  • Can link activity to your identity
  • If breached, your email and activity are exposed

PVTLNK:

  • No email stored
  • Cannot identify you
  • Cannot link activity to identity
  • If breached, only anonymous hashes exposed (cannot be reversed)

vs. Other Privacy-Focused Services

Many “private” services:

  • Still require email for recovery
  • Still store IP addresses (sometimes hashed, but often reversible)
  • Still link accounts to identities
  • May share data with third parties

PVTLNK:

  • No email required (recovery codes instead)
  • IPs hashed with salt (truly irreversible)
  • Accounts completely anonymous
  • No data sharing (we don’t have data to share)

vs. Self-Hosted Solutions

Self-hosting:

  • You control the server (good)
  • But you manage security (requires expertise)
  • You handle updates and patches
  • You’re responsible for encryption

PVTLNK:

  • We handle security (world-class implementation)
  • We manage updates and patches
  • We ensure encryption (verified)
  • Swiss hosting for legal protection
  • You get privacy without the complexity

15. Privacy Guarantees

What We Guarantee

✅ Zero Personal Data Storage

  • No email addresses
  • No names, phones, or addresses
  • No personal identifiers of any kind

✅ Complete Anonymization

  • IP addresses hashed (cannot be reversed)
  • User agents anonymized (no fingerprinting)
  • Country-level location only

✅ Zero-Knowledge Architecture

  • Even we cannot identify users
  • Even we cannot access accounts without commitments
  • Even we cannot reverse IP addresses

✅ Encryption Everywhere

  • All traffic encrypted (TLS 1.3)
  • Database encrypted (AES-256)
  • Sessions encrypted
  • Credentials encrypted

✅ Swiss Legal Protection

  • Data stored in Switzerland
  • Subject to Swiss privacy laws (strongest globally)
  • Not subject to foreign surveillance laws

What We Cannot Guarantee

⚠️ Complete Anonymity from All Parties:

  • Law enforcement can request data with proper legal process (Swiss law)
  • Swiss authorities have jurisdiction over Swiss-hosted data
  • This is true of any service, anywhere

⚠️ Protection from Browser/Device Fingerprinting:

  • Your browser may collect data independently
  • Your ISP can see domain names you visit
  • VPN is recommended for maximum anonymity

⚠️ Payment Anonymity:

  • Stripe processes payments (subject to their policies)
  • However, Stripe customers are not linked to email addresses in our system

16. Best Practices for Maximum Privacy

Recommendations for Users

For Maximum Anonymity:

  1. ✅ Use a VPN - Masks your IP address from ISP
  2. ✅ Use Tor Browser - Maximum anonymity (all traffic routed through Tor network)
  3. ✅ Clear cookies between sessions - Prevents tracking
  4. ✅ Use private browsing mode - Reduces fingerprinting
  5. ✅ Don’t reuse passwords - If commitment compromised, other accounts remain safe

For Maximum Security:

  1. ✅ Use strong passwords - Makes brute force attacks harder (even though commitments can’t be reversed)
  2. ✅ Save recovery codes - Only way to recover account
  3. ✅ Use HTTPS Everywhere - Browser extension ensures HTTPS
  4. ✅ Verify SSL certificate - Browser should show valid certificate

Note: These are optional - PVTLNK is private by default. These practices provide additional layers of protection.

17. Technical Verification

How to Verify Our Claims

Database Schema Review:

  • Check db/schema.rb - verify no email, name, phone, or address columns
  • Verify commitment_users table structure
  • Confirm IP hashing implementation

Code Review:

  • Review authentication code - commitments, not passwords
  • Review IP handling - hashing before storage
  • Review analytics - anonymization of user agents

Security Audits:

  • Run automated privacy tests (test_security_privacy.rb)
  • Review security audit reports
  • Verify encryption configuration

Legal Verification:

  • Review Exoscale privacy policy
  • Verify Swiss data protection laws (FADP)
  • Confirm data residency (Switzerland)

18. Conclusion

Our Privacy Promise

PVTLNK is built to be private by design, not private by promise.

We cannot access your data because we never stored it in the first place.

✅ No email addresses stored ✅ No passwords stored ✅ No payment card details stored ✅ No precise location data stored ✅ IP addresses hashed (cannot be reversed) ✅ User agents anonymized ✅ Hosted in Switzerland for legal protection ✅ Even we cannot access your identity

Trust Through Transparency

Every privacy measure listed here has been:

  • ✅ Verified through code review
  • ✅ Tested with automated security audits
  • ✅ Documented in our codebase
  • ✅ Confirmed through database schema analysis

We believe privacy is a right, not a feature.

This whitepaper documents what we actually do, not what we claim to do.

Appendix: Technical Details

Cryptographic Implementation

Commitment Generation:

// Client-side (simplified) nonce = SHA-256(email) // Deterministic from email commitment = SHA-256(password + nonce) // One-way hash

IP Anonymization:

# Server-side salt = Rails.application.secret_key_base hashed_ip = SHA-256("#{ip_address}_#{salt}") # Original IP discarded, only hash stored

Session Security:

# Session rotation on authentication reset_session // Regenerates session ID session[:commitment_user_id] = user.id // New session ID

Database Schema Verification

CommitmentUser Table (commitment_users):

  • commitment (string, 64 chars) - SHA-256 hash, cannot be reversed
  • nonce (string, 64 chars) - Cannot reveal email
  • anonymized_id (string) - Generated ID, not personal identifier
  • No email, name, phone, or address columns

ClickAnalytic Table (click_analytics):

  • hashed_ip (string, 64 chars) - SHA-256 hash + salt, cannot be reversed
  • country (string, max 2 chars) - ISO country code only
  • city (string, nullable) - Filtered for privacy
  • No plain IP addresses, no precise coordinates

AnonymousSubscription Table (anonymous_subscriptions):

  • stripe_customer_id (string) - Stripe’s anonymous ID
  • stripe_subscription_id (string) - Stripe’s subscription ID
  • No payment card details, no billing addresses

FAQ

Q: Can you see my username or email address?

A: No. We ask for a username during signup (not an email), and your username never leaves your browser. It’s used only client-side to generate a deterministic nonce, then discarded. We never transmit your username to our servers, and we never store it in our database. Authentication uses cryptographic commitments, not username-based login. We never ask for or store email addresses.

Q: What if I forget my password?

A: We provide recovery codes during account creation. Save these codes - they’re the only way to recover your account. We cannot reset your password because we don’t store your username or any other identifying information.

Q: Can law enforcement identify me?

A: We cannot identify you because we don’t store personal data. Even with a valid legal request, we can only provide anonymous data (hashes, country codes). Swiss law enforcement would need to work with us to match commitments, which is computationally infeasible.

Q: What if your database is hacked?

A: Attackers would only get commitment hashes and nonces - they cannot reverse these to determine emails or passwords. Your identity remains protected. This is why zero-knowledge architecture is so powerful.

Q: Can someone intercept my traffic and see my data?

A: All traffic is encrypted with TLS 1.3. Even if intercepted, attackers see only encrypted data. Even if TLS is broken (theoretical), they only see commitment hashes (cannot be reversed).

Q: Can my account be reverse engineered from the database?

A: No. Commitment hashes cannot be reversed (mathematically impossible). Even with full database access and code knowledge, identifying users is computationally infeasible (2^256 brute force required).

Q: Is Switzerland really better for privacy?

A: Yes. Swiss data protection laws are among the strongest globally, Switzerland is not part of surveillance alliances, and Swiss hosting provides stronger legal protections than many other jurisdictions.

A: No. IP addresses are hashed (different each time you connect), user agents are anonymized, and there are no persistent identifiers. We cannot create activity profiles.

For detailed technical information about our encryption architecture:

  • Encryption Architecture Guide: Comprehensive guide explaining: - Types of encryption and cryptographic functions - Why we use each method (SHA-256, PBKDF2, BCrypt, AES-256, TLS 1.3) - Why our zero-knowledge architecture is superior - Comparison to traditional systems - Real-world attack scenarios - Industry standards compliance

This document focuses on privacy and security what we do. The Encryption Architecture Guide explains how we do it and why it’s the best approach.

Document Version: 2.2 Last Updated: November 2nd, 2025 Verification: Code-reviewed, tested, and verified

Recent Updates (Version 2.2)

✅ Key Terminology Added: New section 0.5 for core definitions. ✅ Commitment Flow Diagram: Added visual process flow for Section 1. ✅ IP Anonymization Flow Diagram: Added visual process flow for Section 8. ✅ CSP Violation Reporting: Real-time detection and logging of XSS attempts ✅ Storage Encryption Clarification: Instance disk encryption (automatic, AES-256) ✅ Enhanced Security: All security enhancements verified and documented