Module install 

Downloading a known-good browser.

Why this exists

Every other part of proofsheet is deterministic, and then the first run on a fresh machine fails because there is no Chrome. “Install Chrome” is a surprisingly bad instruction: a desktop Chrome auto-updates underneath you, so the browser producing your screenshots changes without you asking, and the images churn. Chrome for Testing exists precisely to be pinned.

Why it shells out, and why that reasoning is provisional

Fetching over HTTPS from Rust means a TLS stack, and unzipping means an inflate implementation; this crate has neither. The original argument was “the crate hand-rolls its WebSocket, so it should not take dependencies here either” – which is aesthetic consistency, not an engineering criterion, and it does not survive contact with the real questions: reliability, attack surface, portability, diagnosability, maintenance and size.

The counter-argument that actually bites: this command is the onboarding path, and depending on combinations of curl / unzip / python3 / PowerShell multiplies the environment states that must work. Dependency count is not the metric; controlled failure surface is.

So this implementation is treated as PROVISIONAL. It stays only while it behaves like a declared runtime dependency:

• tools are detected up front, before a 100MB download ([preflight])
• the archive lands in a temp path and a partial install is cleaned up
• the archive’s SHA-256 is recorded for continuity checking
• the installed binary must execute and report a version
• the exact external commands are named in every error

Measured failure data across clean OS images decides whether it graduates or is replaced by a TLS + inflate dependency. Not taste.

Continuity checking, which is NOT a verified download

Chrome for Testing publishes no checksums – its manifest carries only platform and url – so there is no upstream hash to authenticate against. What is possible is trust-on-first-use: record the SHA-256 of what was downloaded, and compare if the same version is fetched again.

Call it continuity checking or TOFU integrity. Never call it a verified download. It detects a pinned version’s archive CHANGING after first observation. It cannot authenticate the first archive by any means beyond TLS, and no amount of hashing later makes the first fetch trustworthy. This paragraph exists so nobody reading the code in a year upgrades the claim by accident.

What it is genuinely good for: a pinned version is reproducible across a team and CI, and a silent upstream replacement becomes loud.

Archive safety, bounded

Extraction is delegated, so extractor behaviour is part of this crate’s compatibility surface. Tested adversarially on Linux with unzip 6.0 and CPython 3.9 zipfile:

vector	unzip	python3 zipfile
../ traversal	stripped	sanitised
absolute path entry	contained	contained
backslash separators	contained	contained
symlink escape	link created, write through it REFUSED	symlinks not restored, so vector absent

Note the last row: those are different guarantees. unzip defended against an attack it genuinely attempted; CPython never creates the symlink, so the vector does not exist there rather than being blocked.

This does NOT establish safety for every extractor version, platform, or archive construction – nested archives, hard links and other zipfile implementations are untested. It is evidence for the tested matrix, not a universal guarantee.

Functions

install_browser

Download a pinned Chrome for Testing headless shell.

installed_version

What install_browser reported, for printing.

latest_stable_version

The current Stable version, as Chrome for Testing reports it.

managed_root

Where a managed browser is installed.