Privacy and security model

Your files are de-identified and encrypted in your browser. The server stores data it cannot read. This page explains how, and where the promise ends.

De-identification happens on your device

Before anything is uploaded, the browser removes identifying metadata from every file:

• DICOM follows the PS3.15 Annex E Basic Application Confidentiality Profile, plus the options the project chose (keep longitudinal dates with a shift, keep age and sex, clean descriptions). Private tags are removed. UIDs are replaced with values keyed by a project secret, so the same study uploaded twice maps to the same new UIDs.
• NIfTI and NRRD headers lose their free-text fields.
• Photographs lose EXIF, XMP, IPTC and GPS metadata.
• Signals keep their samples as recorded: EDF and BDF files lose the patient and recording identification, the start date and time and their text annotations; WFDB records lose their comments (age, sex, diagnoses, medications), base time and date, and record and file names.
• File names are replaced by random IDs.

The upload screen shows what was removed from each file before you confirm. Patients get pseudonym codes assigned by their site, or generated from the project’s pattern (the site’s code and a number, such as MODENA-0001); the real identity, and the mapping from it to the pseudonym, never enter the platform.

Pixels are your responsibility. Text burned into images, faces in head scans and name tags in photographs are not removed automatically. The upload screen flags modalities and files known for burned-in text, and for ultrasound shows where the scanner’s calibrated region lies (the names and dates are usually outside it); the project admin decides what may be uploaded. Check pixels in the review previews an image of a series, finds text in it (on your device; it can miss text) and lets you draw masks: rectangles blacked out in every image of the series before it is encrypted. Masks apply to PNG and uncompressed DICOM; JPEG, HEIC and compressed DICOM must be converted first, since masking them would encode their pixels again. HEIC photos are uploaded as HEIC, with their metadata removed. Head CT and MRI can be defaced by a processor, when the installation offers one. The same holds for surface scans: a mesh’s header, names and comments are removed, but a face scanned in 3D stays recognizable.

Encryption and keys

• Each project has its own key. Its private half exists only on members’ devices: it is wrapped to each member’s public key and unwrapped in the browser.
• Each file and each annotation has its own key, derived from or sealed to the project key. Files are encrypted in 64 KiB chunks, so viewers download and decrypt only what they show.
• Your own keys are generated in your browser at your first sign-in, and that browser becomes a trusted device. The server keeps them only inside an encrypted bundle that a trusted device or your passkey opens.
• Signing in takes an email code and nothing else; unlocking data takes a trusted device or a passkey. A new browser is approved from a trusted one: you compare a 6-digit code on both screens. A stolen mailbox gives an attacker an empty account.
• If you lose every trusted device and passkey, you start over with new keys. Your project admins share each project with them only after comparing a safety code with you, and your other sessions and your email address are told that your keys were replaced.
• In the browser, private keys live in one isolated worker, and decrypted data stays in memory: it is never written to disk caches or browser storage unencrypted. Work in progress that autosaves on the device (answers, shapes, mask strokes) is encrypted under the project key first.
• All primitives come from audited libraries (libsodium, WebCrypto, HPKE as in RFC 9180). The container format, YGG1, is published with test vectors.

Membership is signed

Project admins sign every change to a project’s membership, keys, manifest and processors. Each browser verifies this signed log and pins the project’s first admin on first contact, so the server cannot add a member, swap a key or change the manifest without the clients noticing. When a member’s key changes, for example after they lost their devices, an admin compares a short safety code with them out of band before sharing the project key again. The code covers both people’s keys and the first record of the project’s signed history, so it also tells whether both see the same project. It does not cover the records since: a browser that sees the server hold back or rewrite records it already verified stays blocked until the server serves the whole history again, whatever code is compared.

Answers are signed by their authors

Every member signs each answer they save with their own key, in the browser, over the answer’s encrypted content and what it is about. The project’s members all hold the project key, so the signature is what tells who wrote an answer: browsers and exports check it against the signed membership log. An answer whose signature is missing or does not match the member the server names is shown as Author not verified and is left out of consensus, corrections and exports. A member who starts over or leaves keeps their earlier answers verified: their old key still counts for what was written before it was replaced.

Processors get the least access that works

An external processor receives only the keys of its job’s inputs, sealed to its own public key; the browser that starts a job grants only inputs it verified to lie inside the job’s target. A project admin can instead grant a processor the whole project key; every member then sees a badge saying so. Processor results arrive as proposals for people to correct, unless a task is set to take them as they are.

A processor is given the project’s root (the hash that starts its signed history) by the admin, out of band: it refuses any other history, and the keys granted to it open only under the real one. Everything it writes is signed with its registered key, and members’ browsers check that signature before showing or accepting a result. See the processor SDK quickstart.

Exports leave the encryption, on purpose

Only project admins export. An export worker the project registered decrypts exactly the data the admin chose and writes a plain zip, kept behind a link until it expires (1 to 30 days) and then deleted. With this server’s export worker, the operator can see the data while it is packaged, and the archive is readable on the server until it expires; a worker the institution runs keeps the host out. The admin is told which before confirming, and the audit log records every step. See Exporting data.

Open projects are not end-to-end encrypted

A project admin can make a project open when it is set up, before its key exists: for public data only. The server then holds the project key and gives it to members itself, so the operator can read everything in that project. It also lets invitees in as soon as they set up keys, without waiting for an admin to open the app: it can admit only people an admin invited, never as admins, and never change a member’s keys. Removing a member of an open project does not change its key. Data is still de-identified on your device and encrypted at rest, and the choice is signed into the project’s history, where every member’s browser sees it; it can never be undone, and a project keyed end-to-end can never be made open. Every open project shows the badge Not end-to-end encrypted — public data; every other project shows End-to-end encrypted.

What the operator can see

The server needs some plaintext to route data, enforce permissions and report usage. It sees:

• accounts: email addresses, sign-in times and devices;
• projects: title, public summary, members and their roles, quotas, the manifest;
• data: how many patients, studies, series and files there are, their sizes, modality types, upload times and site;
• annotations: who annotated what and when, task progress and status, but not the content.

Clinical values, pseudonyms, descriptions, images, annotation content and processor logs are encrypted.

The honest limits

• Visible metadata. Sizes, counts, timing, modality types and task progress are visible to the operator, as listed above. The length of encrypted data reveals the length of what it encrypts.
• Site scoping inside a project is enforced by the server only. Every member of a project holds its key.
• Removed members may keep keys or data they cached before removal. Removing a member rotates the project key for new data (not in an open project, whose key the server holds anyway), but an operator working with a removed member could keep the other members writing under the old key by hiding the rotation from them.
• The server delivers the web app. A malicious operator could ship altered JavaScript. The app’s scripts carry Subresource Integrity hashes (the browser does not check those of its workers), the web build is reproducible from a release tag, and releases are signed with published hashes, so anyone can compare what a server sends with the release (verify what you run). Nothing in the browser checks the page itself; self-hosting removes the need to trust another operator.
• First contact with a project or a member’s key is trust on first use, and the server can tell which browsers are on first contact. Safety codes let people verify keys and the project’s history out of band.
• A trusted device unlocks the keys for anyone who can use that browser profile. Locking only clears the keys from memory; remove the device, or never trust shared computers. Script running in the app on that profile (an injected script, a malicious dependency) could copy the keys for good.
• Invitees’ email addresses are in the project’s signed history, which every member and processor reads.
• The email code alone can start over. Whoever takes over your mailbox can give your account new keys. They open nothing until an admin of each project compares a safety code with you, so never confirm a safety code you did not see yourself, and tell your admins if you get a notice you did not expect.
• An approved device gets your keys. Approve only your own devices, and only when both screens show the same code.
• Open projects are readable by the operator, by design (above).
• Export archives are not encrypted. Until it expires, an archive on the server can be read by whoever holds its link (and its code, when the link has one), by the operator, and by anyone with access to the server’s storage.
• Lost keys mean lost data. If every admin of a project loses access to their keys, nobody can recover the data, including the operator. Projects need at least two admins, and members should keep a second trusted device or a passkey.

Reporting a vulnerability

See the security policy.