Bronwin Early access

Security

What we hold, and what we could never hand over.

Stated precisely, including the part we can't prove to you and the check that closes it.

The two locks

You need the phone and the PIN. Either one alone is useless.

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

If someone stole the entire database tomorrow.

Every server, every backup. What they would have is a pile of ciphertext and a count of how many patients each provider has. That sentence is meant literally, and the whole architecture exists to keep it true.

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

Fifteen seconds, in person, once.

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.