Security architecture

Every layer of the District Seal platform — biometric matching, liveness detection, cryptographic sealing, infrastructure, and data retention — documented for technical reviewers.

Face matching (ArcFace)

District Seal uses the ArcFace family of deep-learning models for face embedding. ArcFace computes a 512-dimensional vector from a face image in a way that minimizes the cosine distance between images of the same person and maximizes it between images of different people.

The threshold is configurable per account. A stricter threshold (lower number, e.g. 0.45) reduces the chance of a false match at the cost of more false rejections. The default of 0.55 is chosen to balance security and usability on consumer cameras.

Liveness detection (MediaPipe)

Liveness — the property of being a present, live human rather than a photograph, screen, mask, or video replay — is verified through four independent signals:

Random challenge phrase

Three words from a sixteen-word pool are randomly selected per session. The pool is fixed and large enough that the chance of guessing is negligible for any single session. The signer must speak the words, and an ASR model must transcribe them correctly. A pre-recorded video of the signer cannot be reused because it will not contain the correct random phrase.

Random gesture sequence

Two gestures are drawn at random from five possibilities. The order is disclosed one at a time. A pre-recorded video cannot be spliced to match an unknown sequence in real time.

Sensor noise variance

The client samples ten consecutive frames from the live camera and computes the variance of pixel luminance across the samples. A real camera sensor produces measurable noise; a static screenshot or a synthetic feed produces near-zero variance. Results are streamed to the server alongside the challenge samples.

Virtual camera detection

The client enumerates all video input devices attached to the system and compares their labels against a blocklist of known virtual-camera software. This includes OBS Virtual Camera, ManyCam, Snap Camera, Camo, DroidCam, EpocCam, Iriun, mmhmm, vMix, E2ESoft, YouCam, XSplit, Streamlabs, and NVIDIA Broadcast. Detections are logged in the forensic record. They do not by themselves block the ceremony — a user may legitimately have such software installed for other purposes — but they are visible to the sender in the transaction audit log.

Cryptographic sealing

Every signed document and every certificate contains a SHA-256 hash. SHA-256 is the standard cryptographic hash function used across digital forensics, government procurement, and financial services.

The sealing process works as follows:

1. The original PDF is hashed at the moment of upload. The 64-character hexadecimal digest is stored.
2. A forensic manifest is built: a JSON object containing the reference hash, the signer identity, the full event timeline, the results of each verification check, and the verification ceremony timestamps.
3. The manifest is itself hashed with SHA-256.
4. The manifest hash is embedded in the certificate PDF, along with the original document hash.
5. The public verification URL resolves to a page that reads the certificate and confirms that both hashes match the records in the District Seal database.

If anyone modifies the signed PDF after the fact — even a single character — the document hash on the verification page will not match, and the certificate will display as invalid.

Infrastructure security

Biometric data handling

District Seal handles biometric data — a term that includes face geometry and voice — under a strict destruction policy designed to minimize exposure.

Retention periods can be configured per account within limits. The 7-year default matches the record-retention standards commonly applied to signed instruments in the United States.

Anti-tampering and anti-extraction

District Seal certificates are designed to resist two classes of manipulation:

Anti-tampering

Every certificate and every signed document is bound to a SHA-256 hash computed at the moment of upload. The certificate contains both the document hash and a manifest hash of the entire forensic record. If any byte of the document changes after signing, the document hash will not match, and the public verification page will return the certificate as invalid. This makes tampering detectable by any third party — no trust in District Seal is required to confirm the certificate is unmodified.

Anti-extraction

Text extraction from District Seal certificates — including via copy-and-paste, OCR tools, and automated scrapers — may be unreliable by design. Extracted text can be garbled, truncated, or incomplete. This is intentional and is a property of how the certificate is generated, not a bug.

Independent verification

Every certificate carries a public verification URL. A third party — a court, an auditor, an opposing counsel — can open the URL and confirm that the certificate is genuine. No account is required, no phone call, no letter. The page displays the signer name, the document hash prefix, the verification mode, and the timestamp.

Reporting a security issue

Security researchers are asked to report issues privately to security@districtseal.com before public disclosure. We will acknowledge receipt within 72 hours and coordinate disclosure timelines with the reporter.

Standard contact information is also published at districtseal.com/.well-known/security.txt.