Bronwin

Security

The security model

What sits on our servers, what doesn’t, and the one part of this you shouldn’t take our word for.

The two locks

Two locks: the device and your PIN

The first lock is the device. At setup, the phone generates a key inside the same hardware that protects a fingerprint and a payment card — the Secure Enclave on iPhone, the hardware-backed keystore on Android. That key cannot be copied off the device, and it never loads into the app’s memory even to do its job: the chip performs the unwrap itself and hands back the result.

The second lock is a PIN you choose. It is never sent to us and never leaves the phone. Both parties have their own.

No PIN Opens immediately
  • The board itself
  • The history — colors, shapes, numbers, dates
  • Logging something new
  • The crisis numbers
PIN required Stays sealed
  • What each color means
  • Every note either of you wrote
  • Your patient’s name, on your device
  • The PDF export

What we can see

What is on our servers

If someone took every server and every backup tomorrow, what they would have is a pile of ciphertext and a count of how many patients each provider has. Below is the whole of it, on both sides.

On our servers
  • Ciphertext we hold no key for — not “encrypted but we have the key.” We have never had one and there is no mechanism by which we could get one.
  • Your name, license, and email. You’re a professional using a business tool; that part is ordinary.
  • A count. Something like this provider has 47 patients.
  • Roughly when data arrived, to the hour.
Not on our servers, in any form
  • Your patient’s name. We never ask for it and there is nowhere to put it.
  • Their email address or phone number. Same.
  • Which colors were pressed, or how they were rated.
  • Anything either of you wrote.
  • What any color means.
  • Any way to work out which of your patients is which — or that two of them are the same person seeing another clinician.
What your patient typed

Sat with it 20 min. Didn’t check the lock. Came down on its own.

What reaches us

 

The severity, the timestamp, and which button it was are sealed the same way. The server authenticates the caller, moves the blob, and enforces who may read it. It performs no cryptography over your content at all.

The one thing we can’t do for you

Verifying your connection in person

Everything else — the invite link, the setup, the syncing — passes through our servers. If we were dishonest, or ordered by a court to be, we could in principle insert ourselves into that first key exchange and read everything after it. No amount of clever engineering on our side rules that out, and you shouldn’t take our word for it.

So the first time you meet after connecting, both screens show the same number. Read it to each other. It’s computed from the keys on your two phones — if anyone had inserted themselves, the numbers wouldn’t match, and we can’t fake it because the comparison happens between the two of you and never touches us.

● Unverified
482119057317264380956241077138059263148084617293505607213845

Shown on both screens until you confirm it matches. After 30 days without the check, the connection pauses until you do it.

Until it’s done, both screens carry a warning that can’t be dismissed. That friction is deliberate: this check is the only part of the system that doesn’t require trusting us, which makes it the most important part.

If either of you replaces a phone, a new number appears and you check it again.