Security Center

Windows used to greet you with three green shields. Here is the honest version for this site: what actually guards it, and what each layer really does.

Firewall ON

Cloudflare edge. Every request hits Cloudflare's network before it reaches the origin, so the edge filters traffic, terminates TLS, and absorbs DDoS attempts before they get near me. You reached this page through colo … over …, ….

Automatic Updates ON

Deploy-time delivery. Every deploy purges the edge, shared assets carry short revalidating caches, and pages ship origin-fresh, so a return visit picks up changes without a hard reload and there is no second cache to go stale. (A service worker used to do this job; it retired in v136 because the platform now covers it.) See the recent installs in Windows Update.

Threat & identity protection ON

Bot management and Web Bot Auth. Cloudflare scores incoming bots. This site signs its own crawler's outbound requests per RFC 9421 and publishes the key at /.well-known/http-message-signatures-directory, so a site receiving a request can verify it really came from here.

Header & transport details

Content-Security-Policy: default-src 'self'; object-src 'none'; frame-ancestors 'none'; upgrade-insecure-requests, with no external script or connect origin: the browser-facing directives are self-only. Server-side route handlers may still make the outbound calls documented on their own surfaces
script-src: every page built here ships a sha256 of each of its own inline scripts, so the enforced policy names each inline script by hash instead of trusting inline code as a class. 'unsafe-inline' left this directive on 2026-08-16, after riding along in a report-only twin while it proved itself against real browsers. The style directive keeps 'unsafe-inline' and will, because the CSS here is inline by design. So this protects against script injection and makes no claim about style injection
… and what it lets through: hashing inline scripts says nothing about scripts loaded by src from this origin, which 'self' permits. It happened here: from 2026-08-06 the edge injected /.webmcp/bridge.js into every page after this worker was done, so the strictest policy the site could ship still admitted 47KB of code the repository does not contain. That injection is off, and every src this page loads is now a file in the repository. The directive still permits any same-origin script, so removing the script closed the gap and the policy itself never tightened. The next edge feature anybody enables re-opens it silently. This page names the gap because a page about guarantees should say where they stop; details at /whoareyou
One worker, one more token: the AV2 decoder on /garage/av2 runs as a dedicated worker, and that worker script's own response adds 'wasm-unsafe-eval' so it can compile its WebAssembly. A worker enforces the policy of its own script and never the page's, so no document carries the token
Permissions-Policy: camera, microphone, geolocation, USB, Topics + 10 more: all denied
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
DNSSEC: signed (ECDSAP256SHA256, DS at the registrar)
Content Signals: search, ai-input, ai-train: all yes (deliberately open)
This connection: … · …

Read-only, nothing logged or stored. System Properties shows what your specific request revealed.