English · Português
gentropic.org / security
Tools that ask nothing of the machine they run on
The GCU builds small, single-file tools that need no installer, no network, and no special permission to run — and that let you verify each of those claims for yourself rather than take them on trust. They are free and open-source, and they hold up where most software cannot go, for reasons you can check. This page describes what the tools do, what they ask of a host, and exactly how to confirm every claim.
This page is held to the same standard as the tools it describes. It is a single static document with no scripts, no network requests, and no third-party fonts or content-delivery networks — everything it loads is served from this one origin. If that is a claim worth checking, its source is already open to you under View Source.
Verify it yourself — five minutes
You do not have to take any of the following on faith. Each property claimed on this page corresponds to something you can confirm directly, in a few minutes, using tools you already have on the machine.
- Download
lamina.htmlfrom the pinned release below. - Hash it — shasum -a 256 lamina.html — it matches the published SHA-256 and the Zenodo DOI.
- Open it. DevTools → Network → load a file → zero requests.
- View Source — it is readable; here is the repository it is built from.
- Disconnect the network entirely. It still works.
- Export something — it writes only the one file you choose, through the operating-system Save dialog. Nothing silent; nowhere you did not pick.
What a locked-down host controls — and what survives
Serious environments stopped policing computation (the browser is the most capable runtime on any managed machine, and can't be stripped without breaking the web apps the org runs on) and police reach. Here is exactly what each control blocks, and the hardened-profile answer:
| Host control | Blocks | Hardened profile |
|---|---|---|
unsafe-eval (CSP) | eval / new Function | Zero runtime codegen — closure backend, never eval |
wasm-unsafe-eval | WASM compile | Stripped (or admin-toggle) |
remote import() | remote code | Bundled / local imports only |
| Trusted Types | Function construction | Same — no codegen |
| secure origin | crypto.subtle, workers, storage | Served from an intranet HTTPS / loopback origin |
connect-src 'none' | network egress | Reach-zero by design — the air-gap is the feature |
Profiles
Each tool declares the strictest profile it meets. The profile is set by the two axes a reviewer weighs first — whether the tool generates code at runtime, and whether it reaches the network:
| Profile | Runtime codegen | Network / reach |
|---|---|---|
| Sealed | None | None — survives the strictest CSP and Trusted Types; air-gapped, and demonstrably so (disconnect and run) |
| Connected | None | A declared set of endpoints — codegen-free, but not air-gapped |
| Full | uses eval / Function | The full-power build, for environments that permit runtime codegen |
Two capabilities are declared orthogonally, as flags on the profile, because they change neither the codegen nor the network story:
| +WASM | Uses WebAssembly (needs wasm-unsafe-eval) for heavy computation. |
|---|---|
| +GPU | Uses WebGL / WebGPU. Not governed by CSP — shaders are compiled by the GPU driver, not by eval, so this does not break a Sealed profile. May be disabled by browser policy, and adds GPU-process attack surface (mitigated by the browser's GPU sandbox). |
A served secure origin (an intranet HTTPS site, or a loopback server) is required only by
tools that use service workers for offline caching, or that rely on
crypto.subtle for self-hash-verification — both of which are unreliable
from a file:// origin. Everything else, a Sealed +GPU tool included, runs as a single
file opened off disk. (A file:// page is a secure context; its opaque origin,
not the secure-context gate, is what limits those two features.)
How each guarantee is established
Not every property on this page is backed the same way, and the difference is the point. Each claim is established in one of these ways — strongest first — and a tool's declaration marks which:
| Host-enforced | The browser's own policy makes it impossible, not merely absent — "no codegen" under a script-src without unsafe-eval; "no network" under connect-src 'none'. A flawed build cannot violate a host-enforced limit. This is the strongest kind, and it is genuinely available here. |
|---|---|
| Demonstrable | You can observe it directly — disconnect the network and the tool still works. |
| Inspectable | You can read it in the source, and the published hash confirms the source is what runs — for instance, "reads only files you open." |
| Best-effort | Intended and believed, but neither host-enforced nor directly testable. Where a property rests only on this, the declaration says so plainly. |
lamina — capability declaration
lamina is the first tool we publish, and a sensible one to evaluate first: it meets the strictest profile, Sealed. It opens a file — even a multi-gigabyte one — and lets you scroll, filter, and export it: windowed and read-only over the source, and running entirely offline. Its capability declaration is set out below, and the machine-readable forms your own tooling can ingest are linked here — capability.json, csp.txt, and sbom.json.
| Profile | Sealed — no runtime codegen, no network, no WASM, no GPU |
|---|---|
| Executes | runtime codegen No (no eval / new Function) · wasm No · remote import No |
| Reach | network None (connect-src 'none') · telemetry None |
| Filesystem | reads — user-opened files only (picker / drag-drop) · writes — user-initiated export only, to a path you choose in the OS Save dialog · silent or arbitrary I/O None |
| Host needs | secure origin Yes · admin No · install No |
Is this the reviewed thing, unchanged?
Integrity rests on a single, checkable chain from source to running file: an organisation-owned repository with full history, a signed and tagged release, the SHA-256 of the built artifact, and a Zenodo DOI that freezes that exact version as a citable, CERN-hosted record. Taken together, they let you establish that the file you reviewed, the file that is running, and the file bearing this hash are one and the same.
| Release | <tag — build-emitted> |
|---|---|
| SHA-256 | <hash — build-emitted> |
| Zenodo DOI | <doi — on first frozen release> |
| Source | github.com/gentropic/auditable (ext/lamina + tools/lamina) |
The two questions a reviewer asks
Once you stop trusting file extensions as a proxy for capability, two coherent governance models remain — and a GCU artifact pre-answers both, by construction:
| Govern the boundary | assume arbitrary compute, control reach → air-gapped, connect-src 'none', reach voluntarily zero — and demonstrable: pull the cable. |
|---|---|
| Govern provenance | identity + integrity → hash-pinned, frozen, CC0-auditable — "is this the reviewed thing, unchanged." |
Files for your tooling
- capability.json — machine-readable capability declaration
- csp.txt — the exact CSP the artifact is built to run under
- sbom.json — CycloneDX SBOM (zero runtime dependencies, stated in your scanner's format)
- .well-known/security.txt — RFC 9116 contact + policy
Reviewer FAQ
- Does it phone home?
- No.
connect-src 'none'; zero network requests; pull the cable and verify. - Does it need admin, or an installer?
- No. It is a web document opened in your managed browser, under your CSP.
- Can it read arbitrary files?
- No. Only files you explicitly open; it cannot browse the disk.
- Telemetry / analytics?
- None. There is no network path for it to leave by.
- How are updates and CVEs handled?
- You pin a named release. You update when you choose, by pinning a new one. Zero runtime dependencies means a near-empty CVE surface.
- Can we host our own copy?
- Yes — that is the intended deployment. You hold a pinned copy; we operate nothing; uninstall = delete the file.
- What if the author disappears?
- Nothing breaks. It is public OSS (CC0 / MIT); your copy has no operator and no dependency on us being around.
What this is not
It is not "certified safe." We do not sell a safety badge, and a flat assurance of safety is not something a credible assessment produces — only a scoped set of findings against a defined scope. The decision to accept the residual risk belongs to your organisation, not to us and not to any report we might commission. What we can offer is everything you need to make that decision well.
It is not installed software in a costume. However an artifact is packaged — as a bare file, a shortcut, or an installer — what ultimately runs is HTML in your managed browser, under your content-security policy. Packaging changes how the tool is discovered and inventoried; it does not change what executes, or where.
It is not a support contract, and its authorship is disclosed rather than hidden. The tools are public open-source software: you run your own pinned copy, with no operator and no ongoing dependency on us. Where the person proposing a deployment is also an employee of the organisation, that is a conflict of interest to state plainly — and a reason the deploying organisation, rather than the author, should own the decision.
Using a GCU tool where you work
If you found this page because you would like to use one of these tools at your organisation, the most useful thing you can do is also the most boring one: take it through your normal approval path rather than running it unannounced. Running good software off the books still leaves unreviewed software on a managed system — and it puts you, rather than the tool, in the awkward position when someone asks what it is and who allowed it.
This page exists to make that approval straightforward. Point whoever signs off — your IT or security team — to it; hand them the capability declaration and the other artifacts above; and frame it as what it is: one well-scoped, verifiable tool taken through the proper process. The precedent that sets — a reviewable category your organisation has seen and accepted — is as much the point as the tool itself.