What each connection sends

1 · Sign-in

You sign in to the Palomar account through the browser or with your phone, by a QR code; the app never asks for your password. On this connection the app sends the Palomar web platform: its client id, the sign-in’s verification code (PKCE) or the code shown on screen for the phone, the refresh token, a proof signed with the installation’s key (DPoP), a generic installation label — “Palomar Countermark · <system> · <architecture>” — and the app’s version.

It sends at sign-in and when the token is refreshed. The installation label carries no computer name, no user name and no address.

Signing in does not move the ledger: the account identifies you, and the file stays on your computer.

2 · Updates, the licence and the security advisories

On one connection, the app reads the list of published releases and its signature, the keys they are verified with, the freshness statement of the releases and the list of security advisories. For these it sends nothing beyond the request itself.

For the licence — at activation and at validation — it sends the access token, its proof (DPoP) and the app’s version. Security updates never depend on the licence.

It checks at start, then every six hours. An update’s file is downloaded from the downloads page, from the address the signed list names.

3 · Sync

Sync is off until you switch it on for a ledger; while it is off, the app sends nothing on this connection, and the Connections screen says so.

With sync on, the app sends the Palomar web platform the access token with its proof (DPoP), the workspace’s id, the changes to that ledger’s records and the evidence files attached to them, encrypted on the platform under a key of the workspace.

The synced copy is yours: you switch it off and delete it at any time from your workspace, and the file on your computer stays untouched.

4 · The public timestamp

At the end of each day with records, the app closes the day into a day statement and sends its hash — 32 bytes and nothing else — to two of the four public timestamp calendars pinned in the app, chosen at random. No record, no name and nothing of the company’s data reaches a calendar.

It sends once a day, after the day closes, then repeats the request until the proof is complete. The request names neither the product nor its version. You can switch the public timestamp off for a ledger: the day statements are still signed, but a day closed while it is off is never stamped later.

Anchoring on the public ledger through the Palomar web platform, and verification through an RPC endpoint you choose, are not part of version 1.0.0.

5 · The backup sources

Each source is a documented connector, with the hosts you entered yourself: a local or mounted folder (no network), a host over SSH, an S3-compatible store. The tools on your computer — restic, BorgBackup, Kopia — reach only the repository you configured.

This connection carries the source’s own protocol, with the read-only credentials kept in the system’s keyring; never a Palomar token and never a record of the ledger. The credentials reach the connectors’ process alone, which has no access to your account.

It reads on the schedule you set and on demand. What each connector reads and which rights it asks for is described on the connectors page.

A database test for MySQL or MariaDB loads the dump into a container started through Docker or Podman on your computer; pulling the image, after your consent, is the container engine’s traffic, to the registry the app shows you beforehand, not the app’s.

How the app keeps the list

The app keeps two lists of hosts: the ones pinned in the app — Palomar’s hosts for sign-in, updates and downloads, and the public timestamp calendars — and the ones you declared — each source. Every request carries its purpose, 1 to 5, and a request to a host outside the two lists is refused and written to the security log. The app’s screens have no network access.