Métadonnées PDF et données cachées
Dernière mise à jour:
Les métadonnées d’un document sont les informations qu’un fichier transporte sur lui-même au-delà du contenu de la page : qui ses champs prétendent l’avoir écrit, quelle application l’a produit, quand il dit avoir été créé et modifié, et quel matériau antérieur se trouve encore dedans. Un PDF peut contenir deux systèmes de métadonnées qui se chevauchent, une chaîne de révisions antérieures, des fichiers complets incorporés et du texte dessiné de façon invisible ; une photo JPEG contient un journal d’appareil photo ; même une simple capture PNG nomme le logiciel qui l’a faite. Cet article parcourt chacune de ces cachettes, explique pourquoi les données survivent à l’édition ordinaire et comment les vraies fuites se sont produites. Pour inspecter un de vos fichiers en lisant, lancez l’outil de forensique de documents — il fonctionne localement dans votre navigateur — et pour le côté structure de lecture des mêmes fichiers, voyez vos PDF font partie de l’accessibilité de votre site web.
Deux systèmes de métadonnées voyagent dans chaque PDF
Le plus ancien est le dictionnaire d’informations, un petit ensemble de paires clé–valeur stocké dans la bande-annonce du fichier : Title, Author, Creator (l’application qui a fait le document d’origine), Producer (l’application qui a fait le PDF), CreationDate et ModDate. Ces champs sont écrits automatiquement à l’exportation, et la plupart des auteurs de documents n’ouvrent jamais la boîte de dialogue des propriétés qui les montrerait — c’est exactement pour cela qu’ils fuient. Un rapport exporté depuis un ordinateur portable personnel porte le nom du compte de cet ordinateur comme auteur. Un document commencé depuis le modèle de l’année dernière nomme encore l’auteur de l’année dernière. Rien de tout cela ne se voit sur la page imprimée, et tout est à un panneau de propriétés de distance pour chaque destinataire du fichier.
Le système le plus récent est XMP, un paquet XML incorporé au document, construit sur la plateforme de métadonnées extensible d’Adobe et décrit avec la spécification PDF elle-même, ISO 32000-2. XMP répète une grande partie du même terrain dans des espaces de noms : dc:title pour le titre, pdf:Producer, xmp:CreateDate et xmp:ModifyDate, plus des champs que l’ancien dictionnaire n’a jamais eus, comme l’outil créateur. Avoir deux systèmes serait inoffensif s’ils étaient tenus au même pas, mais ils ne le sont pas : un outil met à jour le dictionnaire d’informations et ignore XMP, un autre réécrit XMP et laisse le dictionnaire périmé, un troisième supprime l’un et garde l’autre. Le résultat est qu’un seul fichier raconte couramment deux histoires légèrement différentes sur lui-même — et le désaccord est lui-même une information, car il enregistre que plus d’un outil, à plus d’un moment, a mis les mains sur le document.
Mises à jour incrémentales : le paragraphe supprimé qui n’est jamais parti
PDF a été conçu pour l’édition par ajout seulement. Quand un éditeur enregistre un changement de façon incrémentale, il ne réécrit pas le fichier : il ajoute les objets modifiés, une nouvelle section de références croisées et une nouvelle bande-annonce à la fin, en chaînant vers la bande-annonce précédente par un pointeur /Prev. Chaque révision se termine par son propre marqueur %%EOF, donc compter ces marqueurs donne une borne inférieure du nombre de fois où le fichier a été enregistré ainsi — et chaque révision antérieure reste physiquement présente et lisible dans les octets. Ouvrez un tel fichier dans un afficheur ordinaire et vous ne voyez que la révision la plus récente. Lisez les octets, ou remontez la chaîne, et l’état antérieur du document est toujours là : l’ancien chiffre du tableau, la formulation précédente de la clause, le paragraphe supprimé avant publication.
C’est le mécanisme derrière les échecs de masquage qui continuent de faire les nouvelles. Une équipe doit publier un rapport dont les noms ou les chiffres sont retenus, alors quelqu’un dessine des rectangles noirs sur les passages sensibles — une opération de dessin qui change l’apparence de la page et ne touche à rien en dessous — ou supprime le texte dans un éditeur qui enregistre ensuite de façon incrémentale, laissant les objets supprimés dans une révision antérieure. Le fichier publié semble propre. Quelques jours plus tard, un lecteur sélectionne la région « masquée », la copie et colle les mots d’origine dans un éditeur de texte ; ou un chercheur analyse la chaîne de révisions et récupère ce qui avait été retiré. Le vrai masquage est une opération différente de couvrir : le contenu sous-jacent doit être retiré du flux de contenu et le fichier entièrement réécrit, pour que les octets eux-mêmes ne contiennent plus ce que la page ne montre plus. Si un fichier que vous allez publier porte plusieurs marqueurs %%EOF, son histoire est encore dedans — partez du principe qu’un lecteur motivé lira cette histoire.
Fichiers incorporés et texte caché : la cargaison que personne ne liste
Un PDF peut transporter des fichiers complets en lui-même. Le format définit une arborescence de noms de fichiers incorporés, à laquelle on accède par les objets /EmbeddedFiles et /Filespec, et les outils de création l’utilisent pour les feuilles de calcul sources, les annexes de données et les documents de portefeuille. Le panneau des pièces jointes qui les révélerait est un panneau que la plupart des lecteurs n’ouvrent jamais, donc la cargaison incorporée voyage en silence : publiez le résumé PDF soigné et vous publiez peut-être aussi la feuille de calcul de travail derrière lui, complète avec ses propres métadonnées, ses feuilles de brouillon et ses commentaires. L’inverse vaut aussi pour les destinataires : une pièce jointe dans un PDF reçu hérite de la confiance du document qui l’entoure, et c’est pourquoi les fichiers incorporés méritent une ligne dans toute liste d’inspection plutôt qu’une découverte par accident.
Le texte peut se cacher sans être un fichier séparé. PDF peint le texte avec un mode de rendu, et le mode 3 — défini par l’opérateur 3 Tr — ne peint ni remplissage ni contour : les caractères sont dans le flux de contenu, ils peuvent être sélectionnés, recherchés et extraits, et ils sont complètement invisibles sur la page. Une partie du texte invisible est légitime et précieuse : la couche OCR derrière une page numérisée est exactement cela, du texte caché qui rend une image interrogeable. Le problème est tout le reste qui finit en mode 3 ou chez ses cousins — texte blanc sur fond blanc, texte rogné hors de la page visible, couche de mots-clés ajoutée pour les moteurs de recherche — parce qu’un lecteur qui extrait la couche de texte reçoit des mots que la page n’a jamais montrés. Quand la couche cachée contredit la couche visible, le fichier dit deux choses à la fois, et une seule des deux a été relue.
Les images aussi tiennent un journal : blocs PNG et Exif en JPEG
Un fichier PNG est une séquence de blocs nommés, et plusieurs types de blocs existent uniquement pour transporter du texte : tEXt, son frère compressé zTXt et l’internationalisé iTXt. Les outils d’exportation les écrivent par habitude — un mot-clé Software nommant l’éditeur, une chaîne d’outil de création, parfois un profil XML incorporé entier — et ils survivent à chaque recadrage et redimensionnement qui laisse la liste des blocs intacte. Le bloc tIME ajoute un horodatage de dernière modification, un bloc eXIf peut contenir un bloc complet de métadonnées d’appareil photo, et les octets ajoutés après le bloc de fermeture IEND sont ignorés par tout afficheur tout en restant dans le fichier. Une capture d’écran qui ressemble à une image neutre d’une fenêtre peut donc nommer le logiciel de la machine, se dater elle-même et transporter des données que son auteur n’a jamais vues.
Les photos JPEG vont plus loin. Le fichier est une chaîne de segments de marqueurs : APP0 transporte l’en-tête JFIF, APP1 transporte soit un bloc Exif, soit un paquet XMP — parfois les deux. Les champs IFD0 d’Exif se lisent comme le journal d’un appareil photo : Make et Model de l’appareil, le DateTime auquel la photo a été prise ou modifiée pour la dernière fois, le Software qui l’a traitée et, dans les répertoires étendus, les coordonnées GPS. Des photos de téléphone publiées directement depuis la pellicule ont embarrassé organisations et particuliers en les plaçant, précisément, à un moment et en un lieu que la photo elle-même n’a jamais montrés. Les segments de commentaire (COM) ajoutent du texte libre du dernier outil qui a enregistré le fichier, des octets excédentaires peuvent rester après le marqueur de fin d’image, et l’outil qui lit tout cela — ExifTool de Phil Harvey, cité dans les sources — est un téléchargement gratuit, ce qui signifie que vos destinataires peuvent le lire aussi.
Recoupez les horodatages, puis nettoyez avant de publier
Un seul horodatage est une affirmation ; plusieurs horodatages sont une histoire qui peut être recoupée avec elle-même. Une date de création qui tombe après la date de modification ne peut pas décrire un document produit par un outil en une seule passe. Une date du dictionnaire d’informations qui contredit la date XMP pour le même événement enregistre deux outils avec deux horloges. Une date dans le futur enregistre une horloge mal réglée, un champ modifié à la main ou un fichier assemblé à partir de pièces. Même le format de date PDF lui-même invite à l’ambiguïté : la chaîne D: peut omettre son fuseau horaire, laissant les lecteurs deviner de quelle horloge viennent les nombres. Traitez chaque incohérence comme un auditeur traite un écart de grand livre : elle a habituellement une explication innocente — réutilisation d’un modèle, horloge d’un ordinateur portable, optimiseur qui a réécrit le fichier lors du téléversement — et c’est une preuve à peser, jamais un verdict à elle seule. Les champs de métadonnées peuvent être modifiés par quiconque dispose d’outils gratuits, donc ils corroborent ou contredisent une histoire ; ils ne peuvent pas la prouver.
Nettoyer est donc un flux de travail, pas un bouton. D’abord, inspectez : faites passer le fichier dans l’outil de forensique de documents et notez ce qu’il dirait à un inconnu — noms d’auteur et d’outils, nombre de révisions, fichiers incorporés, texte caché, horodatages qui se disputent. Ensuite, corrigez à la source quand vous le pouvez : corrigez les propriétés du document dans l’application de création plutôt que de rafistoler sa sortie. Troisièmement, exportez une réécriture complète et fraîche — impression en PDF, nettoyeur dédié ou ExifTool pour les images — car une réécriture complète écarte les révisions antérieures, les objets orphelins et les données excédentaires d’une façon que l’enregistrement incrémental ne fera jamais. Enfin, revérifiez la copie que vous envoyez réellement, pas celle que vous comptiez envoyer. Et gardez la distinction sur laquelle repose tout l’article : les originaux internes doivent conserver leurs métadonnées, car la provenance, la valeur d’archive et même l’accessibilité — un titre de document est aussi une métadonnée — en dépendent. Nettoyez la copie publiée et conservez l’enregistrement intact à la maison.