Security architecture and data flow

1. Scope and security model

This document describes the current technical data flow and safeguards. It is not a certification, penetration-test report, NHS assurance, clinical-safety case or guarantee. The core model is local-first: the app stores one encrypted vault on the device and contacts optional third parties only when the user invokes those features.

2. Trust boundaries

The main boundaries are the unlocked device and browser/webview; encrypted local storage; source files and camera roll; exported files and clipboard; Google authentication and Drive; the selected AI provider; the website host; and support email. Moving data across any boundary can change who can access it and which legal terms apply.

3. Vault encryption

The current format encrypts vault JSON with AES-256-GCM. A 256-bit key is derived from the user passphrase using PBKDF2-HMAC-SHA-256 with 600,000 iterations and a random salt. AES-GCM uses a unique random IV for the encrypted payload and authenticates the ciphertext so alteration normally causes decryption failure.

Cryptographic strength does not compensate for a weak passphrase or compromised endpoint. RQAI does not hold a recovery key.

4. What is inside and outside the encrypted envelope

Case content, settings and saved attachments are held in the encrypted vault. The configured AI API key is inside the local vault. A versioned terms-acceptance record and limited synchronisation metadata are stored separately on the device. When unlocked, decrypted data exists in application memory.

5. Authentication and auto-lock

The vault passphrase is the local secret used to derive the encryption key; OrthoLog does not operate a user account or remote password reset. Auto-lock reduces unattended exposure but does not replace the device screen lock. Browser, operating-system and biometric unlock behaviour remain controlled by the platform.

6. Google Drive data flow

After user authorisation, a temporary Google token permits the drive.file operations used by the app. The vault is encrypted before upload. The AI API key is removed from the synchronised state. Downloaded ciphertext is decrypted locally only after the correct passphrase is available.

Encryption hides content from ordinary Drive access but not file size, timing, account, network or access metadata. Drive account compromise may allow deletion or replacement of ciphertext.

7. AI data flow

When confirmed, selected image bytes and a prompt travel over HTTPS directly to the provider API. The provider can see the plaintext input needed for inference. The result returns as generated text and is reviewed locally. Vault encryption does not cover data while the provider processes it.

8. Exports and backups

The .ologbook backup preserves the encrypted envelope and excludes the AI key. CSV and portfolio exports are plaintext unless the user protects them separately. Filenames, recent-file lists, thumbnails, print queues and cloud-device backups can disclose metadata or content outside OrthoLog.

9. Web and native distribution

The production website is served over HTTPS. The PWA caches app assets for offline use; an installed PWA remains bound to the site origin. Native packages embed the same web application. A macOS public release should be Developer ID signed, notarised and stapled. An Android APK must be release-signed; future updates must use the same signing key.

10. User security baseline

• Use a supported, patched device with full-disk encryption and automatic screen lock.
• Use a strong unique vault passphrase and store it in an approved password manager.
• Do not share a browser profile or unlocked device.
• Avoid untrusted extensions, rooted/jailbroken devices and unofficial installers.
• Verify release source, version and SHA-256 checksum.
• Use approved accounts and enable multi-factor authentication for Google and AI providers.
• Test an encrypted backup and keep an independent authorised copy of essential evidence.

11. Threats not eliminated

Controls do not eliminate shoulder-surfing, screenshots, camera-roll copies, clipboard capture, malicious extensions, endpoint malware, keylogging, weak passphrases, compromised accounts, supply-chain attacks, provider access, traffic metadata, coercion, user error, denial of service, device loss while unlocked or future cryptographic weaknesses.

12. Data deletion limits

Deleting a case removes it from the active vault state and the next saved ciphertext, but browser storage, operating-system backups, synchronised copies, exported files, source images and provider logs may remain. Secure deletion on flash storage cannot be guaranteed by a web app. The user must delete every relevant copy under the applicable retention policy.

13. Vulnerability and incident reporting

Report a suspected OrthoLog vulnerability to hello@rqai.co.uk with a clear description, version and reproduction using mock data. Do not test against another person, disrupt the live service, access data without authority or attach secrets. For patient-data incidents, use the relevant organisation’s formal incident route first.

14. Security assurance and deployment decision

Before any institutional or identifiable-data use, the deploying organisation should conduct proportional due diligence, including architecture review, DPIA, supplier and transfer assessment, clinical-safety and medical-device boundary review where relevant, mobile/device policy review, penetration testing, incident planning, retention and exit planning. Publication of this document is transparency, not approval.