Data and Security Statement

How the Software stores, transfers, and protects data

Version 2.13 · Effective 28 September 2026 · Alberta, Canada

Contents

• 1. Data are not collected by the developers
• 2. What is stored, and where
• 3. Photographs that leave the app
• 4. Metadata handling
• 5. Sync between your own devices
• 6. Deletion, and what it does not do
• 7. On-device machine learning
• 8. Apple platform permissions
• 9. Your role

1. Data are not collected by the developers

The OphthoRuler Developers operate no server and receive no Study Data. There is no account, no login, no cloud storage, no analytics, no crash reporting, no telemetry, no advertising, and no third-party SDK that reports on you.

The Software itself makes no outbound internet connection. The only network activity it performs is direct, local communication between your own Mac and your own iPhone when you use Sync. Three things it hands to the operating system can still travel: if you switch on camera-roll backup, iOS uploads those copies to iCloud Photos; a backup destination inside a cloud-synced folder will be uploaded by that service; and the iPhone’s own iCloud or computer backup includes the app’s data. In that backup the photographs and record contents stay encrypted, but the database’s structure (counts, dates, and identifiers) does not. Restoring that backup restores the library but not its sync pairing, which the Software asks the operating system to leave out of backups and which must be set up again. On the Mac, the application’s own folder (the structure database, the sealed photographs, the wrapped keystore, the sync pairing keys, and the internal backup snapshots) is copied by Time Machine and by Migration Assistant like any other files. The photographs and sealed fields stay encrypted in those copies; the database’s structure and the pairing keys do not, and the Software does not ask macOS to leave anything out. Links to model papers open in your browser, which is outside the Software.

ℹ️ What this means for recovery and support

Because the developers receive no Study Data, they have no copy from which to restore a loss and no server-side record with which to investigate an incident.

2. What is stored, and where

All Study Data live in the application’s own folder on your device: a database file plus one file per photograph, stored under Application Support on macOS and in the app container on iOS.

What the database holds

• Studies, folders, participants, encounters, and photograph records.
• Participant study codes, and any free-text demographics, notes, and tags you type.
• Encounter dates and labels.
• Tabular study variables you define and enter.
• Landmark annotations, calibrations, measurements, and measurement definitions.
• Analysis plans, study designs, and installed-model records.

What the photograph files hold

• The full-resolution image, up to 48 megapixels, of whatever you photographed or imported. In practice, that is a person’s face or eyes.
• The file holds pixels only. It is rewritten at ingest with no metadata block at all; the capture date and time, camera model, lens, and exposure are read first and kept in the encrypted photograph record instead (section 4). Photographs the Levator measurement takes with the TrueDepth camera are rendered by the Software itself and carry no camera metadata to begin with.
• On devices with a LiDAR scanner or a TrueDepth camera, a depth map may be stored beside the image: a grid of distance readings, one per pixel, giving the three-dimensional shape of the face that was photographed. It is stored as its own file, encrypted the same way the image is, and it is what lets the Software measure in millimetres without a physical ruler in the frame.
• When Live Photos are turned on (they are off unless you turn them on, for every study or for one), a short, silent movie of about three seconds around the moment of capture is stored beside the image as its own file, encrypted the same way the image is. No sound is recorded; the Software has no microphone access. The movie is a moving picture of the person’s face. Any frame of it can be chosen as the photograph the Software measures, and the frame the camera delivered is kept as well.
• Each file is named by a hash of its own contents, so the same image imported twice is stored once and shared by both records.

What is encrypted, and what is not

Every photograph is stored as an authenticated encrypted container using AES-256-GCM, and so is every field of the study records that carries information about a person. Setting up encryption is part of getting started and cannot be skipped or postponed. The key that opens it is derived from your password by PBKDF2-HMAC-SHA256 at one million iterations, and it wraps a key hierarchy that gives each participant their own key. Each sealed value is bound to the record and the column it belongs to, so that moving values between records inside the raw file is designed to be detected. PBKDF2 is used because it is the only password-based key derivation function in Apple’s own cryptography libraries, which the Software is restricted to; the parameters are recorded alongside each wrapped key so a stronger function can replace it later without re-encrypting your data.

Encrypted: the contents of your records

• Participant codes and any demographics you type.
• Every note and tag, wherever you enter one.
• Study names, folder names, encounter labels, and photograph labels.
• Photograph metadata carried over from the camera.
• Landmark and annotation geometry: coordinates describing a person’s eyes and face. These are sensitive identifiers and may be biometric data under applicable law, depending on how they are processed and used.
• Depth maps, where the device captured one: a per-pixel measurement of facial shape. These are sensitive identifiers and may be biometric data under applicable law, depending on how they are processed and used.
• Live Photo movies, where the study captured them: a few seconds of silent video of a person’s face, identifying in the same way the photograph is.
• Measurement formulas, and measured values with their units and uncertainty.
• The whole tabular study-variable dataset, both the column names and the cell values.
• Exclusion records, the study schema, and the ethics attestation held by any study created under a version that asked for one.

⚠️ Not encrypted: the shape of the database

The Software seals what is inside the records; it cannot conceal the structure around them without abandoning the database technology it is built on. Someone who obtains the raw file, and cannot decrypt anything in it, can still see how many studies, participants, encounters, and photographs exist; the dates attached to them, including when each participant was seen; the internal identifiers linking them together; various yes/no flags; the fingerprints identifying each photograph file; and the names of the measurements the Software itself defines, such as MRD1. For a small or distinctive cohort, that pattern of counts and dates may be informative on its own. On macOS this layer is what FileVault covers; the Software recommends FileVault but does not require it and cannot turn it on for you. On iPhone the operating system protects the file once the device has been unlocked after a restart.

📌 Data recorded before encryption was set up

Photographs and records that pre-date your encryption setup stay unencrypted until a background pass finishes sealing them, and Settings shows how many are encrypted so far. One further step matters: after the records are sealed, the database file still holds remnants of the old plaintext in space it has stopped using, and the Software compacts the file at the next launch to clear them. Until that happens (one launch, automatically), fragments of those values can still be recovered from the file by someone examining it directly. Backups taken before then remain unencrypted snapshots and are labelled as such in the restore list.

⚠️ The developers cannot recover your password

The password and the 12-word recovery code in your Emergency Recovery Kit exist only where you keep them. The OphthoRuler Developers never receive either, hold neither, and can reset neither, and there is no back door or support route. If you lose both, there is no way back to any encrypted photograph, for you or for anyone else. The recovery code on its own opens a backup or a device you have already paired; it cannot restore data to a device that has none. Keep the kit printed and offline: a locked drawer and an unplugged USB drive, never on an internet-connected device and never in e-mail, iCloud, Dropbox, or your photo library.

3. Photographs that leave the app

Several ordinary actions copy participant photographs, or the data recorded with them, out of the Software’s control. Each is worth a deliberate decision.

• Camera-roll backup (iPhone), OFF by default: If you switch this on in Settings → Capture, every photograph you capture is also saved to the iPhone’s own photo library. Once there it is outside the Software entirely, is visible to any app with photo-library access, and will be uploaded to iCloud Photos or any other photo-syncing service you use, which may mean participants’ faces are stored outside your country. Switch it on only if your ethics approval and your consent materials cover it, and record in your study documentation that you did.
• Scheduled library backup (Mac): macOS runs a local backup of the whole library (records and full-resolution photographs) on a schedule, on by default, and only while the app is open. One destination inside the application’s own folder always receives them and cannot be switched off, so a second copy of every photograph exists on that Mac whatever else you configure; any further destination is one you add. Once encryption is set up, destinations default to encrypted and each has its own switch; an encrypted snapshot holds a sealed database, the wrapped keystore, and no study or participant names anywhere in its file paths. That lowers the exposure if the medium is lost or taken (without your password or recovery code it should not be readable), but it lowers that risk without removing it, and it is not a reason to treat any storage location as safe. A destination you mark unencrypted is written in the clear by decrypting on the way out. The Software keeps write access to the folders you nominate so backups can run unattended, and warns you when it detects one inside iCloud Drive, Dropbox, or another synced folder. Adding a location writes to it at once, without waiting for the next scheduled run: choosing a folder in the file picker puts a complete copy of the library there within seconds, with no confirmation step between the choice and the copy existing. A destination that was disconnected when a backup ran is not skipped permanently: as soon as that drive or share is available again the Software writes the backups it missed to it, unattended and without asking. Connecting a nominated drive is by itself enough to place a copy of every participant photograph on it, at a moment you did not choose. Those copies are encrypted unless you marked that location unencrypted, and a catch-up runs only while the vault is unlocked; a locked one waits and writes nothing in the clear. It also runs only for locations that are switched on, and only while backups are on a schedule: a location switched off receives nothing while it stays off, and under manual-only scheduling no catch-up happens at all. Treat neither as protection: switching a location back on, or restoring a schedule, resumes it without further warning. If a location is one you would not leave a plain copy on, remove it. Do not rely on never connecting the drive. How many past backups are kept is a setting you control.
• Switching a location between encrypted and plain: Locations are encrypted unless you switch one to unencrypted, and that choice then stands. A location whose setting you have never chosen is encrypted, so if you need one to stay readable without OphthoRuler, check it; do not assume it. Either way the setting governs only what is written from then on. Snapshots already on that drive stay exactly as they were written: plain ones remain plain and readable to anyone who picks the drive up, however the location is set today. You must separately delete or replace old unencrypted snapshots; turning encryption on does not alter them.
• Choosing an unencrypted destination: Anyone who obtains an unencrypted backup can read every photograph and record in it. That is also the reason the option exists: it stays readable to you without OphthoRuler, without your password, and without your Emergency Recovery Kit, which is the only way back if you lose all three. The two are the same property, so weigh them against each other before choosing this option.
• Share panels (iPhone): The measurement, nine-gaze, levator, and pupillometer panels composite participant images and send them through the system share sheet to whatever you choose, such as Messages, Mail, Files, a third-party app, or a cloud service. Those destinations have their own terms and their own retention.
• Image and figure export (Mac): Exported images, publication figures, and scale-bar composites are written as ordinary unencrypted files. Periocular cropping and censor bars reduce but do not remove identifiability.
• Study archives: A study archive is an unencrypted zip containing the study’s records and the original photograph bytes. Anyone who obtains the file has the photographs.
• Reproducibility bundles: Analysis bundles contain your data table, data dictionary, results, figures, and generated manuscript. Check what a bundle contains before you send it to a journal or a collaborator.
• Photo-library import (iPhone): Importing from your photo library copies the selected images into the Software. The originals stay in your photo library, and in iCloud if you use it.
• The clipboard (Mac): “Copy table”, copying cells from the data grid, and copying a generated manuscript put participant codes and values on the system clipboard as plain text, where Universal Clipboard can carry them to your other Apple devices and a clipboard manager can keep them. The Software marks those copies as concealed so that clipboard managers which honour the mark skip them; not all do.
• File names: The names the Software proposes for exported panels, figures and shared images contain the participant code, and often the study name and the capture date; a study archive is named after the study and the date. A file name is visible wherever the file goes, including in places that never open it.

4. Metadata handling

On import and on capture the Software rewrites every photograph so that it holds only its pixels and no metadata block at all. EXIF, TIFF, IPTC, XMP, GPS, maker notes, and the embedded thumbnail are all removed, and the orientation is baked into the pixels. The result is checked before it is accepted; where the lossless rewrite cannot be verified, the image is re-encoded instead, which carries no metadata either. It records only that the original had location data; it does not record what that data was.

Before the rewrite it reads the capture date and time, the camera model, the lens, and the exposure, and keeps them in the Software’s own encrypted photograph record. Capture times are used to group photographs into sessions.

⚠️ Two limits on metadata removal

First, it happens on import and on capture. Photographs that arrive by study-archive import or by sync are written as received, because they were sanitised on the device that first ingested them; if that device was running an older build, they may carry whatever that build left in. Second, removing metadata is a reduction in risk and is not de-identification: the image still shows a face, and your obligations under clause 13 of the Terms are unchanged.

5. Sync between your own devices

Sync connects your Mac and your iPhone directly, over your local network or a peer-to-peer link between the devices. No server is involved and no data pass through anyone else’s infrastructure.

How it is protected

• Devices are paired using a secret shown on the Mac, then establish a shared key by ephemeral key agreement mixed with that secret, prove possession of it to each other, and encrypt everything after that with an authenticated cipher, separately in each direction.
• Pairing secrets are single-use and expire after five minutes.
• The session key is ephemeral, which is intended to stop someone who records the traffic and later obtains a device key from reading those past sessions.
• Setting up a second device sends the wrapped keystore inside that encrypted session; the second device finishes setup by entering the password you already chose. Two devices that each created their own separate vault will refuse to sync rather than merge, and say so.
• A paired device can ask the Mac for any study the Mac holds. The Mac is designed to serve only studies that are not archived, so archiving a study on the Mac also takes it out of what a paired device can fetch until you unarchive it.

Limits of sync protection

• Pairing by typed code uses a much shorter secret than pairing by QR code. An attacker who is on your network and records the pairing exchange within its five-minute window could, with enough computation, recover the session. Use the QR code where you can.
• Long-term device keys are stored in a permission-restricted file in the application folder, not in the system keychain. Anyone who can read your files can read them.
• The transport is encrypted; at either end the data are protected only as section 2 describes: record contents and photographs sealed, the database’s structure readable.
• Sync makes each device’s library match the other. It can overwrite or delete records on one device based on the state of the other, and the archive hand-off deletes the iPhone’s copy of a study once the Mac reports it has the data.

6. Deletion, and what it does not do

⚠️ Deleting inside the app does not erase the photograph

Studies, participants, encounters, and photographs are hidden and retained so they can be restored. The image file stays on disk. If a participant withdraws consent, hiding their record does not remove their data and does not discharge your obligation to erase it. Deleting a single photograph is ordinary file deletion and is not cryptographic erasure.

To actually erase image bytes, you must use the permanent-erase function in Organise Library on the Mac. This cannot be undone. Because photographs are shared by content, the bytes are removed only when no remaining record refers to them.

ℹ️ Erasing a participant destroys their key

Each participant’s photographs are encrypted under a key of their own, and erasing the participant destroys it. Every encrypted copy that key protected should then stop being readable, whether or not the files themselves are deleted. This applies on this device, on the device you sync with once the change reaches it, and in encrypted backups restored after the erasure. This is the closest the Software comes to erasure that reaches copies you cannot physically find. It rests on the encryption holding, which is not something the OphthoRuler Developers can guarantee.

ℹ️ Restoring an older backup does not undo an erasure

The Software keeps its record of erased participants outside the encrypted store, so it survives a restore, and puts a copy of that record (participant identifiers only) into every backup made after the erasure. A device learns of an erasure by performing it, by syncing with a device that did, or by restoring any backup made after it, and from then on it re-applies that erasure to any key list it is given, before those keys are ever used. Restoring an older backup on such a device, or receiving a stale key list over sync from one that was switched off at the time, leaves the participant unreadable. The same record governs what is copied to a drive that has been away: when a location is caught up, any snapshot that does not already carry every erasure this Mac knows about is withheld rather than written, so reconnecting an old drive cannot backfill pre-erasure material onto it.

📌 Cases erasure does not cover

A machine whose only contact with the data is material from before the erasure has never learned of it. A fresh computer restoring an old backup on its own terms has no record to apply, so it carries the pre-erasure keys and can open them. Destroying backups made before an erasure therefore remains part of a complete withdrawal. Separately, nothing cryptographic touches unencrypted copies at all: plain backup destinations, exports, figures, archives, shared files, and camera-roll copies must still be found and deleted by hand.

📌 Copies outside the Software must be erased separately

Erasing inside the Software does nothing about the copies made elsewhere: scheduled library backups and every retained snapshot in them, camera-roll and iCloud copies, exports, figures, archives, reproducibility bundles, shared files, operating-system device backups, and the other device you synced to. When a participant withdraws, every one of those has to be found and erased. Tracking them is your responsibility, and much easier if you decide where copies may go before you start.

7. On-device machine learning

Landmark placement and iris and pupil segmentation run entirely on your device using models bundled inside the app. No image and no model output is uploaded anywhere, and no model learns from your data. The bundled models are fixed and are never trained, fine-tuned, or updated by your use. The Software contains no training capability.

Two further face-processing steps run live on the iPhone, on the device, and store nothing of their own. While the capture screen is open, Apple’s Vision framework reads the head’s pitch, yaw, and roll off the camera preview a few times a second so the screen can warn when the face is not square to the camera; each frame is analysed and discarded, and no reading is kept. During the TrueDepth levator capture, Apple’s ARKit tracks the face continuously; the eyelid landmarks and the depth map the Software stores for that capture are derived from that tracking, and nothing else from it is retained.

Model provenance, versions and licences are listed in the Third-Party Notices and on each model card in the app.

8. Apple platform permissions

• Camera: Used to take study photographs, and only while you are capturing.
• Photo library: Used to import images you select and, if the camera-roll backup setting is on, to add copies of your captures.
• Local network: Used to find and connect to your other device for Sync, including directly between devices without a shared network.
• Files you select: On macOS, read access to files and folders you choose to import, and write access to any folder you nominate as a backup destination. Write access to a backup destination is retained across launches so that scheduled backups can run without asking again.
• Face ID or Touch ID: Used only to open the optional app lock on that device. The operating system answers yes or no; the Software receives no biometric data.

The Software requests no other permission, and asks for none of contacts, location, microphone, health data, or tracking.

The key that unlocks each device

The key that lets you unlock once per device, rather than typing your password at every launch, is held only in the system keychain, marked for that device only and never synchronised to iCloud. The Software writes it nowhere else. If the keychain will not hold it, nothing is stored at all and that device asks for the password at every launch; there is no file on disk either way. Settings ▸ Security shows which of the two states a Mac is in, in its “Unlock key” row, so you can check it there.

FileVault, on macOS

⚠️ FileVault is recommended but not required, and the Software cannot turn it on

Encryption setup does not check FileVault, does not refuse to continue without it, and never enables it: it is a system setting only you can change. Setup ends by recommending it and offering to open the relevant system settings. Settings ▸ Security then re-reads the status every time you open it and shows what it found (on, off, or that it could not be checked), and when it finds FileVault off it says so and offers the same button. Where the status cannot be read, the Software says so plainly and gives you no assurance either way.

📌 If FileVault is off

A Mac holding this data without FileVault leaves the structure of the database (the counts, dates, and identifiers described in section 2) readable to anyone who can read the disk, along with the device pairing keys described in section 5, which are held in a permission-restricted file rather than the keychain, and anything else on that disk the Software does not encrypt. Nothing in the Software reduces that exposure. Only you or your administrator can enable and maintain FileVault.

9. Your role

📌 Your role in data governance

As between you and the OphthoRuler Developers, you are the controller, custodian, and steward of everything you put into the Software and are responsible for obligations to participants, institutions, and regulators. The Software runs on your devices; the OphthoRuler Developers receive no Study Data, hold no copy and perform no processing on your behalf. On those facts, they provide software rather than acting as your processor or joint controller. Legal status ultimately depends on applicable law and the actual circumstances. If they were ever to process personal data for you, an agreement meeting the requirements of your law would be put in place first.

This statement describes the Software’s behaviour at the revision shown above. Behaviour may change in later versions; re-read it after an update.

Text fingerprint (SHA-256): a70280ec4885b6c04aefeb8fd8138d83ec32c830bca144346bc1258b4a75b2e6