x70.dev

Experiments

status is honest: live means it runs

Each entry carries a status rather than a date, because the useful question is does it run, not when it was started. live means you can use it on this site right now. wip means it partly exists. planned means nothing is built yet and the entry is a placeholder.

header-audit

live

The README for this site publishes the security policy it is written against, and claims that policy is verified rather than assumed. This checks the claim: it reads the response headers off / and grades them against the documented set, then explains what each one is actually holding shut.

It audits this site and no other, which is a hard limit rather than a missing feature. A browser cannot read response headers from another domain: a no-cors fetch returns an opaque response with nothing on it, and a normal cross-origin fetch exposes only the CORS-safelisted headers unless the far end opts in. Pointing an audit at somebody else’s domain needs a server to do the fetching, which a static bundle does not have.

The Content-Security-Policy is taken apart directive by directive, because a policy can be present and still leave the important parts open. frame-ancestors, base-uri and form-action do not fall back to default-src — so default-src 'none' can look like a complete answer while doing nothing at all about framing, form targets or a rewritten <base>.

source · js/headers.js

Header audit

same-origin · graded against the documented policy

    One request, and it grades what comes back.

    What this shows, and what it doesn’t. Headers are set per response, so this grades / and not every path on the site — a rule that matches the HTML but misses /js/ would still read as a pass here. A present header is also not a working one: this checks that the policy is served and well-formed, not that a browser enforced it against a real attack. required means the header is part of the documented policy; advisory means it is a suggestion this site never committed to.

    edge-cache-probe

    live

    This site sits behind Cloudflare, and every asset is uploaded with a deliberate Cache-Control header. The probe below checks whether the edge actually honours them, by requesting six of this site’s own files twice each and reading the cf-cache-status header off every response.

    Two passes rather than one, because a single request cannot tell the difference between an asset the edge declines to cache and one it simply has not seen yet. Both come back MISS-shaped the first time; only the second pass separates them.

    It works because everything here is same-origin. A cross-origin response hides every header except the CORS-safelisted ones, and cf-cache-status is not among them — which is why this probe can only be pointed at the site serving it.

    source · js/edge.js

    Cache probe

    same-origin · two passes

    path cache-control pass 1 pass 2 ms
    Twelve requests to this site, about 300 KB in total.

    What this shows, and what it doesn’t. It reports the cache that answered your request, at one Cloudflare colo, at one moment. A HIT here says nothing about the colo nearest someone else, and an asset that misses at a quiet edge may sit warm at a busy one. The browser cache is stepped over deliberately — every probe is sent with cache: 'no-store', or the request would never reach Cloudflare and the numbers would be measuring nothing. /main.wasm is requested as a one-byte range, since cache eligibility does not depend on the range and pulling 2.4 MB twice would cost more than the answer is worth.

    go-wasm-bench

    live

    A Go program compiled to WebAssembly and a hand-written JavaScript implementation run the same workload: hash a 64-byte block with SHA-256, then feed each digest back in as the next input, 250,000 times. Chaining is deliberate — it stops either engine from hoisting the work out of the loop.

    Both sides return their final digest. If the digests match, the two engines provably did identical work, which is what makes the timing comparable at all. Both also get a short warm-up pass, so neither is measured cold against a warmed rival.

    The result is often not what people expect. A JIT-warmed JavaScript engine is extremely good at 32-bit integer arithmetic, which is essentially all SHA-256 is. Run it yourself on the index page.

    source · cmd/wasm/main.go · js/sha256.js