Seal Media
Evidence of who published an audio or video work and verification of its integrity, including after platform re-encoding.
| Version | 2.0 — 15 September 2026 |
|---|---|
| Intended audience | Technical, security, integration and partner teams |
| Status | Technical description based on public information; implementation parameters to be confirmed |
Purpose and scope
Answer the question “who stands behind this publication?” and enable comparison of a link or file with a sealed work. Seal Media does not determine whether the content is true.
Operating principle
- The artist or organisation proves identity and control of publication channels.
- The work is read locally in the browser; the file is neither modified nor sent to Seal.
- A compact fingerprint is recorded with the sealer identity and date.
- The verifier uses a link, file, screen share or camera according to the required assurance level.
- Daily OpenTimestamps and Bitcoin anchoring enables public verification that a work had been sealed before a given date.
Targeted threats
- Deepfake or voice replacement
- Modification of images, audio or synchronisation
- False attribution to a creator
- Copying a badge to an undeclared channel
Components and responsibilities
| Component | Role |
|---|---|
| Verified organisation or publisher | Establishes identity, channels or domains and manages authorised people. |
| User or approver | Presents live evidence or participates in authorisation under policy. |
| Seal service | Evaluates necessary verification elements and returns a result limited to the use case. |
| Integrating system | Binds the Seal result to the exact action, applies business rules and retains required audit data. |
| Verifier | Checks the result in context and does not interpret it as a guarantee of truth. |
Data and privacy
The stated public principle is data minimisation: no GPS, biometrics or cameras for identity and presence modules; local browser computation when a media or document module processes a file; and retention of irreversible fingerprints and limited metadata rather than source content. The exact fields, retention periods, logs, subprocessors and transfers must be confirmed in a data-processing appendix.
Expected security properties
- Temporal freshness of live evidence
- Separation of roles and factors
- Binding of the result to the context or action
- Minimisation and non-disclosure of source content
- Proportionate traceability without turning Seal into a central identity database
Limitations and assumptions
- Camera or screen-share checking identifies the work and publisher but does not alone prove that the particular copy is unaltered; the file or address is required for that analysis.
- Public anchoring proves who sealed first, not who created first.
- A work not sealed before publication is not covered. Seal informs and cannot remove content from a platform.
Items to confirm before integration
- API, request and response schemas, authentication and quotas
- Applicable algorithms, key lengths, entropy sources and rotation
- Time tolerances, clock synchronisation and expiration handling
- Error handling, revocation, recovery and service continuity
- Logging, retention, location, deletion and regulatory obligations
- Penetration testing, independent cryptographic review and vulnerability disclosure process
Public references
- https://seal.lifaio.com/go
- https://lifaio.com/seal-lifaio/
- https://lifaio.com/seal-media/
Notice: this document describes the publicly communicated conceptual operation. It does not replace an API specification, cryptographic analysis or independent security audit.
UK patent applications pending: GB2619490.2 · GB2619948.9 · GB2620153.3 · GB2620211.9 · GB2620220.0 · GB2620253.1 · GB2620315.8 · GB2620629.2 · GB2621074.0 · GB2621382.7 · GB2622122.6 · GB2622135.8
