chirpfile

Security model.

How your files stay private - and what the actual guarantees are.

The core idea

Most "secure" file transfer tools encrypt data in transit but leave a copy on a server. That server - or anyone who compromises it - can eventually access that copy.

chirpfile takes a different approach. The file is encrypted in your browser before anything is uploaded. The decryption key is transmitted as sound - it never touches any network. A remote attacker who intercepts the server gets only unreadable ciphertext with no key to open it.

How it works
1. Encrypt locally
Your browser encrypts the file using AES-GCM via the Web Crypto API before a single byte is sent anywhere. The key exists only in your device's RAM.
2. Upload the ciphertext
The encrypted blob is uploaded to our relay. The server has no key. It is holding something it cannot read.
3. Chirp the key
The decryption key is encoded into a 1-2 second sound using ggwave (open-source FSK). In Ultrasound mode this is inaudible. The key travels as air pressure - not as a network packet.
4. Decrypt and delete
The receiving device hears the chirp, pulls the blob, and decrypts locally. The relay deletes the blob immediately. All blobs auto-expire after 15 minutes regardless.
Verify it yourself

These claims are testable, not promises. Every chirpfile page runs a small audit script that wraps window.fetch and scans every outbound request body for the active AES key. If the key were ever transmitted, the audit panel would alarm.

Read the script: /public/audit.js - about 230 lines of plain JavaScript, no minification. It is the exact code running in your browser right now.

Or open browser DevTools → Network tab and watch a transfer. Every byte that leaves your device is visible there. Compare what you see with what the audit panel reports at the bottom of the page - they will match. If they ever diverge, the audit is lying.

Here is an actual exported audit log from a successful 345 KB transfer on this site:

// AES-128 key generated locally. Location is verifiable: it never appears in any network event below.
{ "type": "key_generated", "detail": { "algo": "AES-128-GCM", "location": "browser memory only", "fingerprint": "79efcfc7" } }

// File encrypted in browser. Ciphertext = plaintext + 16-byte GCM auth tag.
{ "type": "encrypt_done", "detail": { "plaintextSize": 353332, "ciphertextSize": 353348 } }

// Ciphertext uploaded to relay. keyAbsent = true means the audit scanned
// every byte of the request body and confirmed the AES key is not present.
{ "type": "request_start", "detail": { "method": "PUT", "host": "relay.chirpfile.com", "bodySize": 353348, "keyAbsent": true } }

// Relay accepted ciphertext (it does not have the key to decrypt it).
{ "type": "request_end", "detail": { "status": 201, "ok": true, "elapsedMs": 2160 } }

// Key encoded into a chirp and played as sound. Network is not involved here.
{ "type": "chirp_encode", "detail": { "payloadBytes": 36, "protocol": "audible_fastest" } }

The full log is 13 events. Notice what is absent: not a single network event contains the key, and not a single crypto event contains a network call. The two channels are physically separated.

What it protects against
Server breach
The server holds only ciphertext. No key is stored on our infrastructure. A full database dump gives an attacker nothing usable.
Man-in-the-middle
The key never travels over a network, so it cannot be intercepted by monitoring WiFi, DNS, or TLS traffic.
Forwardable links
The encrypted blob is deleted after the first download. There is no persistent URL to forward.
Replay attacks
Each transfer uses a fresh key. Old ciphertext cannot be re-decrypted with a new chirp.
Subpoena of our servers
We cannot hand over keys we don't have.
What it does not protect against

chirpfile is designed against remote attackers. We'd rather be honest about the limits than overclaim.

A microphone physically in the room
If a recording device is present when the chirp plays, it could capture the key. This requires an attacker who is already physically present with you.
A compromised receiving device
Once the file is decrypted on the receiver's machine, what happens to it is beyond our control.
Remote transfers
Practical decode range is under 1 meter in Ultrasound mode. This is not a replacement for secure messaging when both parties are not in the same room.
Technical notes

Encryption: AES-GCM via the Web Crypto API, entirely in-browser. Acoustic encoding: ggwave (MIT license), an open-source FSK library. No proprietary or unaudited cryptography.

Short text under ~120 characters bypasses the relay entirely and is chirped as a direct acoustic payload - nothing is uploaded at all.

If your network blocks chirpfile.com

Some corporate URL filters misclassify chirpfile.com as cloud storage and block it. The same site is reachable at chirpfile.up.railway.app - different domain category (developer platform), same architecture, same audit panel, same canonical content. If one URL is blocked, the other usually isn't.

Open app → Guide: acoustic data transmission Guide: cross-network file transfer Guide: zero-knowledge file transfer AirDrop alternative Share WiFi password Cross-platform transfer Send without WiFi Corporate laptop Compare FAQ ← Home