Security at relaybell

Encryption in transit

The relaybell website, dashboard and API are served over HTTPS only. Browsers are told to use HTTPS for every future visit (HTTP Strict Transport Security, two years, including subdomains), and pages are sent with a Content Security Policy.

Notifications travel to your subscribers through the browsers' own push services (Google, Mozilla, Apple, Microsoft). Following the Web Push standard, each message is encrypted with keys that belong to the subscriber's browser, so the push service carries it without being able to read it.

Backups

Every night the database is copied off the server to Cloudflare R2 object storage, over TLS, where it is stored encrypted at rest. Uploaded files (notification images and logos) are mirrored there too. Older copies are pruned automatically after a retention period, and the restore procedure is documented.

Access control

• API keys are scoped. Each key can be limited to what it needs (for example, sending only, or reading subscribers), and keys are stored as a one-way hash: we can check a key, but we can't read it back.
• Passwords are stored as salted scrypt hashes, never in plain text. You can also sign in with Google or GitHub.
• Two-factor authentication. Customers can turn on sign-in codes from an authenticator app, with one-time recovery codes. relaybell's own admin console requires two-factor sign-in for every admin.
• Audit log. Actions taken in the relaybell admin console are recorded in an audit log.
• Isolation and limits. Every request is scoped to one website's data, and sending and the public endpoints are rate limited.

Signed webhooks

Every webhook relaybell sends carries an X-Relaybell-Signature header: sha256= and the HMAC-SHA256 of the raw request body, keyed with that webhook's own secret. Verify it before trusting the request — the webhook docs show how, with a constant-time comparison.

User ID verification

When you link browsers to your own user ids, your server can sign each id (HMAC-SHA256 with a secret only you and relaybell know). With Require verified User IDs switched on, relaybell ignores any user id whose signature is missing or wrong, so nobody can subscribe as one of your customers and receive their messages. See Identity verification.

Data retention

• Activity history (the event log behind your analytics and automations) is deleted automatically after 90 days by default. Each website can choose a different retention window in its settings.
• Subscriptions are kept until the person unsubscribes, the browser drops the subscription, or you delete them.
• We don't store subscribers' IP addresses: the approximate country is worked out when someone subscribes, and the address itself is not kept.
• You can export or permanently delete a subscriber's data through the API at any time. More in our Privacy Policy and DPA; the providers we use are listed on Subprocessors.

Reporting a vulnerability

If you believe you've found a security problem in relaybell, please email security@relaybell.com with what you found, the steps to reproduce it, and its impact as you understand it. We aim to reply within two business days, and we'll keep you updated while we fix it.

While you look, please:

• only use accounts and websites that are yours, and never access, change or delete other people's data;
• don't run denial-of-service tests, spam, or social engineering against our team or customers;
• give us a reasonable time to fix the issue before you share it with anyone else.

Our contact details are also published in machine-readable form at /.well-known/security.txt. To report spam or phishing sent through relaybell, use Report abuse instead.