Co je Evidence ZIP?
Evidence ZIP je přenosný, samonosný balíček, který můžete exportovat z libovolného proofu. Identifikátor formátu:
getproofanchor-evidence-4. Typický balíček obsahuje kolem 30 souborů uspořádaných do 6 adresářů; velikost závisí na stránce (typicky 5–15 MB bez videa; až 100–150 MB se zapnutým videem a plným HAR archivem). Je navržený tak, aby opustil váš účet — pro archivaci, přiložení ke spisu, předložení regulátorovi nebo odeslání nezávislému recenzentovi.
Klíčová vlastnost není „jen export“ — klíčové je, že balíček lze později ověřit zcela offline , pouze pomocí standardních open-source nástrojů. Bez internetu, bez služby GetProofAnchor, bez účtu.
Všechny externí závislosti, které by ověření mohlo potřebovat, jsou zmrazené uvnitř ZIPu samotného: kryptografický manifest, záznamy proofu v hash chainu, Bitcoin OpenTimestamps receipt, plný certifikační řetězec kvalifikované TSA a dokonce snapshot EU Trusted List (LOTL), který dokazuje, že TSA byla v okamžiku razítkování oficiálně uznaná. Kdyby GetProofAnchor zítra zmizel, váš Evidence ZIP by se ověřil úplně stejně — kýmkoli, kdekoli, s notebookem a Pythonem.
Co je doopravdy uvnitř (každý soubor, podle účelu)
Otevřete ZIP a uvidíte něco takového — kolem 30 souborů v šesti adresářích. Jsou tady seskupené podle toho, k čemu slouží: zachycený obsah, kontext capture, důkazy síťové identity, kryptografické integritní vrstvy a dokumentace pro lidi.
Co stránka v okamžiku zachycení skutečně byla.
screenshot.png— celostránkový screenshot vykreslený v okamžiku capture, pořízený přes Playwright (Chromium) ve viewportu šířky 1280 px s plným scrollem do výšky stránkypage.html— zachycené DOM/HTML v okamžiku capture — užitečné pro inspekci struktury, odkazů a skriptů, které byly skutečně doručenycontent.txt— extrahovaný čistý text — to, co by čtenář na stránce skutečně viděl, bez markupucapture.webm— záznam obrazovky celé capture session ve formátu WebM/VP9. Zachycuje veškerý dynamický obsah, animace nebo interakce (jako obsluhu consent dialogů), které statický screenshot ukázat nemůže. Užitečný důkaz pro časově závislý nebo interaktivní obsah.
Jak capture proběhl — auditní stopa.
proof.json— hlavní záznam proofu: Proof ID, source URL, finální URL po přesměrováních, čas zachycení, všechny SHA-256 otisky (obsah, screenshot, raw HTML), režim capture (server/browser), eIDAS status, info o anchorucapture/capture_meta.json— detailní forenzní metadata o samotném capture: capture engine (Playwright + verze prohlížeče), user agent, viewport, plné rozměry stránky po lazy-load scrollu, automaticky vyřízené consent dialogy a metoda použitá k jejich odbavení, počet AI volání, počet scroll kol, status načítání obrázků, visual quality score, výsledek (verdict)capture/capture_meta.sha256— SHA-256 souboru capture_meta.json uložený zvlášť — referencovaný eIDAS payloadem, takže i metadata capture jsou pokryta kvalifikovaným razítkem
Kdo stránku skutečně obsluhoval, co se odkud načítalo a které IP pro doménu odpovídaly (podle ISO/IEC 27037 § 6.4–6.5).
network/capture.har— HTTP Archive (specifikace HAR 1.2) každého síťového requestu, který prohlížeč během capture provedl: URL, metoda, request/response hlavičky, status kód, velikost odpovědi, MIME typ, plné rozdělení časování (DNS, connect, TLS, send, wait, receive). Umožňuje recenzentovi přesně vidět, jaké assety, skripty, trackery, third-party volání a přesměrování byly v procesu.network/network_evidence.json— human-readable indexový soubor (identifikátor formátu getproofanchor-network-evidence-1): cílová URL, hostname, čas capture a flagy ukazující, které soubory síťových důkazů jsou přítomny. Rychlý orientační soubor pro forenzní recenzenty.network/tls.json— human-readable metadata o handshaku v JSON: verze TLS (např. TLSv1.3), cipher suite, IP serveru, který odpověděl, SNI, doba platnosti certifikátu, všechny Subject Alternative Names, fingerprinty celého řetězce (SHA-256 + SHA-1), flag shody hostname, OCSP status — všechno, co recenzent potřebuje k inspekci spojení bez parsování X.509.tls/leaf_cert.pem— leaf X.509 certifikát serveru v PEM formátu, jak byl předložen během TLS handshaku. SHA-256 tohoto souboru je svázaný do eIDAS payloadu — takže kryptografická identita serveru je orazítkovaná spolu s obsahem stránky.tls/chain.pem— plný řetězec intermediate + root certifikátů v PEM formátu. Umožňuje recenzentovi offline validovat leaf cert proti známé veřejné CA. SHA-256 tohoto souboru je rovněž svázaný do eIDAS payloadu.network/dns.json— multi-resolver DNS resolution v okamžiku capture, dotazovaná nezávisle proti Cloudflare (1.1.1.1), Google (8.8.8.8) a Quad9 (9.9.9.9): A, AAAA, CNAME záznamy s TTL. Když se více resolverů shoduje, je to silný důkaz, že doména v ten okamžik skutečně resolvovala na ty IP.network/rdap.json— Výsledek RDAP (moderní náhrada WHOIS) dotazu: registrant domény, registrátor, datum registrace, datum expirace, datum poslední změny, name servery, status flagy. Stanoví, kdo doménu v okamžiku capture ovládá.
Tyto soubory dohromady odpovídají na otázky, které položí nepřátelský křížový výslech: kdo tuhle doménu ovládal? Která IP pro ni skutečně odpovídala? Jaký certifikát server předložil a byla jeho identita svázaná s časovým razítkem?
Každá vrstva je nezávislá. Prolomení jedné nerozbije ostatní.
manifest.json— základ integrity: SHA-256 hash každého dalšího souboru v balíčku + chain head + metadata anchoru a eIDAS. Ověření vždy začíná tady. Jakákoli změna byte v jakémkoli souboru kontrolu shodí.
chain/proof_chain.jsonl— události tohoto proofu v globálním SHA-256 hash chainu (jeden JSON objekt na řádek: seq, event_type, prev_hash, data_hash, entry_hash, created_at). Vložení nebo úprava staršího záznamu chain rozbije.chain/chain_head.json— snapshot hlavy chainu, ke které byl tento proof ukotven — sekvenční číslo a entry hash. Použité pro ověření posledního článku chainu.
anchor/anchor_payload.json— minimální datová struktura, která byla uložena do Bitcoinu: hash hlavy chainu + observed UTC time + verze formátu. Před razítkováním kanonicky hashována.anchor/anchor_receipt.ots— binární OpenTimestamps receipt obsahující Merkle cestu zpět k Bitcoin transakci. Po potvrzení časové razítko drží celá Bitcoinová síť — ne GetProofAnchor.
Deset souborů dohromady tvoří kompletní, samonosný eIDAS verifikační kit.
timestamp/eidas.tsr— binární RFC 3161 TimeStampResp od kvalifikovaného poskytovatele důvěryhodných služeb — CMS-signed, ve stejném standardním PKI formátu, jaký používají soudy a regulátoři v EUtimestamp/eidas_payload.json— přesná data, která byla orazítkována, v kanonickém JSONu (řazené klíče, bez mezer). Svazuje 8 SHA-256 otisků do kvalifikovaného razítka: content_sha256, raw_html_sha256, screenshot_sha256, capture_meta_sha256, video_sha256, har_sha256, tls_leaf_pem_sha256, tls_chain_pem_sha256 — plus source_url, final_url, captured_at, proof_id. Identifikátor formátu: getproofanchor-eidas-stamp-5. Každý forenzní artefakt v balíčku je svázaný do jednoho kvalifikovaného razítka.timestamp/eidas_payload.sha256— SHA-256 výše uvedeného payloadu. Tento přesný hash je imprint embedded v RFC 3161 razítku, který kryptograficky propojuje razítko se zachycenými daty.timestamp/eidas_meta.json— high-level eIDAS status: jméno poskytovatele (aktuálně SK ID Solutions, Estonsko), URL TSA, přesný čas razítka, statustimestamp/<proof_id>.tsa_signer_cert.pem— X.509 certifikát konkrétní timestamping unit, která razítko podepsala — leaf cert v PEM formátutimestamp/<proof_id>.tsa_certs.pem— celý PEM certifikační řetězec: signer + intermediate CA + root CA. Umožňuje validovat řetězec offline bez stahování čehokoli.timestamp/<proof_id>.tsa_certs.json— stejný řetězec v JSON formě (subjects, issuers, sériová čísla, doby platnosti, SHA-256 fingerprinty) — snadno čitelné bez parsování PEMtimestamp/<proof_id>.qualified_context.json— kontext propojující TSA s EU Trusted List: zdrojová LOTL URL (eu-lotl.xml z ec.europa.eu), přesný čas stažení, SHA-256, a které country TSL jsou v balíčku přibalené. Identifikátor formátu: getproofanchor-eidas-qualified-context-2.timestamp/tsl/<COUNTRY>.xml— Trusted List členského státu EU v XML formátu (např. EE.xml pro estonskou TSA, CZ.xml pro českou atd.). Toto je ETSI-standardní country-level TSL, který dokazuje, že TSA byla v okamžiku razítkování oficiálně uznaná jako kvalifikovaný poskytovatel důvěryhodných služeb podle eIDAS. Soubor qualified_context.json výše vysvětluje, které country TSL byly přibalené a proč.timestamp/<proof_id>.eidas_verification_report.json— interní eIDAS verifikační report (identifikátor formátu getproofanchor-eidas-tsr-summary-1) vytvořený v okamžiku razítkování: status (granted), policy OID 0.4.0.2023.1.1, hash algoritmus, imprint digest v hex, signature_verified flag, shrnutí TSA certifikačního řetězce.
Pro lidi, ne pro stroje.
README.md— bilingvní (anglicko-český) verifikační návod pro forenzní znalce. Provede vás všemi 4 verifikačními kroky pomocí copy-paste příkazů s python3, openssl a ots klientem.report.pdf— human-readable Evidence Report (~1 MB). Formátované shrnutí s Proof ID, zachycenými URL, časy, všemi SHA-256 otisky, info o blockchain anchoru, eIDAS statusem — vhodné do spisu nebo k tisku.
Čtyři nezávislé integritní vrstvy
Důvěra není jeden mechanismus. Jsou to čtyři nezávislé vrstvy, každá s vlastními soubory v ZIPu. Prolomení jedné z nich nerozbije ostatní — útočník by musel pro zfalšování jediného proofu prolomit všechny čtyři současně, včetně rozbití Bitcoinu a zfalšování podpisu EU-kvalifikované TSA.
Hash každého souboru v balíčku. Pokud se změní jakýkoli byte v jakémkoli souboru — i třeba JSON whitespace — ověření selže.
Soubory: manifest.json
Události tohoto proofu jsou v globálním SHA-256 chainu. Každý záznam obsahuje hash předchozího. Vložení nebo úprava staršího záznamu chain matematicky rozbije.
Soubory: chain/*
Hlava chainu je ukotvena do Bitcoin blockchainu přes OpenTimestamps. Po potvrzení drží časové razítko celá Bitcoinová síť. Antedatování se stává nereálným.
Soubory: anchor/*
RFC 3161 razítko od EU-kvalifikované TSA, s plným certifikačním řetězcem a zmrazeným snapshotem EU Trusted List uvnitř. Právně uznáváno v EU/EHP dle nařízení (EU) 910/2014.
Soubory: timestamp/*
Všechny 4 ověření PROŠLY → balíček je kryptograficky neporušený, ne jen důvěryhodný. Každou vrstvu lze ověřit i samostatně a tím prokázat konkrétní vlastnost: integritu souborů, konzistenci chainu, čas existence (dvakrát — Bitcoinem a EU-akreditovanou TSA).
Jak ověřit (4-krokový postup)
Bilingvní
README.md
uvnitř ZIPu vás provede ověřením s copy-paste příkazy. Postup odpovídá jedna ku jedné čtyřem integritním vrstvám výše:
- Krok 1 — Integrita souborů — Skript v python3 přečte manifest.json, přepočítá SHA-256 každého souboru a porovná. PROŠEL = nic v balíčku nebylo přidáno, odebráno ani změněno.
- Krok 2 — eIDAS kvalifikované časové razítko — openssl ts -verify proti eidas.tsr + eidas_payload.json + přibalenému tsa_certs.pem. (Pro prostředí bez openssl je v README zahrnutá čistě Pythonová alternativa.) PROŠEL = zachycená data v daný okamžik existovala a podpis pochází od kvalifikované TSA zaznamenané ve snapshotu EU Trusted List.
- Krok 3 — Bitcoin anchor — ots verify anchor/anchor_receipt.ots -d <payload_sha> — nebo nahrát receipt na opentimestamps.org, případně zkontrolovat Bitcoin transakci přímo na veřejném block exploreru. PROŠEL = hlava chainu byla zapsána do konkrétního Bitcoin bloku.
- Krok 4 — Hash chain — Skript v python3 projde chain/proof_chain.jsonl, přepočítá každý entry hash z (prev_hash | event_type | proof_id | data_hash) a potvrdí návaznost na chain_head.json. PROŠEL = interní log událostí je neporušený.
Všechny 4 PROŠLY → balíček je kryptograficky neporušený. Krok 3 (Bitcoin) vyžaduje síť (nebo lze alternativně jen ověřit transaction ID na veřejném exploreru); kroky 1, 2 a 4 fungují zcela offline.
python3— funguje na Linuxu, macOS i Windows. Použité v krocích 1, 2 (alternativní cesta) a 4.openssl— standardně součást Linux/macOS; na Windows přes Git Bash nebo WSL. Použité pro kanonické eIDAS ověření (krok 2).ots(z pip install opentimestamps-client) — pro ověření Bitcoin OpenTimestamps (krok 3). Volitelné — můžete také ověřit nahráním receiptu na opentimestamps.org nebo kontrolou Bitcoin transakce na block exploreru.
Doporučení pro sdílení
- Sdílejte ZIP přesně tak, jak byl vyexportován. Nepřebalujte ho, nepřejmenovávejte soubory ani „neuklízejte“. Ověření závisí na tom, že každá cesta a každý byte jsou identické s tím, co bylo vygenerováno.
- Pokud lze, ukládejte na read-only nebo write-once média. Pomáhá doložit chain of custody, kdyby byl důkaz později zpochybněn.
- Mějte Proof ID a čas zachycení viditelné v poznámkách nebo titulním listu. Jsou také uvnitř proof.json a report.pdf, ale rychlá reference dělá spis přehlednější.
- Posuzovatele odkažte na README.md uvnitř ZIPu. Obsahuje copy-paste verifikační příkazy v angličtině i češtině a vysvětluje, co každý PROŠEL přesně znamená.
- Neextrahujte jednotlivé soubory pro přeposlání. Ověření vyžaduje celý balíček — manifest, chain, anchor, eIDAS kit. Vždy posílejte kompletní ZIP.
Exportujte si Evidence ZIP z proofu a pak ho ověřte. Hned uvidíte, jak striktní integritní kontroly jsou — a jak se balíček ověří i plně offline.
Nejde o právní poradenství. Přípustnost důkazu závisí na jurisdikci a konkrétních okolnostech.
Pokračujte na: Browser widget — instalace, připojení API klíče, zachycení za přihlášením (Enterprise & Business).