⚖️ Courtesy abstract in English. Only the French version of this disclosure, published on 19 August 2026, is authoritative.
The Seal method — public technical disclosure
Published by Technologies Marco Prive (Québec, Canada) on 19 August 2026. This page is a voluntary, dated public disclosure of the mechanism (prior art). UK patents pending — GB2619490.2 · GB2619948.9 · GB2620153.3 · GB2620211.9 · GB2620220.0 · GB2620253.1 · GB2620315.8 · GB2620629.2 · GB2621074.0 · GB2621382.7.
Each registered organisation is verified through a chain of independent proofs: legal existence (specialist providers and public registers), identity of the representative (documentary check with liveness), electronically signed attestation of role with an audit trail, and control of public channels — a code dictated by an automated call to the phone number the organisation publishes on its own official listing.
Each employee holds a 16-digit number that changes IN FULL every 60-second window: the first 8 digits are the internal identifier ENCRYPTED with format-preserving encryption (Feistel network, HMAC-SHA256) whose key is derived from the time window; the last 8 are a one-time TOTP-style code (HMAC-SHA256). Nothing is stored.
Whoever wants to verify enters the 16-digit number — or scans the QR that carries it — on a public page: no account, no installation, no identity. The service answers only that the code matches an active employee of an organisation whose listed proofs were verified, or a neutral result that never accuses. Each code is consumed on first use.
The verifier may issue a challenge (a short number) that the employee enters in their organisation's tool; the signed answer is bound to that precise interaction, making any code obtained in another context useless.
A verified organisation may attach to each message (email, SMS) a self-contained verification link: a payload signed with HMAC-SHA256 under a key derived (HKDF) from the master key, per organisation and per key version, carrying the organisation identifier, the expiry, the MASKED recipient address and the declared subject — no secret and no per-message record.
One challenge designates two to five ORDERED time windows (configurable length: 60, 30, 20, 15 or 10 seconds — short windows form cryptographically separate code families, the length entering key derivation). At each designated window the person supplies the code of THAT exact window; the code of a later window DOES NOT YET EXIST at the moment of the earlier answer, so the sequence cannot be produced in advance.
Between checks, the person's page emits minimal heartbeats (the body carries only the session token). The server records ONLY aggregates: number of interruptions (any gap beyond a tolerance) and cumulative duration. The CAUSE of an interruption is never known to the server — deliberately.
A subscribing organisation may display, on its site and in its emails, a badge served by the verification server, leading to a free public verification page with no account. The server derives on demand, storing no per-site secret, a short-lived code (60-second window) bound cryptographically to the organisation AND to a domain identifier.
Point 8 protects the diligent verifier who types the domain himself; this point protects the one who does not. When a browser fetches the badge image to include it in a page, it transmits an indication of the including page's address; when a page requests the live code by script, it transmits an origin. Display outside the declared places is reported.
Similarity search in public certificate transparency logs; DNS resolution of mechanically generated variants of the official domain; and bounded edit-distance comparison on the domain label. The three channels are independent: losing one does not blind the watch.
A sensitive operation requires authorisation from a configurable number of DISTINCT people bound to the same organisation. The requester can never approve himself: the rule is enforced by the system at request creation AND at signature, never by an internal policy instruction. An explicit refusal by a signatory may be made blocking.
Client data is encrypted with a key reconstituted from TWO SHARES: one held by the client, one derived by the service and released only at the end of an authorisation ceremony by a second identified person. Neither the service nor the client can decrypt alone, and the service never holds nor receives the client's share.
Requiring a ceremony on every read would make the protection unbearable and push the client to circumvent it. Data keys are therefore wrapped under a distinct derivation, and a window counter bounds the VOLUME that may be unwrapped between two ceremonies. Exceeding the threshold is a NORMAL refusal, distinguished from a failure so the client application treats it as such.
A deliberate architectural choice, not a commercial policy: a client billed per read starts avoiding reads — that is, circumventing his own protection. A protection one has an interest in circumventing is not a protection.
Disclosed on the same footing as the rest, because a limit left unsaid is a lie. The two-share mechanism does not protect against an attacker durably installed on the client's system: during an authorised operation the reconstituted key necessarily exists in memory on that system, and persistent privileged access can observe it there. The mechanism narrows the exposure window; it does not close it.
The work is cut into time segments; each segment receives a fingerprint computed by a transform chosen to survive the re-encoding, resizing and container change that distribution platforms systematically apply. The fingerprint is a RANK RELATION between neighbouring blocks, never an absolute value, so it does not depend on exact pixel values.
Each segment carries a visual AND an audio component computed over the SAME interval, sealed together rather than as two independent seals. Three distinct substitutions are thereby detected: replacing the soundtrack over authentic images — the cheapest attack to manufacture, since cloning a voice costs less than remaking a face; replacing the images; and desynchronising the two.
Because fingerprints are kept in order and frame-aligned, a legitimate excerpt is recognised as a contiguous subsequence and confirmed WITH its position in the original work — the very information that reveals an excerpt whose cut reverses the meaning. A reassembly of authentic segments in a different order is reported as such. A system that cried fraud at every excerpt would be ignored within a week.
The two-person ceremony is required at sealing, never at verification: a work sealed once is then verified a billion times, free and without anyone's approval. To make the ceremony bearable at catalogue scale, an authorisation may cover an ENUMERATED set of works FROZEN BEFORE signature and shown to the approver with its exact extent.
The entity declares the accounts and domains where the work is entitled to appear. An authentic work presented elsewhere is NOT confirmed: the result reports unauthorised republication and names the legitimate places. This is the only way to address diverted context — authentic images republished on a site impersonating the broadcaster are authentic in every respect except the one that matters.
An alteration both very small and very brief can pass under the decision threshold. On a highly repetitive work, an excerpt may match several positions. Platforms protected by digital rights management let no browser read their stream and no software capture reach their image; they remain verifiable by optical capture.
Measured in an unmodified browser: a page served by one site can neither read the bytes of a video served by another site, nor read a single point of its image once displayed — the video plays perfectly and remains unreadable. That is the browser's security model, not a limit of the service. Verification by address therefore never claims to have examined the work.
When a capture contains the screen AND its surroundings, the fingerprint would describe the room as much as the work. The screen area is therefore delimited first, without seeking any contour or straight line: for each point of the image, the spread between its maximum and minimum value over a few seconds is measured. A wall never changes; a screen point always ends up changing.
On a screen capture, the framing is chosen by the user and moves the visual fingerprint beyond tolerance while the tab's sound stays faithful: the sound decides. On a camera capture the opposite holds — the visual fingerprint survives perspective and sensor noise while the sound crosses the room and comes back altered. On the optical channel, no integrity verdict is rendered.
When the verifier holds the file, a cryptographic digest is compared BEFORE any fingerprint: it answers not « is this the same work, within a tolerance » but « is this the same file, byte for byte ». It does not replace the fingerprint, since bytes change at every re-encoding. Perfect identity remains subject to the authorised places.
A broadcast in progress has no fingerprint yet. The window code may therefore also be emitted in the audio track, at a pitch above ordinary hearing but inside the band that broadcast coding preserves, and renewed at each window. The viewer brings their device close; it decodes the sound LOCALLY and sends only the six characters.
Identity verification establishes that a real human registered with his own papers; KYB establishes that a company exists and who represents it. Neither establishes that the entity controls the channel where it claims to publish. An impostor can pass identity verification with his REAL papers, under his REAL name, and then declare someone else's channel. That is the missing link, and it is proved separately.
The date of a seal would otherwise rest on our registers and our clock alone — and an opposing party would be right to say we could backdate. At the close of each day, a Merkle root of all that day's seals is computed and submitted to OpenTimestamps calendar servers, which inscribe it in the Bitcoin chain. Each work receives its path in the tree: whoever holds it can verify the date WITHOUT TRUSTING US.
A badge placed under a video is an image, and an image can be copied: a fake site would display it to look guaranteed. The media badge is therefore not an inert image — it is served by Seal, which reads the witness the browser itself sends and compares the display location with the places declared for that work. Outside those places it turns red and states the anomaly.
The metering of point 13 says « this may be abnormal »; this mechanism says « this is a theft, now ». The service manufactures an envelope having EXACTLY the shape of a real one — same key derivation, same authenticated encryption, same length — wrapping a random draw: it opens nothing, and if unwrapped would yield no useful key. The service keeps only its cryptographic fingerprint; the envelope itself is shown once and cannot be redisplayed, not even to the entity that created it — a decoy envelope readable in the portal would be readable by an intruder in the portal, and therefore avoidable. The entity places it in a ghost record that none of its legitimate programs ever reads. On each unwrap request, the fingerprint of every envelope in the batch is compared with the vault's decoy fingerprints. On a match the whole batch is refused WITH THE EXACT MESSAGE OF AN INVALID ENVELOPE — the same as for an envelope belonging to another vault, and with no measurable timing difference. That property is what makes the mechanism hold: if the service answered « decoy detected », the attacker would unwrap one envelope at a time, map the decoys by bisection and avoid them. A batch refused because of a decoy is furthermore COUNTED against the metering quota as if it had been unwrapped — otherwise mapping the decoys would be free and leave no trace. Two configurable responses: alert and refuse the batch; or alert, refuse AND rotate the vault key. The rotation is a REVERSIBLE stop, not a destruction: the previous key version is retained and can be restored. This is necessary rather than cosmetic — an irreversible rotation would turn every decoy into a weapon against its owner, since the attacker who read the database holds the decoys: he would submit one and permanently destroy the existing envelopes together with the printed share kept offline, the key version entering its derivation. Two precautions accompany the method. A decoy's label is constrained to a short identifier without spaces: it serves to recognise the envelope in the alert, and this format prevents a sentence containing personal data from reaching the service and then leaving again in a notification. And the fingerprint is checked in its canonical form AND in the form inherited from an earlier version of the format, so that a change of representation never silently disarms decoys already in place.
Point 9 unmasks a forger who EMBEDS the seal from our servers: the origin witness set by the browser betrays them. It sees nothing, however, of a forger who SAVES the seal image and serves it from their own hosting — no request reaches us, so no witness exists. But a saved image is FROZEN, and this mechanism turns that single weakness into a signature. The seal carries a second part, DRAWN INTO THE PAGE rather than embedded as an image — a constraint imposed by browsers, which execute no script inside an image. That band shows, for the current time window: the six-digit public code, a hue drawn from a fixed palette, THE WRITTEN NAME of that hue, and a second word from a fixed list. Hue and word are derived by keyed hash from the pair (domain displaying the seal, time window), using a SUB-KEY OF ITS OWN, distinct from the one behind the displayed code: the attire therefore reveals nothing about the code, and two domains never wear the same attire at the same instant. Three checks follow, from least to greatest effort: the band CHANGES BY ITSELF, whereas a saved copy stays still; the words are REAL TEXT, selectable and readable by a screen reader, which a copied image is not; and the words shown MATCH those the service publishes for that domain at that instant. The word is not random but DERIVED — a truly random word would be unverifiable, including by the service. Two requirements make the method sound rather than decorative: the hue NEVER carries the information alone (the written name always accompanies it, and the palette EXCLUDES the two hues that already carry the verdict), and silence accuses NOTHING — the band then states that the code is unavailable, neither verified nor disputed, since accusing on an absence of proof would be the symmetric fault to the one being fought. Finally the service REFUSES TO COMPUTE when the origin declared by the browser matches no official domain of the entity, returning the same answer as for an unknown domain, so the forger learns nothing of what was understood. A server-side relay, which emits no origin, remains out of reach; it is addressed by detection — a single address repeatedly requesting one domain's code while never presenting an origin — not by refusal, since refusing on the absence of an origin would cut off every legitimate non-browser call.
This English text is an abstract provided for readability. Where the two differ, the French version published on 19 August 2026 prevails.
