Security

How we protect the record

If the product is evidence, the handling of it is the product. This page describes what actually happens to a submission, who can reach it, and the things we deliberately do not do.

The link opens the phone’s rear camera directly. There is no gallery step in the flow, so the photo is taken live rather than chosen afterwards.

When the submission arrives, our server writes the time. It does not read the time from the phone, so a device clock cannot decide what a record says. The image bytes, that server-set time, the coordinates when the worker shares location, and the storage path are then sealed together under a single SHA-256 fingerprint. Change any one of those afterwards and the fingerprint stops matching, which is what makes a later edit detectable.

The wording is exact on purpose, and it is the same wording we use on our About page: the record is tamper-evident, not tamper-proof. A fingerprint shows that a record was not altered after it was captured. It cannot speak to whether the world was honest in the instant the shutter fired, and we will not claim it does.

• One company’s data stays with that company. Row Level Security is enabled on the tenant tables in the database itself, so isolation does not depend on the application remembering to filter.
• Worker links expire. The link in a worker’s text is a short random code that stops resolving once its window closes. Opening it mints a second, signed, short-lived token for the submit page itself, and that token is stored only as a SHA-256 hash. The code in the text message is stored as it is written, so treat it the way you would treat any link that opens something: it works for whoever holds it, until it expires.
• Evidence pages are kept out of search. Proof, portal, packet and worker submit paths are disallowed in robots.txt, and the display surfaces additionally return a noindex header, so a shared link cannot quietly end up in an index.
• Signed-in pages are served no-store. The app’s authenticated routes are sent with caching switched off, so a logged-out browser cannot page back into a stale copy of somebody’s dashboard.
• The browser is told what the site may use. Camera and location are permitted only to LockProof itself, because the submit flow needs them; microphone, payment and USB access are switched off outright. Connections are HSTS-pinned to HTTPS.

No third-party trackers on these pages. The only analytics on the marketing site is Vercel’s own, first-party, and it is wired to an allowlist rather than an exclusion list: a page earns a pageview by being named, instead of somebody remembering to leave it out.

That distinction is load-bearing. On a worker or client link, the address itself is the credential. An analytics beacon mounted everywhere would have posted live submit and portal links into a dashboard as a matter of routine. It is not mounted everywhere, and a test in our suite covers that allowlist and has to pass before we ship.

Workers never get an account. There is no app to install and no password to create or leak, because there is nothing for a worker to sign in to.

A security page that only lists wins is marketing. These are the honest gaps, and we would rather you read them here than discover them.

• We hold no SOC 2 report and no ISO certification. We are a small company and have not been through either audit. If you need one to buy, we are not there yet.
• Our Content Security Policy reports, it does not block. It is deployed in report-only mode so we can see what a stricter policy would break before it breaks a worker mid-submission. Enforcing it is a real decision we have not yet made.
• There is no public page where an outsider can re-check a fingerprint. The seal is computed and stored on our side. Anyone you share a record with is, at that point, trusting us that it matches.
• Our AI review flags; it never decides. A flag asks a person to look closer. It is not a verdict on a worker and it never blocks a submission.