Security and privacy¶

Arca holds sensitive data: identity numbers, contracts, health records, scans of your documents. This page says what Arca protects, what it leaves to you, and what to check before exposing it to the Internet.

What is not encrypted¶

The database and the documents are stored as they are on disk: they are not encrypted, health data included. Anyone who can read the disk can read them: whoever has access to the computer, the Docker host, the volume or a copy of it. This is a deliberate choice: encrypting the disk protects the same data, with tools made for it, and keeps Arca simple. This includes the text of PDF documents (kept for the search).

Encrypt the disk that holds Arca's data: LUKS on Linux, BitLocker on Windows, FileVault on macOS, the encryption of your NAS or of your virtualisation host.
Treat the server's administrators as people who can read everything.
A document you delete is erased from the disk, but the backups made before keep it until their rotation removes them.

What is encrypted¶

Backups and exports are encrypted with your recovery key, shown once when you turn backups on. The server keeps only the public half of the key: it can make archives, not read them. Any storage will do for the copies, a consumer cloud service included.

Keep the recovery key away from the archives: in a password manager, or printed (the emergency kit).
A lost recovery key cannot be recovered: the archives can no longer be opened.

See Automatic backups and Off-site copies.

What leaves Arca¶

Nothing, except what you set up: no telemetry, no update check, no outgoing network call.

The photo of an identity document that you give to Quick add is read on the server by Tesseract, a program installed with Arca: it is never sent anywhere. Until you save the record, the photo waits in a temporary folder that the backups do not include; it is deleted when the record is saved, or after 24 hours if you abandon it. Of what is read, Arca keeps the name, the expiry date, the document number and the issuing country: the birth date, the nationality and the sex are neither kept nor shown.

The calendar feed is the one exception you choose to make. Its content is kept to a minimum: the record's title, the action, the dates and the category, never the reference number, the amount, the organization or the notes. But the calendar that subscribes to it (Google Calendar, Apple, a phone app) sees and keeps those titles.

The feed's address works without a password: treat it as one. If it leaks, regenerate it on the Calendar page; the old address stops working.
Per-person feeds follow the same rule.

See Calendar feed.

Arca has one account, and it sees the whole household's data. Share it with nobody you would not show every record to.

HTTPS as soon as Arca leaves your local network: behind a reverse proxy, with ARCA_HTTPS on.
Login attempts are limited per address. Behind a reverse proxy, set ARCA_TRUSTED_PROXIES to the proxy's address, otherwise every failure counts for the proxy, shared by everyone.
Two-factor authentication (page Security) for an installation reachable from the Internet without a proxy that already asks for a second factor. It is not needed on a local network.

See Login security.

Checklist for an installation reachable from the Internet¶

[ ] The disk holding the data is encrypted.
[ ] Arca is reached over HTTPS only, with ARCA_HTTPS on.
[ ] ARCA_TRUSTED_PROXIES names the reverse proxy's address (the Integrity page warns when it is missing).
[ ] Arca's port is published to the proxy only, not to the whole network.
[ ] Two-factor authentication is on, unless the proxy already asks for a second factor.
[ ] The password is long and used nowhere else.
[ ] Automatic backups are on, with a copy off the server, and the recovery key is stored apart.
[ ] Arca is kept up to date.

Desktop application¶

The desktop application (planned) will keep its data on your computer, not encrypted either: encrypt the disk. Its optional lock only hides the window: it encrypts nothing.