Security — Dawn

This page describes how Dawn is actually built. It lists the controls that exist, and is deliberately quiet about the ones that do not — a security page that claims more than the system does is worse than no page at all.

The short version. Dawn holds an opaque Apple conversation identifier and your messages. It never receives your phone number. It does not hold passwords, card numbers, or anything from your phone beyond what you text it. Everything moves over HTTPS, and inbound webhooks are rejected unless they arrive from our messaging provider's published network on an endpoint whose address is itself a secret.

In transit

Every connection is HTTPS — the site, the API, and every call out to a service provider. There is no plain-HTTP path into Dawn.

Secrets

API keys, database credentials, and webhook signing secrets live in environment variables on the host. None are committed to the repository. Nothing in the source tree contains a working credential.

Proving the account is yours

Dawn no longer verifies a phone number, because it no longer has one. Apple does the identification: a conversation with a business is bound to the device and Apple ID that opened it, and Apple hands us only an opaque conversation identifier — never your number, Apple ID, or email.

That identifier is the account, and it is learnable only from a message you send. Dawn cannot open a conversation with someone who has not written first, so there is no way to be enrolled without acting, and no way to enrol somebody else.

The honest trade: Dawn has given up its own proof of possession and now relies on Apple's. In exchange, a class of abuse disappeared rather than being defended against — there is no send-a-code endpoint to pump, no code to intercept, and no number to recycle to a stranger.

Inbound webhooks

Anything that can start a conversation and send a message is an entry point worth attacking, so it is authenticated. Apple's messaging providers do not sign their webhooks, so signature verification is not available to us and this page will not imply otherwise. Three independent controls stand in its place:

The endpoint's address is itself a secret — a random path segment that appears in no link, no page, and no repository. Guessing it is the first thing an attacker would have to do.
Requests must arrive from our messaging provider's published network ranges. The client address is taken from the last hop of the forwarding chain rather than the first, because the earlier entries are written by whoever is calling and can say anything. A forged header does not move the check.
Each inbound message is claimed exactly once before it is processed, so a message that arrives twice — including on the provider's week-long retry schedule — cannot produce two replies.

If the allowlist or the path secret is missing, the endpoint refuses every request rather than falling open, and says in its logs which control refused and what would fix it. A control that switches itself off when a setting goes missing is not a control, and a refusal nobody can read is not much better.

Administrative access

Administrative endpoints are disabled unless an admin token is configured, and then require that token. There is no admin login, no session cookie, and no password to steal.

What Dawn deliberately does not do

No payment data. Dawn does not take payments, so there is no card data to lose.
No passwords. There is no password to reuse, leak, or phish. The conversation is the account.
No selling of data to anyone, for any purpose.
No advertising or ad targeting, and no third-party analytics or tracking scripts on this site.
No access to your device. Dawn has no app, so it has no contacts, camera, microphone, photos, or location.

What is not claimed

Dawn is an independent service that has not been through SOC 2, ISO 27001, or a third-party penetration test. It has no security team. Saying otherwise would be easy and untrue. What it has is a small attack surface and controls that are actually implemented, which the section above describes precisely.

Reporting a problem

If you find a security issue, email dylan@heydawn.ca. Include enough detail to reproduce it. You will get a reply, reports are welcome, and nobody acting in good faith will be pursued for reporting one. Please give a reasonable window to fix it before publishing.

A note on this document. Every control described here was verified against the source code rather than assumed. It has not been reviewed by a lawyer or an external auditor.