Security & Zero-Knowledge
Understanding how we protect your privacy without technical jargon
The Core Concept: We're Blind By Design
Most file-sharing services work like this: You upload a file → They store it → They can read it. Even if they promise not to look, they could if they wanted to (or if someone forced them to).
We're different. We literally cannot read your files. Not because we're being nice, but because of how the technology works. It's like asking a blind person to describe a painting - the information simply isn't accessible to us.
In simple terms:
Your files are encrypted before they leave your device. We never see the unencrypted version. The key to decrypt them never touches our servers. Without that key, your files are just random noise to us.
How It Actually Works (Step by Step)
Let's walk through what happens when you share a file:
You Select Files
You choose files to upload. They're still sitting on your computer at this point.
Your Browser Generates a Random Key
A unique encryption key is created in your browser - not on our servers. This key is completely random and only exists in your current session.
Files Are Encrypted in Your Browser
Before uploading, your browser scrambles the files using that key. The original files never leave your device unencrypted. What gets uploaded is encrypted garbage - meaningless without the key.
Encrypted Data Is Uploaded
The encrypted blob is sent to our servers. All we see is: "File received, 2.5MB, expires in 7 days." Filenames are also encrypted - we store them, but they're just scrambled text we can't read without your key.
You Get a Link with the Key
The share link includes the encryption key in the URL fragment (the part after the #). Example: privsen.com/view/abc123#keyhere
Critical: The part after # is never sent to our servers. It stays in the browser.
Someone Clicks Your Link
When someone opens your link, their browser:
- Requests the encrypted file from our servers
- Extracts the key from the URL (in their browser)
- Decrypts the file locally
- Displays the original content
All decryption happens in their browser. Our servers never see the decryption key or the unencrypted content.
⚠️ Important Exception: Polls Are NOT Encrypted
Polls work differently from our other tools (Snapshot, Paste, Chat, Proof). Polls trade encryption for real-time aggregation and anonymous voting.
Why polls aren't encrypted: To show real-time results and prevent duplicate votes, we need to see the data. We store poll questions, options, and vote counts in plaintext.
Polls remain anonymous: We don't collect any identity data (names, emails). We use standard anti-abuse measures to prevent vote manipulation while keeping all votes completely anonymous.
Bottom line: Use polls for surveys and feedback, not for sharing sensitive information. Everything else (files, text, chat, proofs) uses full zero-knowledge encryption.
Why This Matters
Protection from hackers
If someone hacks our servers, they get encrypted blobs they can't decrypt. Your files remain secure even if our entire infrastructure is compromised.
Protection from government surveillance
If authorities request data, we comply with legal orders - but we can only provide encrypted files we can't decrypt. We don't have the keys, so we can't help them access your content.
Protection from us
Even if we wanted to snoop (we don't), or if a rogue employee tried to access your files, it's technically impossible. The architecture prevents it.
Protection from data breaches
Most breaches expose passwords, emails, and file contents. In our case, a breach would expose... encrypted blobs with no way to decrypt them. Your data remains private.
The Trade-off: What This Means for You
Zero-knowledge encryption is powerful, but it comes with one major consequence:
If you lose the link, your files are gone forever.
There's no "forgot password" button. No account recovery. No customer support backdoor. The encryption key only exists in that link. Without it, the files are permanently inaccessible - even to us.
This isn't a bug or an oversight. It's the fundamental principle that makes zero-knowledge work. We can't recover your files because we never had access to them in the first place.
Technical Details (For the Curious)
If you're technically inclined, here's what's happening under the hood:
- Encryption algorithm: AES-256-GCM (industry-standard, battle-tested encryption)
- Key generation: Web Crypto API with secure random number generation (crypto.getRandomValues)
- Key storage: Share keys embedded in URL fragment (never sent to servers). For "My Links" feature, wrapped (encrypted) keys stored using HKDF-derived wrapping keys from your login token.
- Transport security: All connections use TLS/HTTPS. Even encrypted data is transmitted over secure channels.
- Authentication: Files are identified by random IDs with no connection to user identity.
Want to verify? Our encryption happens in your browser's JavaScript. Open your browser's developer console and inspect the network requests - you'll see encrypted data being sent, never plaintext.
Common Security Questions
Q: Can you add a password recovery feature?
A: No. Password recovery requires storing a copy of the key or using key escrow, which defeats the entire purpose of zero-knowledge encryption. If we could recover your files, so could hackers or governments.
Q: What if you're lying about not storing keys?
A: Fair question. You can verify by inspecting the network traffic in your browser's developer tools. The encryption key (everything after # in the URL) is never sent to our servers. It's a technical limitation of how browsers work, not a promise we can break.
Q: Is this really more secure than [other service]?
A: If the other service has access to your unencrypted files (for features like previews, virus scanning, or search), then yes - we're more secure in that we genuinely can't access your data. The trade-off is we can't offer those convenience features.
Q: What about metadata - upload times, file sizes?
A: We see minimal metadata: file size (to calculate storage costs) and upload timestamp (to enforce expiration).
Q: How does "My Links" work if keys never touch your servers?
A: For users who create accounts, we use a clever workaround called "key wrapping." Your share keys are encrypted (wrapped) before storage using a key derived from YOUR login token (which never leaves your browser). The server stores these wrapped keys but can't decrypt them - only your browser can unwrap them when you view "My Links." This gives you the convenience of seeing your upload history without compromising zero-knowledge security. You can verify this in your browser's DevTools: the network requests show wrapped keys (encrypted base64 strings), never plaintext keys.
Q: Can someone brute-force the encryption?
A: AES-256 encryption would take billions of years to crack with current technology, even with massive computing power. The sun will burn out before someone brute-forces your files. However, if you share the link publicly or with untrustworthy people, encryption won't help - they have the key.
Technical Deep Dive: How Key Wrapping Works
For technically curious users: here's the complete cryptographic flow that powers the "My Links" feature while maintaining zero-knowledge security.
🔍 Verify Our Claims Yourself
Don't take our word for it. Here's how to verify zero-knowledge encryption works:
- Open your browser's Developer Tools (press F12 or right-click → Inspect)
- Go to the Network tab
- Upload a file to Privsen using any tool (Snapshot, Paste, etc.)
- Inspect the upload request in the Network tab - you'll see encrypted binary data, not your original file
- Check the share URL you receive - the encryption key appears after the # symbol
- Notice the key (everything after #) never appears in Network requests - browsers don't send URL fragments to servers
This verification works because encryption happens in JavaScript running in YOUR browser, not on our servers. The code is open for inspection in your browser's DevTools.
Security Status
Dependencies: 0 known vulnerabilities in production code
Regularly scanned (npm audit)
Encryption: AES-256-GCM (NIST approved, battle-tested since 2001)
Used by: US Government, major cloud providers, banking systems
Transport: TLS 1.3 (all connections encrypted in transit)
Even encrypted data travels through secure channels
Implementation: Web Crypto API (browser-native, audited by browser vendors)
Used by millions of websites, maintained by Google/Mozilla/Apple
Security practices: Automated scans, verifiable architecture, responsible disclosure program
Professional audits planned as platform scales
The Bottom Line
Zero-knowledge encryption isn't marketing fluff - it's the foundation of how this service works. We built the system so that we can't access your data, not so we won't.
Your files are encrypted before they leave your device. The key never touches our servers. Without that key, your files are meaningless noise - to hackers, to governments, and to us.
This is privacy by architecture, not by policy. And that's the only kind of privacy guarantee that actually matters.
Questions about our security? security@privsen.com
🔒 Responsible Security Disclosure
Security Researchers: If you discover a security vulnerability in Privsen, we want to hear from you. We take all security reports seriously and will respond promptly.
Please email detailed reports to security@privsen.com
What to include:
- Description of the vulnerability
- Steps to reproduce the issue
- Potential impact assessment
- Your contact information (optional, but helpful for follow-up)
Our commitment: We will acknowledge receipt within 48 hours and provide updates on our investigation and remediation timeline.