Skip to main content
Hypastack operates on a zero-knowledge paradigm for one of its three pipelines. This page explains exactly how far that guarantee reaches, since it’s not all-or-nothing.

​
Secure File Sharing (zero-knowledge)

When you upload a file through the website’s Secure File Sharing flow:
  1. Your browser encrypts the file locally using AES-GCM (256-bit) before a single byte leaves your device.
  2. The encryption key is embedded in the URL fragment (the part after #...).
  3. Browsers never transmit the URL fragment to a server during a request, it’s processed entirely client-side.
Because of that last point, Hypastack’s infrastructure never receives, stores, or has any path to reconstruct your decryption key. There’s no “master key” and no backdoor. If a server is breached, an attacker gets nothing but ciphertext.
This also means Hypastack cannot scan these files for illegal content, recover a lost key, or decrypt a file on your behalf, ever. That’s a direct consequence of the architecture, not a policy choice.

​
Permanent CDN Hosting (not encrypted)

CDN assets are public by design. A browser has to be able to fetch and render them directly (<img src="...">, stylesheets, etc.), which is incompatible with client-side encryption. CDN uploads are stored and served in the clear. To protect your privacy anyway, Hypastack strips EXIF, GPS, and camera metadata from images on upload. But the visible content of the file itself is readable by Hypastack and by anyone holding the link.

​
Developer API uploads (not encrypted)

The API has no browser in the loop to hold a key, so files uploaded through it are stored as received and are readable by Hypastack. If you’re using a third-party app built on the Hypastack API, your upload sits in that developer’s account, both they and Hypastack can access it. Your privacy relationship in that case is with the developer, not Hypastack directly.

​
Summary

For what account metadata is collected (separate from file contents), see the Privacy Policy.