10 Security · This Site
Verify this website from your own terminal.
A security page you have to take on faith is a contradiction. Every claim below comes with the command that checks it — run them against the page you are reading.
01Zero third-party — grep it yourself
Grep this page for an origin we do not own.
Zero third-party anything. No trackers, no CDNs, no cookies, no analytics — every byte arrives from QERYX-controlled origins. The interactive crypto instruments run self-hosted, readable, first-party scripts on your device.
curl -sI https://qeryx.com | grep -i set-cookie
# no output = no cookies, evercurl -s https://qeryx.com | grep -oE 'https?://[a-zA-Z0-9./_-]+' | grep -v qeryx
# the only non-qeryx origin anywhere is quantumentanglement.io — also oursThe one cross-origin request the whole site can make is the user-initiated Bell-beacon fetch on the Q-Entangle-Bell instrument, to quantumentanglement.io — a QERYX property.
02Transport — TLS 1.3, X25519MLKEM768 first
Handshake with us. Demand the hybrid group.
The repo Caddyfile pins TLS 1.3 only, AES-256-GCM and ChaCha20-Poly1305 suites, and puts the X25519MLKEM768 hybrid group first in the curve list. Neither badge below turns on until the command beside it passes against the live site — your handshake is the proof, not our badge.
openssl s_client -connect qeryx.com:443 -tls1_2 </dev/null
# must FAIL — a TLS 1.2 handshake is refused.
# This badge appears the day this command passes against the live site.openssl s_client -connect qeryx.com:443 -groups X25519MLKEM768 </dev/null 2>/dev/null \
| grep -i 'negotiated'
# requires OpenSSL >= 3.5; the group negotiating is the claim.
# This badge appears the day this command passes against the live site.The day these commands pass, the badges flip. If a live badge ever claims what a command refutes, we want the report: security@qeryx.com.
03Headers — the whole contract, published
Read the header contract in full.
curl -sI https://qeryx.comThe configured contract, line by line
The configuration this site ships commits to: Strict-Transport-Security with preload · a default-src 'none' CSP baseline (instrument routes earn first-party script-src only) · X-Content-Type-Options nosniff · X-Frame-Options DENY · Referrer-Policy no-referrer · COOP/COEP/CORP cross-origin isolation · a Permissions-Policy that switches every sensor off · no Server header, no Via header. Until the production deploy lands, this is the contract in the repo — the curl above is how you hold the live site to it.
What the logs keep
Access logs are written with remote IP, remote port, and User-Agent deleted by the log filter before the line is stored. The filter is configuration, not policy prose — it ships in the same file as the header set.
04Not yet true — four gates still open
Not yet true. Listed anyway.
These posture items are absent because their gates have not closed. Each badge appears the day its command passes — one by one, never as a set on faith.
Not yet enabled at the registrar. When the DS record exists,
dig +dnssec qeryx.com proves it and the badge appears.
Not yet provisioned. When it is, the Onion-Location header names it and the footer carries the address.
The preload token already ships in the header; directory submission follows 90 clean days of serving it. We claim the listing only when the directory shows it.
Reissue ceremony pending — semantics documented at /security/disclosure.
05The record — the questions we get asked hardest
The hard questions.
Why does a marketing site need this posture at all?
Because this site is the first QERYX surface most people touch, and a vendor whose own website leaks trackers while preaching zero-knowledge has already answered the trust question. The site is the smallest demonstration of the same architecture: hold nothing, prove everything.
Why publish the absences?
A posture page that lists only its passes is an advertisement. The absent badges name their gates, so you can watch them close — and hold us to the ones that stay open too long.