Security

What is protected, and from what.

A finance application deserves a stated threat model rather than reassuring adjectives. Here is what beatrax defends against, and what it does not.

What it defends against

A compromised or hostile relay

The sync relay only ever holds ciphertext it has no key for. Operating one grants no read access.

Someone on your network

Device-to-device sessions are mutually authenticated and forward-secret, so a passive listener learns nothing and cannot replay later.

A stolen laptop

With the app-lock on, sensitive fields are encrypted at rest and the key is only released by your PIN or biometric.

A device you no longer trust

Removing it rotates the group key and re-wraps to the rest, cutting it off from everything sent afterwards.

A malicious statement file

The XML parser refuses all external entities, so a crafted CAMT file cannot read your filesystem or reach the network.

Data leaking to us

Structurally impossible: there is no telemetry and no backend to receive it.

What it does not defend against

  • Malware already running as you — Software running with your privileges on your own machine can read what you can read. No application-level encryption survives that.
  • A weak passphrase — At-rest encryption derives from what you choose. A guessable passphrase is a guessable key.
  • Losing everything at once — No devices and no backups means no recovery. Nobody holds a copy — that is the same property that keeps it private.
  • What your bank or mail provider knows — beatrax cannot change what they already hold; it only avoids adding another party.

How it is kept honest

  • Static analysis at the strictest level — The whole codebase is analysed at the maximum strictness the tooling offers, on every change.
  • Architectural invariants are tested — Rules like module boundaries and the encryption field registry are enforced by tests, so a regression fails CI rather than shipping.
  • The specification is public — The threat model and the security requirements live in the spec repository, not in marketing copy.

Reporting something

If you have found a vulnerability, please report it privately through GitHub's security advisory flow on the product repository rather than opening a public issue. The security policy in the organisation's community files sets out the response timeline.