What "signed" and "verified"
actually mean here.
Precise claims, stated plainly — including what each mechanism does not prove. Trust is earned by being exact, not by sounding certain.
Five steps, every capture
Every photo or video you take inside SealMove goes through the same chain — nothing skips a step, and nothing about it depends on a specific device, plan, or subscription.
SECURE ENCLAVE
A key that never leaves your phone
Signing succeeds fully offline. Empty apartments routinely have no signal — SealMove is built around that as the normal case, not an edge case.
On-device signing
The instant you take a capture, a cryptographic key held in your phone's Secure Enclave signs its content hash. That key is generated on-device and never transmitted anywhere — not even to SealMove's own servers.
This proves the capture existed, unaltered, at the moment your device says it did. It does not prove who was holding the phone — that's a separate claim, made later by Face ID/Touch ID sign-off.
What this doesn't prove: identity of the photographer, or that the device itself hasn't been compromised at the OS level. It proves the capture wasn't altered after this exact moment.
The two-timestamp model
A phone's clock is user-settable — it proves nothing about time on its own. So SealMove never asks you to trust just one timestamp.
The device timestamp is asserted the moment you capture. The anchor timestamp is set once our /api/anchor endpoint independently countersigns that capture's hash — the next moment your device has connectivity. If the gap between the two exceeds 48 hours, the report flags it, visibly, rather than picking a side.
EXAMPLE
A 1-minute gap is unremarkable — the capture reached the server almost immediately. A multi-day gap gets flagged honestly, not passed over silently.
APP ATTEST
Genuine app, genuine hardware
Apple's DCAppAttestService — every anchor request is checked before the server signs anything.
Requests come from a real copy of the app
Separate from capture signing, App Attest lets our backend assess whether a protected request came from a genuine, unmodified instance of SealMove running on real Apple hardware — not a script pretending to be one.
What this doesn't prove: who's using the app, or that the separate capture-signing key hasn't been compromised. It only strengthens the chain of custody at the network boundary.
A report that outlives the company
An exported report is a self-contained bundle: every hash, signature, and public key a verifier needs travels inside it. The standalone tool at api.sealmove.com/verify checks it entirely in your browser — nothing uploads, nothing needs SealMove's servers to still exist.
That's a deliberate product principle: evidence has to remain useful and legible months after capture, since that's typically when disputes actually surface.
MANIFEST.JSON (SHAPE)
{
"formatVersion": 2,
"captures": [ … signed, hashed, anchored … ],
"signature": { … sign-off, Secure Enclave … },
"anchor": { … server countersignature … }
}
LINK ACKNOWLEDGMENT
Server-countersigned, not just logged
Report ID + name + timestamp, signed with the same anchor key used for captures.
What a link acknowledgment is — and isn't
When someone reviews a shared report and clicks "Acknowledge," our server countersigns the report ID, the name they typed, and the moment it happened — turning "they saw this and didn't dispute it" into a tamper-evident record instead of an editable database row.
What this doesn't prove: the identity of who typed the name. A link acknowledgment is not notarization, a witnessed signature, or verified identity — we say so on the acknowledgment page itself, not just here.
Check the math yourself.
The homepage demo runs this exact process on a real image, live, in your browser.
Get notified at launch