Le ZIP de preuve expliqué — fichier par fichier

Ce qu’était réellement la page au moment de la capture.

• screenshot.png — capture d’écran pleine page rendue au moment de la capture, réalisée par Playwright (Chromium) avec une largeur de zone d’affichage de 1280 px et un défilement pleine hauteur
• page.html — le DOM/HTML capturé au moment de la capture — utile pour inspecter la structure, les liens et les scripts réellement fournis
• content.txt — contenu texte brut extrait — ce qu’un lecteur aurait réellement vu sur la page, débarrassé du balisage
• capture.webm — enregistrement d’écran de toute la session de capture au format WebM/VP9. Capture tout contenu dynamique, animation ou interaction (comme le traitement des fenêtres de consentement) qu’une capture d’écran statique ne peut pas montrer. Preuve utile pour le contenu temporel ou interactif.

Comment la capture s’est déroulée — la piste d’audit.

• proof.json — l’enregistrement principal de la preuve : Proof ID, URL source, URL finale après redirections, horodatage de capture, toutes les empreintes SHA-256 (contenu, capture d’écran, HTML brut), mode de capture (serveur/navigateur), statut eIDAS, informations d’ancrage
• capture/capture_meta.json — métadonnées forensiques détaillées sur la capture elle-même : moteur de capture (Playwright + version du navigateur), user agent, zone d’affichage, dimensions complètes de la page après défilement à chargement différé, fenêtres de consentement traitées automatiquement et méthode utilisée, appels IA utilisés, tours de défilement, statut de chargement des images, score de qualité visuelle, verdict de réussite
• capture/capture_meta.sha256 — SHA-256 de capture_meta.json stocké séparément — référencé par le contenu eIDAS afin que les métadonnées de capture soient aussi couvertes par l’horodatage qualifié

Qui a réellement servi la page, ce qui a été chargé depuis où, et quelles IP ont répondu pour le domaine (selon ISO/IEC 27037 § 6.4–6.5).

• network/capture.har — Archive HTTP (spécification HAR 1.2) de chaque requête réseau effectuée par le navigateur pendant la capture : URL, méthode, en-têtes de requête/réponse, code de statut, taille de réponse, type MIME, ventilation complète des temporisations (DNS, connexion, TLS, envoi, attente, réception). Permet à un réviseur de voir exactement quels actifs, scripts, traqueurs, appels tiers et redirections étaient impliqués.
• network/network_evidence.json — fichier d’index lisible (identifiant de format getproofanchor-network-evidence-1) : URL cible, nom d’hôte, heure de capture, et indicateurs des fichiers de preuve réseau présents. Un fichier d’orientation rapide pour les réviseurs forensiques.
• network/tls.json — métadonnées de handshake lisibles au format JSON : version TLS (p. ex. TLSv1.3), suite de chiffrement, IP du serveur ayant répondu, SNI, période de validité du certificat, tous les Subject Alternative Names, empreintes complètes de la chaîne (SHA-256 + SHA-1), indicateur de correspondance du nom d’hôte, statut OCSP — tout ce dont un réviseur a besoin pour inspecter la connexion sans analyser le X.509.
• tls/leaf_cert.pem — le certificat feuille X.509 du serveur au format PEM, tel que présenté pendant le handshake TLS. Le SHA-256 de ce fichier est lié au contenu eIDAS — de sorte que l’identité cryptographique du serveur est horodatée avec le contenu de la page.
• tls/chain.pem — la chaîne complète de certificats intermédiaires + racine au format PEM. Permet à un réviseur de valider le certificat feuille hors ligne jusqu’à une CA publique connue. Le SHA-256 de ce fichier est aussi lié au contenu eIDAS.
• network/dns.json — résolution DNS multi-résolveurs au moment de la capture, interrogée indépendamment auprès de Cloudflare (1.1.1.1), Google (8.8.8.8) et Quad9 (9.9.9.9) : enregistrements A, AAAA, CNAME avec TTL. Si plusieurs résolveurs concordent, c’est une preuve solide que le domaine résolvait réellement vers ces IP à ce moment-là.
• network/rdap.json — résultat de requête RDAP (remplacement moderne de WHOIS) : titulaire du domaine, bureau d’enregistrement, date d’enregistrement, date d’expiration, date de dernière modification, serveurs de noms, indicateurs de statut. Établit qui contrôle le domaine au moment de la capture.

Ensemble, ces fichiers répondent aux questions qu’un contre-interrogatoire hostile posera : qui contrôlait ce domaine ? Quelle IP a réellement répondu pour lui ? Quel certificat le serveur a-t-il présenté, et son identité était-elle liée à l’horodatage ?

Pour les humains, pas pour les machines.

• README.md — guide de vérification bilingue (anglais + tchèque) pour les experts forensiques. Parcourt les 4 étapes de vérification avec des commandes à copier-coller utilisant uniquement python3, openssl et le client ots.
• report.pdf — rapport de preuve lisible (~1 Mo). Résumé mis en forme avec Proof ID, URL capturées, horodatages, toutes les empreintes SHA-256, informations d’ancrage blockchain, statut eIDAS — adapté aux dossiers et aux impressions.

• python3 — tout fonctionne sur Linux, macOS et Windows. Utilisé pour les étapes 1, 2 (voie alternative) et 4.
• openssl — standard sur Linux/macOS ; sur Windows, utilisez Git Bash ou WSL. Utilisé pour la vérification eIDAS canonique (étape 2).
• ots (depuis pip install opentimestamps-client) — pour la vérification Bitcoin OpenTimestamps (étape 3). Optionnel — vous pouvez aussi vérifier en téléversant le reçu sur opentimestamps.org ou en contrôlant la transaction Bitcoin sur un explorateur de blocs.

Continuez avec : Widget de navigateur — installer, connecter la clé API, capturer derrière une connexion (Enterprise et Business).