Setfeed is designed so message content does not need to be readable by Setfeed servers. When encrypted delivery is used, the web bridge (setfeed.app) acts as a ciphertext transport layer.

Threat model (plain language)

• Setfeed servers should not learn message contents when end-to-end encryption is used.
• Attackers may try to abuse the bridge (spam, scraping, automation), so we use integrity checks and rate controls.
• Your device matters: if a recipient device is compromised, content could be exposed there (as with any secure messenger).

Encryption boundary

Messages sent through setfeed.app are encrypted in your browser before they reach our servers. When encrypted delivery is used, Setfeed stores and transports only encrypted ciphertext (plus required cryptographic metadata such as IV and salt).

What Setfeed can and cannot see

• Cannot read: encrypted message content (ciphertext remains opaque to Setfeed).
• Can process: delivery metadata required to deliver an envelope and enforce one-time consumption.
• May see: operational/security logs from infrastructure (e.g., IP address and request metadata) for reliability and abuse prevention.

Keys

Private encryption keys are stored only on recipient devices and are never intentionally uploaded to Setfeed servers. This is an explicit boundary: the system is built so Setfeed does not need access to your private keys to deliver encrypted envelopes.

Attachments (images)

When image attachments are supported for a message flow, Setfeed stores encrypted attachment bytes and delivers them alongside the encrypted envelope. Attachments are intended to follow the same boundary as message text: encrypted client-side, stored as ciphertext-only, and decrypted on the recipient device.

Integrity and abuse prevention

To reduce automated abuse, Setfeed can use Firebase App Check. On Android, App Check can use Play Integrity; on the web bridge it can use reCAPTCHA. These systems may process signals and tokens that help verify requests come from an authentic app/browser environment.

• App Check / Integrity tokens: short-lived attestation tokens.
• Basic device/app signals: required for integrity verification (handled by Google’s services).

Backend protections

• Transport security: HTTPS for data in transit.
• Access controls: server-side authorization checks and Firebase security controls.
• Replay protection: delivery state enforces one-time consumption where applicable.
• Rate limits / constraints: conservative caps to reduce abuse and accidental overload.

Reporting a vulnerability

If you believe you’ve found a security issue, email security@setfeed.app. Please include steps to reproduce, impact, and (if possible) a minimal proof of concept.

• Please do not publicly disclose until we’ve had a chance to investigate and mitigate.
• Please avoid accessing data that isn’t yours, and avoid service disruption.

Changes to this page

If we change this page, we will update the effective date above and publish the updated version here.