Security at boopr

Everything you create on boopr is encrypted on your device before it reaches our servers.

Your private keys never leave your device. We rely on @noble/curves and @noble/ciphers on the client and the Go standard crypto package on the server. We don't write our own primitives.

The server only ever stores ciphertext. Decryption happens on your friends' devices, because we don't hold the keys.

boopr's encryption stops a specific list of attacks. Server-side compromise of post or message content. Passive surveillance by a network-level adversary or our own staff. Ad-tech and data-broker tracking of what you said, who you said it to, or what photo you sent. Casual snooping by anyone reading our database.

It doesn't try to stop everything. A compromised device reads your messages because the keys live on the device. A friend who screenshots a boop and forwards it on another app has done so manually; we notify the sender, but we can't undo it. Someone with physical access to your unlocked phone has the same access you do. Social-engineering attacks against you or your friends are out of scope. And we still hold metadata about who posted when and who pulled the post; under valid legal process, that metadata can be compelled even though the content can't.

The limits are part of the design.

We retain only what we need to run the service. Raw IP addresses are never stored: they live in memory for rate-limiting and are cleared within 24 hours, never written to disk or logs. For abuse detection we store a salted HMAC of IP (not the IP itself), and the salt rotates monthly so the hashes can't be correlated across months. Encrypted backups can persist as ciphertext for up to 90 days after deletion (we still can't decrypt them). Push device tokens roll off after 90 days of inactivity. Subscription records stick around for three years after cancellation because California's Automatic Renewal Law requires it. Account data, profiles, posts, and media are removed within 30 days of account deletion.

Under valid legal process (subpoena, court order, or search warrant under ECPA and the SCA), we can hand over: account UUID, public keys, account creation date, the platform you're on, and the encrypted blobs we hold. We cannot hand over IP addresses (we don't store them), post content, captions, photos, profile fields, friend lists, or audience membership, because those are either never stored or encrypted with keys we don't have. Where law allows, we notify affected users; if a gag order applies, we don't.

A full encrypted-data export feature is on the post-launch roadmap. When it ships, the bundle will be encrypted with your recovery phrase and decryptable on a new device or independently if we ever shut down, using documented standard primitives (XChaCha20-Poly1305, Ed25519, X25519, HKDF) rather than a proprietary container. Until then, your 24-word recovery phrase already restores your account, posts, and profile on a new device.

Starting on the one-year anniversary of public launch (August 15, 2027), we'll publish an annual transparency report listing the number of legal requests received, the categories of data turned over, and the number of users affected. The full process and retention rules live in our Privacy Policy.

Keys and nonces come from CSPRNGs: crypto/rand on the Go backend, crypto.getRandomValues on the client. Math.random never touches security-relevant code. Signature checks, HMACs, and TOFU identity comparisons run in constant time so an attacker can't learn bytes from response timing. Private keys and symmetric keys sit in Uint8Array buffers we zero out as soon as the operation finishes.

Photos are re-encoded on your phone before encryption, which drops GPS coordinates, camera model, capture time, and the rest of the EXIF block. The server never sees the original file. Push notifications carry a routing ID and nothing else: no sender name, no text, no thumbnail. Your device composes the notification text locally after it decrypts the payload.

Every HKDF derivation uses a distinct versioned info string (boopr-post-recipient-key, boopr-screenshot-narc-v1, and so on) so the same seed never produces the same subkey twice.

If you find a vulnerability, email [email protected]. PGP key on request. We acknowledge new reports within 48 hours and complete initial triage within 7 days. Critical issues we aim to fix within 7 days, high severity within 30, medium and low within 90.

In scope: the iOS and Android apps, the backend API and infrastructure, and this site. Out of scope: third-party services we depend on (Apple, Google, our hosting provider), social-engineering attacks against the team, denial-of-service attacks, and findings from automated scanning that don't show a real impact path.

We don't yet have monetary bounties; we're a small self-funded team. Reports that lead to a fix get public credit on this page (with your permission), boopr+ for life, and merch. Monetary rewards will roll in as the app's revenue does. We will never threaten legal action against good-faith research, and we don't enforce non-disclosure beyond a coordinated 90-day window.