- 01
Capture inside the app
Photos and videos originate in FactLockCam. The system camera roll is not the source of the sealed original. Optional location can be recorded with the capture metadata.
- 02
Fingerprint and signed manifest
The app computes SHA-256 over the media bytes and signs a canonical manifest that includes the fingerprint, file length, MIME type, UTC capture metadata, signing address, optional Polygon lower-bound block, and device-key class. The device key class is disclosed. The device key is hardware-backed where the phone has it (Secure Enclave on iOS; StrongBox or TEE on Android). The owner signature is made with a software key held in the phone's secure storage. Neither is hardware camera attestation.
- 03
Independent existence window
When network access is available, the manifest hash can be anchored to Polygon. The later bound is the block that included that transaction. Offline captures have no earlier bound. The displayed window is not a claim that the photographed scene occurred at a specific instant.
- 04
Encrypted archive under your control
Media is stored as an encrypted .seal on the device. Only you hold the keys; a .factlock backup carries them to a new phone.
- 05
Portable package, local unlock
Send Proof writes one .flcproof file and an unlock link. A recipient opens the link and chooses the file. The page unlocks it. They do not type a password. Auditors with a bare proof.json can use /verify. The file, signature, and public-record checks then run as three separate results. That is for a small proof. A large proof opens in the free FactLockFile desktop Viewer, coming for Mac, Windows and Linux once each version is tested.
- 06
Scope of a passing check
Verification confirms the exact file and the signed record. The full ceiling, including what a passing check does not establish, is on the threat model page and in the Terms of Service.
Recipients open /open; auditors
with a bare proof.json use
/verify.
