⚖️ Abrégé de courtoisie en anglais. Seule la version française de cette divulgation, publiée le 19 août 2026, fait foi.
Cette page est la version qui fait foi : elle n'est jamais traduite, et c'est volontaire. Les 17 autres langues reçoivent l'abrégé anglais des 31 points.
La méthode Seal (divulgation technique publique)
English abstract of the 31 points →
Publié par Technologies Marco Prive (Québec, Canada) le 19 août 2026. Cette page constitue une divulgation publique volontaire et datée du mécanisme (art antérieur). / Published by Technologies Marco Prive (Quebec, Canada) on August 19, 2026. This page is a deliberate, dated public disclosure of the mechanism (prior art).
UK patents pending — demandes de brevet britanniques : n° GB2619490.2, déposée le 21 août 2026, et demande « Sequential verification system and method », réf. interne SEAL-LIFAIO-SEQ-2026, n° GB2619948.9, déposée le 27 août 2026, et demande « Website authenticity verification system and method », réf. interne SEAL-LIFAIO-SITE-2026, n° GB2620153.3, déposée le 28 août 2026, et demande « Detection and signalling of unauthorised display of a verification seal », réf. interne SEAL-LIFAIO-ORIG-2026, n° GB2620211.9, déposée le 31 août 2026, et demande « Authorised release of a key share for the decryption of protected data », réf. interne SEAL-LIFAIO-COFFRE-2026, n° GB2620220.0, déposée le 31 août 2026, et demande « Verification of the authenticity and origin of published media content distributed across a plurality of platforms », réf. interne SEAL-LIFAIO-MEDIA-2026, n° GB2620253.1, déposée le 1er septembre 2026, et demande « Verification of the authenticity of media content acquired by capture of a rendered presentation, and authentication of live transmissions by a time-varying code carried in the audio band », réf. interne SEAL-LIFAIO-CAPTURE-2026, n° GB2620315.8, déposée le 1er septembre 2026, et demande « Detection of unauthorised access to protected data by means of decoy records », réf. interne SEAL-LIFAIO-DECOY-2026, n° GB2620629.2, déposée le 5 septembre 2026, et demande « Verification of entitlement to admission, and transfer of such entitlement, without retention of the personal data of the holder », réf. interne SEAL-LIFAIO-TICKET-2026, n° GB2621074.0, déposée le 10 septembre 2026, et demande « Attested erasure of personal data by irreversible destruction, by a party having no access to the data, of per-subject key material », réf. interne SEAL-LIFAIO-ERASE-2026, n° GB2621382.7, déposée le 15 septembre 2026, et demande « Link-free verification of an electronic message by its recipient using a recipient-bound code, a secret held by the recipient alone, consumption upon authenticated verification, and local comparison of transport authentication with the sender domains », réf. interne SEAL-LIFAIO-EMAIL-2026, n° GB2622122.6, déposée le 22 septembre 2026, et demande « Delegated issuance of recipient-bound message verification codes under a sender-held key derived from a verification service's master secret, never stored by the service, carrying its generation in each code, and revocable apart from service codes », réf. interne SEAL-LIFAIO-DELEGATED-2026, n° GB2622135.8, déposée le 22 septembre 2026 (déposant : Marco Prive, faisant affaire sous Technologies Marco Prive). / UK patent applications No. GB2619490.2 (filed August 21, 2026), "Sequential verification system and method" No. GB2619948.9 (filed August 27, 2026) and "Website authenticity verification system and method" No. GB2620153.3 (filed August 28, 2026) and "Detection and signalling of unauthorised display of a verification seal" No. GB2620211.9 (filed August 31, 2026), and "Authorised release of a key share for the decryption of protected data" No. GB2620220.0 (filed August 31, 2026), and "Verification of the authenticity and origin of published media content distributed across a plurality of platforms" No. GB2620253.1 (filed September 1, 2026), and "Verification of the authenticity of media content acquired by capture of a rendered presentation, and authentication of live transmissions by a time-varying code carried in the audio band" No. GB2620315.8 (filed September 1, 2026), and "Detection of unauthorised access to protected data by means of decoy records" No. GB2620629.2 (filed September 5, 2026), and "Verification of entitlement to admission, and transfer of such entitlement, without retention of the personal data of the holder" No. GB2621074.0 (filed September 10, 2026), and "Attested erasure of personal data by irreversible destruction, by a party having no access to the data, of per-subject key material" No. GB2621382.7 (filed September 15, 2026), and "Link-free verification of an electronic message by its recipient using a recipient-bound code, a secret held by the recipient alone, consumption upon authenticated verification, and local comparison of transport authentication with the sender domains" No. GB2622122.6 (filed September 22, 2026), and "Delegated issuance of recipient-bound message verification codes under a sender-held key derived from a verification service's master secret, never stored by the service, carrying its generation in each code, and revocable apart from service codes" No. GB2622135.8 (filed September 22, 2026) (applicant: Marco Prive, trading as Technologies Marco Prive).
Seal LIFAIO est un système de vérification d'humain à humain, sans relation préalable, dont le mécanisme est le suivant :
1. Organisations vérifiées. Chaque organisation inscrite est vérifiée par une chaîne de preuves indépendantes : existence légale (fournisseurs spécialisés et registres publics), identité du représentant (vérification documentaire avec preuve de vie), attestation de rôle signée électroniquement avec piste d'audit, et contrôle des canaux publics — code dicté par appel automatisé au numéro de téléphone affiché publiquement par l'organisation, et confirmation par courriel sur son domaine officiel. L'état exact de chaque preuve est affiché publiquement.
2. Un numéro unique de 16 chiffres, entièrement tournant, jamais stocké. Chaque employé dispose d'un numéro de 16 chiffres qui change EN ENTIER à chaque fenêtre de 60 secondes : les 8 premiers chiffres sont son identifiant interne CHIFFRÉ par un chiffrement à format préservé (réseau de Feistel, HMAC-SHA256) dont la clé est dérivée de la fenêtre temporelle ; les 8 derniers sont un code à usage unique de type TOTP (HMAC-SHA256). Le numéro se dicte comme un numéro de carte (groupes de 4 chiffres) et se transporte par un simple code QR. Aucun secret n'est stocké : tout est dérivé à la demande (HKDF) d'une clé maîtresse, avec un numéro de version par employé permettant la révocation et la rotation instantanées. La vérification s'exécute en temps constant : déchiffrement de l'identifiant pour la fenêtre courante (puis précédente), puis contrôle du code pour LA MÊME fenêtre.
3. Vérification par le tiers, sans compte. La personne qui souhaite vérifier saisit le numéro de 16 chiffres — ou scanne le code QR le contenant — sur une page publique, sans compte, sans installation et sans identité. Le service répond uniquement : « ce code correspond à un employé actif d'une organisation dont les preuves listées ont été vérifiées », ou un résultat neutre qui n'accuse jamais. Chaque code est consommé à la première vérification (anti-rejeu par empreinte éphémère). Aucun historique des vérifications individuelles n'est conservé.
4. Variante à défi inversé. Le vérifieur peut émettre un défi (numéro court) que l'employé saisit dans son outil d'organisation ; la réponse signée est liée à cette interaction précise, rendant inutilisable tout code obtenu dans un autre contexte.
5. Vérification de messages (anti-hameçonnage). Une organisation vérifiée peut joindre à chaque message (courriel, texto) un lien de vérification autoportant : charge utile signée HMAC-SHA256 par une clé dérivée (HKDF) de la clé maîtresse, par organisation et par version de clé, contenant l'identifiant d'organisation, l'expiration, l'adresse MASQUÉE du destinataire et le sujet déclaré — aucun secret ni enregistrement par message n'est stocké. Le destinataire consulte le lien : la fiche vérifiée de l'organisation s'affiche avec l'adresse masquée à laquelle le message était destiné — un lien copié dans un message frauduleux révèle un destinataire différent. La consultation est une lecture pure (compatible avec les analyseurs automatiques de liens) ; l'incrément d'une version de clé révoque instantanément tous les liens émis ; la validité de l'organisation est revérifiée à chaque consultation.
6. Vérification séquentielle (présence continue). Un défi désigne deux à cinq fenêtres temporelles ORDONNÉES (durée paramétrable : 60, 30, 20, 15 ou 10 secondes — les fenêtres courtes forment des familles de codes cryptographiquement étanches, la durée entrant dans la dérivation des clés). À chaque fenêtre désignée, la personne fournit le code de CETTE fenêtre exacte ; le code d'une fenêtre ultérieure N'EXISTE PAS ENCORE au moment où une partie antérieure est donnée — il n'est calculable par personne, pas même par la personne vérifiée. La capture ou le partage anticipé est donc impossible PAR CONSTRUCTION, et non par interdiction. Toute erreur (mauvais code, mauvaise fenêtre, réutilisation) met fin au défi, qui doit être recommencé. Le motif s'applique en CHAÎNE (remises successives — preuves, valeurs, livraisons — chaque maillon étant absorbé dans une empreinte cumulative SHA-256 : insérer, retirer ou réordonner un maillon casse l'empreinte, qui n'est délivrée que si la chaîne est intacte) et en SESSION (présence sur une durée — quart de travail, consultation, examen — avec des contrôles exigés à des moments IMPRÉVISIBLES pour la personne, dérivés par HMAC de la clé maîtresse ; l'état montre combien de contrôles restent, jamais quand). Aucune biométrie, aucune géolocalisation, aucun enregistrement de qui vérifie qui. / Sequential verification: a challenge designates ordered time windows; each part must be the code of ITS exact window — a later window's code does not yet exist when an earlier part is given, making anticipatory capture impossible by construction. CHAIN and SESSION patterns (cumulative SHA-256 fingerprint; unpredictable HMAC-derived control moments) prove custody chains and continuous presence without biometrics or location data.
7. Témoin de continuité (compteur, pas traqueur). Entre les contrôles d'une session, la page de la personne émet des battements de vie minimaux (le corps ne contient que le jeton de session). Le serveur n'enregistre QUE des agrégats : nombre d'interruptions (tout écart entre deux battements dépassant un seuil de tolérance) et durée cumulée. La CAUSE d'une interruption (appareil éteint, réseau perdu, page cachée ou fermée, volontaire ou non) n'est ni détectée, ni classée, ni enregistrée. Des seuils fixés à la création de la session déterminent si le résultat est maintenu ou invalidé, le silence final comptant comme un écart. Des rappels sonores et vibratoires LOCAUX sont émis par l'appareil pendant le temps de réponse permis, sans aucun message réseau. / Continuity witness: minimal liveness heartbeats; the server records only aggregate counters (number and cumulative duration of gaps); the cause of an interruption is neither detected, classified nor recorded; local audible reminders require no network message.
8. Authenticité de site web (code lié au domaine). Une organisation abonnée peut afficher sur son site et ses courriels un badge servi par le serveur de vérification, menant à une page publique de vérification gratuite et sans compte. Le serveur dérive à la demande, sans stocker aucun secret par site, un code de courte durée (fenêtre de 60 secondes) lié cryptographiquement à l'organisation ET à un identifiant de domaine — la dérivation (HKDF, sel dédié, contexte organisation:domaine, puis code à usage temporel de type TOTP tronqué à 6 chiffres) n'est calculée QUE pour les domaines OFFICIELS de l'organisation, établis côté serveur à partir de sources vérifiées indépendamment (site de la fiche d'entreprise publique ancrée, domaine courriel prouvé par code), jamais par saisie libre. Le point essentiel : le visiteur tape LUI-MÊME le domaine qu'il voit dans la barre d'adresse de SON navigateur — le seul élément qu'un faux site ne peut pas altérer. Le vrai site affiche le code de son domaine officiel ; un faux site qui RELAIE ce code en temps réel affiche donc forcément le code d'un AUTRE domaine que celui que la victime a sous les yeux : la comparaison échoue et le relais lui-même trahit la fraude. Domaine non officiel → aucun code n'est dérivé, un avertissement est affiché. Abonnement échu → toute dérivation cesse et le badge, généré à chaque affichage par le serveur, passe visiblement à l'état expiré. Tout le calcul s'exécute exclusivement au serveur : le site client AFFICHE, il ne détient ni clé, ni algorithme, ni compteur. / Website authenticity (domain-bound code): the verification server derives on demand, storing no per-site secret, a short-lived 6-digit code cryptographically bound to the organization AND to a domain identifier, computed ONLY for the organization's official domains established server-side from independently verified sources. The verifier types the domain they see in their OWN address bar — the one element a counterfeit site cannot alter. A counterfeit relaying the genuine site's code in real time necessarily shows a code bound to another domain: the mismatch itself exposes the fraud. Lapsed subscription → derivation ceases and the server-generated badge visibly expires. All computation happens exclusively at the server; client sites display, they hold no key, algorithm or counter.
9. Détection de l'affichage non autorisé du sceau (témoin d'origine). Le point 8 protège le vérificateur diligent, celui qui tape lui-même le domaine. Ce point-ci protège celui qui ne le fait pas. Lorsqu'un navigateur récupère l'image du sceau pour l'inclure dans une page, il transmet au serveur de vérification une indication de l'adresse de la page incluante ; lorsqu'une page réclame le code vivant par script, il transmet une indication de son origine. Ni l'une ni l'autre n'est posée par le contenu de la page : toutes deux sont imposées par le navigateur. Un faux site qui affiche le sceau ne peut donc ni les supprimer ni les falsifier tout en continuant de recevoir ce sceau. Le serveur en tire l'hôte — l'hôte seul, jamais le chemin ni les paramètres, qui pourraient concerner le visiteur — le compare aux domaines officiels de l'organisation, et lorsqu'il ne correspond à aucun, il génère et sert un sceau NÉGATIF, visuellement distinct, portant dans la langue du visiteur la mention que le domaine qui l'affiche n'est pas un domaine autorisé : la page contrefaite porte elle-même l'accusation, sans coopération de son auteur. Trois règles rendent le mécanisme utilisable en production : un sous-domaine d'un domaine officiel est légitime ; un hôte qui CONTIENT le domaine officiel sans s'y terminer (par exemple exemple.com.attaquant.net) est rejeté ; et l'absence du témoin donne le sceau affirmatif — on ne condamne jamais sur une absence de preuve. La réponse porte une directive de cache empêchant un cache PARTAGÉ de servir à un faux site le sceau affirmatif mémorisé pour un vrai site. Chaque hôte non autorisé est inscrit dans un registre propre à l'organisation, qui en est avisée dans son portail ; aucun identifiant de visiteur n'est conservé. / Detection of unauthorised display of the seal (origin witness): when a user agent retrieves the seal image for inclusion in a page, it transmits to the verification server an indication of the including page's address; when a page requests the live code by script, it transmits an indication of its origin. Neither is set by page content: both are imposed by the user agent, so a counterfeit site cannot suppress or falsify them while still receiving the seal. The server derives the host alone — never the path or query — compares it with the organisation's authorised domains, and where it corresponds to none, generates and serves a visually distinct NEGATIVE seal bearing, in the visitor's language, a statement that the displaying domain is not authorised, so that the counterfeit page displays the accusation to its own visitors. A sub-domain of an authorised domain is authorised; a host that merely contains an authorised domain without terminating in it is rejected; an absent witness yields the affirmative seal. The response bears a cache directive preventing a SHARED cache from serving a counterfeit the affirmative seal stored for a genuine site. Each unauthorised host is recorded in a register belonging to the organisation, which is notified in its portal; no visitor identifier is retained.
10. Veille des domaines sosies, par trois canaux indépendants. Recherche par ressemblance dans les journaux publics de transparence des certificats ; résolution DNS de variantes engendrées mécaniquement à partir du domaine officiel ; et comparaison de suite bornée sur l'étiquette du domaine. Les trois canaux sont indépendants : la disparition de l'un ne rend pas la veille aveugle. Les résultats sont présentés dans le portail de l'organisation, jamais poussés par courriel non sollicité. Le découpage sur trait d'union est proscrit — il détruisait toute étiquette en contenant un, et rendait la détection silencieusement inopérante.
11. Séparation des rôles, appliquée et non déclarative. Une opération sensible exige l'autorisation d'un nombre configurable de personnes DISTINCTES, liées à la même organisation. Le demandeur ne peut jamais s'approuver lui-même : la règle est appliquée à la création de la demande ET à la signature, par le système, jamais par une simple consigne de politique interne. Le refus explicite d'un signataire peut être rendu bloquant. Chaque signature et chaque refus est horodaté, attribué et conservé, et constitue le journal d'audit de l'organisation.
12. Chiffrement à clé en deux parts, sous autorisation humaine. Les données du client sont chiffrées par une clé reconstituée à partir de DEUX PARTS : une part détenue par le client, une part dérivée par le service et libérée seulement au terme d'une cérémonie d'autorisation par une seconde personne identifiée. Ni le service ni le client ne peut déchiffrer seul, et le service ne détient ni ne reçoit jamais la part du client. La part initiale n'est livrable qu'UNE seule fois par coffre, verrouillée en base contre l'accès concurrent. La version de clé est figée à la création : une rotation ultérieure de la clé maîtresse ne rend jamais illisible un coffre existant. La révocation n'altère aucune donnée déjà chiffrée mais interdit toute ouverture ultérieure par le service.
13. Extension aux bases de données lues en continu (métrage). Exiger une cérémonie à chaque lecture rendrait la protection insupportable et pousserait le client à la contourner. Les clés de données sont donc enveloppées sous une dérivation distincte, et un compteur de fenêtre borne le VOLUME déballable entre deux cérémonies. Le dépassement du seuil est un refus NORMAL, distingué d'une panne afin que l'application cliente le traite correctement. L'ouverture d'un crédit incrémente le compteur de la fenêtre courante — faute de quoi une seule cérémonie procurerait à la fois le crédit et un seuil intact.
14. Aucune facturation à la lecture, jamais. Choix d'architecture délibéré, et non simple politique commerciale : un client facturé à la lecture se met à éviter de lire, c'est-à-dire à contourner sa propre protection. Une protection qu'on a intérêt à contourner n'est pas une protection.
15. Ce que le mécanisme NE garantit PAS. Divulgué au même titre que le reste, parce qu'une limite tue est un mensonge. Le mécanisme à deux parts ne protège pas contre un attaquant durablement installé sur le système du client : pendant une opération autorisée, la clé reconstituée existe nécessairement en mémoire sur ce système, et un accès privilégié persistant peut l'y observer. Le mécanisme réduit la fenêtre d'exposition et rend chaque ouverture traçable et attribuable ; il ne rend pas invulnérable un système déjà compromis.
16. Empreinte perceptuelle par segments, robuste au ré-encodage. L'œuvre est découpée en segments temporels ; chaque segment reçoit une empreinte calculée par une transformation choisie pour survivre au ré-encodage, au redimensionnement et au changement de conteneur que les plateformes de diffusion appliquent systématiquement. L'empreinte est un RAPPORT D'ORDRE entre blocs voisins, jamais une valeur absolue : elle ne dépend donc ni de la luminosité, ni du contraste, ni du filtre de redimensionnement, et reste identique d'une machine à l'autre. Le découpage par segments permet de répondre non pas « oui ou non » mais OÙ : les passages altérés sont localisés dans le temps.
17. Liaison conjointe de l'image et du son. Chaque segment porte une composante visuelle ET une composante sonore calculées sur le MÊME intervalle, scellées ensemble et non comme deux sceaux indépendants. Trois substitutions distinctes sont ainsi détectées : le remplacement de la piste sonore sur des images authentiques — l'attaque la moins chère à fabriquer, puisque cloner une voix coûte moins que refaire un visage ; le remplacement des images sur un son authentique ; et le DÉCALAGE TEMPOREL d'une piste par rapport à l'autre, qui ne substitue aucun contenu mais peut inverser le sens d'une réponse en la déplaçant sous une autre question. Le résultat indique laquelle des deux pistes a échoué. Pour une œuvre sonore seule — musique, balado, allocution sans images — la composante sonore suffit et tout le reste de la méthode s'applique inchangé.
18. Extrait distingué de la falsification. Les empreintes étant conservées dans l'ordre et alignées à la trame, un extrait légitime est reconnu comme sous-suite contiguë et confirmé AVEC sa position dans l'œuvre d'origine — l'information même qui permet de repérer un extrait dont le découpage renverse le sens. Un remontage de segments authentiques dans un ordre différent est rapporté comme tel. Un système qui crierait à la fraude sur chaque extrait honnête cesserait d'être écouté.
19. Autorisation portant sur un ensemble énuméré. La cérémonie à deux personnes est exigée au scellage, jamais à la lecture : une œuvre scellée une fois se vérifie ensuite un milliard de fois, gratuitement et sans approbation de quiconque. Pour rendre la cérémonie tenable à l'échelle d'un catalogue, une autorisation peut porter sur un ENSEMBLE ÉNUMÉRÉ d'œuvres FIGÉ AVANT la signature, présenté à la personne qui approuve avec son décompte. Toute tentative de sceller une œuvre absente de l'ensemble est refusée et journalisée. Ce qui est exclu, et l'exclusion est le cœur du mécanisme, c'est l'autorisation « ouverte » valable pendant un intervalle : un adversaire n'aurait qu'à y glisser son œuvre.
20. Ensemble de distribution autorisé. L'entité déclare les comptes et domaines où l'œuvre a le droit de paraître. Une œuvre authentique présentée ailleurs n'est PAS confirmée : le résultat signale une republication non autorisée et nomme les lieux légitimes. C'est le seul moyen de traiter le contexte détourné — des images authentiques republiées sur un site qui se fait passer pour le diffuseur sont authentiques dans chaque octet, et tout contrôle qui n'examine que les octets prête son autorité à la tromperie.
21. Ce que le système NE garantit PAS. Une altération à la fois très petite et très brève peut passer sous le seuil de décision. Sur une œuvre très répétitive, un extrait peut correspondre à plusieurs positions. Les plateformes protégées par gestion de droits numériques ne laissent aucun navigateur lire leur flux ni aucune capture logicielle atteindre leur image ; elles restent néanmoins vérifiables par captation optique (point 24), qui ne fait que capter la lumière et ne contourne aucune protection. Et le sceau confirme QUI a publié et que RIEN n'a été modifié — jamais que ce qui est dit dans l'œuvre est vrai.
22. Ce que le navigateur interdit, et pourquoi il existe plusieurs chemins. Mesuré dans un navigateur non modifié : une page servie par un site ne peut ni lire les octets d'une vidéo servie par un autre site, ni lire un seul point de son image une fois affichée — la vidéo joue parfaitement et demeure illisible. C'est le modèle de sécurité du navigateur, pas une limite du service. La vérification par adresse ne dit donc jamais ce que contient le flux servi : elle dit ce qui est déclaré pour ce lieu. Pour examiner le contenu lui-même, il faut le fichier, ou une captation que le spectateur autorise lui-même sur son propre appareil.
23. Délimitation de l'écran avant l'empreinte. Lorsqu'une captation contient l'écran ET ce qui l'entoure, l'empreinte décrirait la pièce autant que l'œuvre. La zone occupée par l'écran est donc délimitée d'abord, sans chercher ni contour ni ligne droite : on mesure, pour chaque point de l'image, l'écart entre sa valeur maximale et sa valeur minimale sur quelques secondes. Un mur ne change jamais ; un point d'écran finit toujours par changer. Le seuil est pris sur un quantile et non sur une valeur absolue, le bruit de capteur variant avec l'éclairage. Si rien ne bouge, aucune zone n'est délimitée, aucune empreinte n'est calculée et aucune requête n'est envoyée : viser un plafond ne produit pas de verdict.
24. La piste qui décide dépend du canal, et les deux canaux se comportent à l'inverse. Sur une capture d'écran, le cadrage est choisi par l'usager et déplace l'empreinte visuelle au-delà de la tolérance, tandis que le son de l'onglet reste fidèle : le son décide. Sur une captation par caméra, c'est l'inverse — l'empreinte visuelle survit à la perspective et au bruit de capteur, tandis que le son traverse la pièce et revient déformé : l'image décide, le son ne fait que corroborer par une médiane sur toute la fenêtre. Chaque canal porte sa propre tolérance, fixée par mesure. Et sur le canal optique, aucun verdict d'intégrité n'est rendu : le bruit de ce canal dépasse la signature d'une altération locale, de sorte qu'aucun seuil ne sépare les deux — un seuil serré accuserait l'œuvre authentique, un seuil large certifierait la fausse. La caméra dit donc DE QUELLE œuvre il s'agit et QUI en répond ; savoir si cette copie-ci a été modifiée exige le fichier ou l'adresse. Ce refus est imposé par le serveur, pas par l'appareil du vérificateur.
25. Condensé exact. Lorsque le vérificateur détient le fichier, un condensé cryptographique est comparé AVANT toute empreinte : il répond non pas « est-ce la même œuvre, à une tolérance près » mais « est-ce le même fichier, octet pour octet ». Il ne remplace pas l'empreinte, les octets changeant à chaque ré-encodage. Une identité parfaite reste subordonnée aux lieux autorisés : des octets identiques ne rendent pas légitime une republication.
26. Code de direct porté par le son. Une diffusion en cours n'a pas encore d'empreinte. Le code de fenêtre peut donc aussi être émis dans la piste sonore, à une hauteur au-dessus de l'audition ordinaire mais à l'intérieur de la bande que conserve le codage de diffusion, et renouvelé à chaque fenêtre. Le spectateur approche son appareil, qui décode le son LOCALEMENT et n'envoie que les six caractères. Ce qui rend le procédé sain ici alors qu'un filigrane ne l'est pas sur une œuvre enregistrée : un filigrane se copie, alors qu'un code de fenêtre copié ne vaut plus rien une minute plus tard. Un code n'est accepté que s'il est lu deux fois à la bonne distance, faute de quoi du son ordinaire finirait par produire un code plausible.
27. Preuve de contrôle du canal. La vérification d'identité établit qu'un humain réel s'est inscrit avec ses propres papiers ; le KYB établit qu'une entreprise existe et qui la représente. Ni l'un ni l'autre n'établit que l'entité contrôle la chaîne où elle prétend publier. Un imposteur peut passer une vérification d'identité avec ses VRAIS papiers, sous son VRAI nom, puis déclarer la chaîne de quelqu'un d'autre. Le maillon manquant est donc une preuve de contrôle : Seal remet un code stable pour le couple (entité, canal), l'entité le place là où seul le titulaire peut écrire — un fichier à une adresse convenue sur son propre domaine, ou la description publique du canal — et Seal va le lire. Un canal PROUVÉ ne peut plus être revendiqué par un second. Et un lieu de publication non prouvé est REFUSÉ au scellage : l'œuvre reste scellable, mais Seal n'affirmera jamais un lieu que personne n'a contrôlé. Le refus distingue « la page a été lue et le code n'y était pas » de « la page n'a pas pu être lue » : certaines plateformes bloquent les serveurs, et ce n'est pas la faute de l'usager.
28. Ancrage public des scellages. La date d'un scellage reposerait autrement sur nos seuls registres et notre seule horloge — et une partie adverse aurait raison de dire que nous pourrions antidater. Chaque jour clos, une racine de Merkle de tous les scellages du jour est donc calculée et soumise aux serveurs de calendrier OpenTimestamps, qui l'inscrivent dans la chaîne Bitcoin. Chaque œuvre reçoit son chemin dans l'arbre : quiconque peut recalculer la racine et vérifier l'ancrage sans nous faire confiance, et le pourrait encore si Seal disparaissait. Un niveau impair reporte la dernière feuille au lieu de la dupliquer, la duplication ouvrant une faiblesse connue où deux arbres différents donnent la même racine. Une seule soumission par jour : les calendriers sont un bien commun, et un arbre donne la même force de preuve qu'un envoi par œuvre. Ce que cela prouve : qui a scellé en premier. Ce que cela ne prouve pas : qui a créé en premier — c'est la preuve de contrôle du canal, au point 27, qui ferme cette porte.
29. Le badge qui se dénonce, appliqué aux œuvres. Un badge posé sous une vidéo est une image, et une image se copie : un faux lieu l'afficherait pour se donner l'air garanti. Le badge média n'est donc pas une image inerte — il est servi par Seal, qui lit le témoin que le navigateur pose lui-même et compare le lieu d'affichage aux lieux déclarés pour cette œuvre. Hors de ces lieux, il devient rouge et énonce l'anomalie dans la langue du visiteur : l'imposteur qui copie le badge copie son propre accusateur. Témoin absent, aucune accusation — condamner sur une absence de preuve serait la faute symétrique. Et le badge ne remplace pas la vérification : ce qui protège réellement, c'est que le spectateur arrive chez Seal par sa propre navigation.
30. Enregistrement-leurre à empreinte, indiscernable du refus ordinaire.
Le métrage du point 13 dit « c'est peut-être anormal » ; ce mécanisme-ci dit
« c'est un vol, maintenant ». Le service fabrique une enveloppe ayant
exactement la forme d'une vraie — même dérivation de clé, même
chiffrement authentifié, même longueur — enveloppant un tirage aléatoire :
elle n'ouvre rien, et déballée elle ne livrerait aucune clé utile. Le service
n'en conserve que l'empreinte cryptographique ; l'enveloppe elle-même
n'est montrée qu'une fois et ne peut pas être réaffichée, y compris à
l'entité qui l'a créée — une enveloppe de leurre relisible dans le portail
serait relisible par un intrus dans le portail, donc évitable. L'entité la
place dans un enregistrement fantôme qu'aucun de ses programmes
légitimes ne lit jamais.
À chaque demande de déballage, l'empreinte de chaque enveloppe du lot
est comparée aux empreintes de leurres du coffre. En cas de correspondance,
le lot entier est refusé avec le message exact d'une enveloppe invalide
— le même que pour une enveloppe appartenant à un autre coffre, et sans écart
de temps mesurable. C'est la propriété qui fait tenir le mécanisme : si le
service répondait « leurre détecté », l'attaquant déballerait une enveloppe à
la fois, cartographierait les leurres par bissection et les éviterait.
Un lot refusé pour cause de leurre est en outre compté au métrage
comme s'il avait été déballé — sans quoi la cartographie des leurres
serait gratuite et sans trace.
Deux réponses configurables : alerter et refuser le lot ; ou alerter,
refuser et faire tourner la clé du coffre. La rotation est un
arrêt réversible, non une destruction : la version précédente de la
clé est conservée et peut être restituée. C'est nécessaire, et non
cosmétique — une rotation irréversible ferait de chaque leurre une arme
contre son propriétaire, puisque l'attaquant qui a lu la base possède les
leurres : il en soumettrait un, et détruirait définitivement les enveloppes
existantes ainsi que la part imprimée conservée hors ligne, la version de clé
entrant dans sa dérivation.
Deux précautions accompagnent le procédé. Le repère d'un leurre est
contraint à un identifiant court sans espace : il sert à reconnaître
l'enveloppe dans l'alerte, et ce format empêche qu'une phrase contenant des
données personnelles n'arrive au service puis ne reparte dans une
notification. Et l'empreinte est vérifiée sous sa forme canonique
et sous la forme héritée d'une version antérieure du format, afin
qu'un changement de représentation ne désarme jamais, en silence, des leurres
déjà posés.
31. Sceau vivant : la bande dont la teinte et les mots changent à
chaque fenêtre, et qui distingue une copie d'un original.
Le point 9 démasque le faussaire qui inclut le sceau depuis nos
serveurs : le témoin d'origine posé par le navigateur le trahit. Il ne voit
rien, en revanche, du faussaire qui enregistre l'image du sceau et la
sert depuis son propre hébergement — aucune requête ne nous parvient, donc
aucun témoin n'existe. Or une image enregistrée est figée : c'est sa
seule faiblesse, et ce mécanisme la transforme en signature.
Le sceau porte une seconde partie, dessinée dans la page et non
incluse comme image — contrainte imposée par les navigateurs, qui
n'exécutent aucun script dans une image. Cette bande affiche, pour la fenêtre
de temps en cours : le code public de six chiffres, une teinte prise dans
une palette arrêtée, le nom écrit de cette teinte, et un
second mot tiré d'une liste arrêtée. Teinte et mot sont dérivés par
fonction de hachage à clé du couple (domaine affichant le sceau, fenêtre
de temps), au moyen d'une sous-clé propre à cet usage, distincte
de celle du code affiché : l'habit ne révèle donc rien du code, et deux
domaines ne portent jamais le même habit au même instant.
Trois vérifications en découlent, ordonnées du moindre au plus grand
effort. La bande change d'elle-même : une copie enregistrée reste
immobile. Les mots sont du texte véritable, sélectionnable et lisible
par un lecteur d'écran : une image copiée ne l'est pas. Et les mots affichés
correspondent à ceux que le service publie pour ce domaine à cet
instant. Le mot n'est pas tiré au hasard mais dérivé : un mot
véritablement aléatoire serait invérifiable, y compris par le service.
Deux exigences rendent le procédé sûr plutôt que décoratif. La teinte
ne porte jamais l'information seule — le nom écrit l'accompagne
toujours, et la palette exclut les deux teintes qui portent déjà le
verdict, afin qu'aucun verdict ne soit lu là où il n'y en a pas. Et
l'absence de réponse n'accuse pas : la bande énonce alors que le code
est indisponible, ni vérifié ni contesté — accuser sur une absence de preuve
serait la faute symétrique de celle que le mécanisme combat.
Le service refuse enfin de calculer lorsque l'origine déclarée
par le navigateur ne correspond à aucun domaine officiel de l'entité, et rend
alors la même réponse que pour un domaine inconnu : le faussaire n'apprend
pas ce qui a été compris. Demeure hors de portée le relais côté serveur,
qui n'émet aucune origine ; il se traite par la détection — une adresse
unique réclamant en boucle le code d'un domaine unique sans jamais présenter
d'origine — et non par le refus, refuser sur l'absence d'origine coupant
tout appel légitime hors navigateur.
Cette divulgation décrit volontairement le mécanisme complet afin de constituer de l'art antérieur opposable. La marque « Seal LIFAIO », le nom « LIFAIO » et l'emblème du cachet demeurent des marques de commerce de Technologies Marco Prive — la divulgation du mécanisme n'accorde aucun droit sur les marques.