Launch review — 2026-09-10
Later update: the public endpoint relay.sparrowsystems.co is now deployed through
Wrangler, and public transport/fresh Nitro checks passed while warming. This
supersedes the DNS/Cloudflare-pending items in the earlier snapshot below.
See public deployment evidence, including
the SDK user-agent source fix awaiting package release.
The security and interoperability prototype works in real Nitro diagnostics. The current production image is running, but the service is not ready for a public launch. The remaining work is primarily public deployment, full-duration validation, recovery publication and archive durability. This review includes fresh runtime checks around 07:36–07:39 UTC; earlier test evidence is identified separately. No production enclave was replaced or restarted.
Fresh observations and the S3 correction
- A fresh AWS-signed challenge verified the exact production PCR0 and actual
inner TLS peer binding. Signed policy: source
92bd47508d7ad48442c98148f6b4e09c6169ab5e,state=warming,current_epoch=null, Graviton5 verified, Mullvad up, 43,768,124 iterations per segment, seven segments and an 86,400-second epoch. The raw attestation and peer certificate are in live-warming.json. nitro-cli describe-enclavesindependently reports the existing enclaveproduction-mullvad-92bd475running withFlags=NONE, 12 CPUs and 24 GiB. Parentgraviton5-host.serviceis active. Parent root disk has about 80 GiB free.- Hetzner tunnel, mirror and solver-controller units are active, with zero automatic restarts reported by systemd. The mirror's latest complete scan discovered zero current production artifacts and reported no replica failures. The current parent index also returned an empty list. There are no production solver checkpoints yet; the controller is waiting for its first puzzle.
relay.girl.surgerydoes not resolve from this machine, and the parent has no running dedicated Cloudflare connector. A renewed login is not a deployed route.- GitHub run 34430163444 remains completed/successful at the expected CI revision
a0fad3334b501c610c20dbe27137edaa607c90b3.
S3 upload works, and the archive is now publicly readable. It was private
at the start of this review: all four bucket public-block flags were enabled and
there was no bucket policy. I inspected every object in the intended artifacts/
prefix: only encrypted records, public puzzles, attestation bundles and references
were present, and each content address matched its bytes. I applied
the restricted public policy.
It permits anonymous HTTPS reads and prefix-scoped discovery, with no public write
or delete grant. ACL blocking remains enabled. Account-wide settings were unchanged.
All ten pre-existing objects passed full-byte anonymous SHA256 verification. A
fresh copy of an existing diagnostic ciphertext then passed the actual deployed
mirror adapter under relay-fleet-v2 and its scoped AWS profile: first create,
full readback, idempotent repeat, and rejection of a duplicate conditional write.
That new object also passed anonymous HTTPS readback and its full hash. This
prefix now contains eleven diagnostic objects/copies, not production traffic.
Evidence: before settings, public readback and after settings, actual scoped upload, new upload anonymous readback, and uploader IAM simulation. The simulation allows Get/Put and denies DeleteObject, DeleteObjectVersion and PutObjectRetention. Anonymous root listing, other-prefix listing and a known existing other-prefix object returned 403. No destructive permission tests were run.
The public listing uses S3's XML API. It is not the relay JSON index consumed by the existing follower. Public downloads work independently of the parent, but automatic fleet discovery/failover through S3 still needs an adapter or compatible index. Published objects remain encrypted until someone solves the puzzle; S3 itself does not schedule their decryption.
Major facets
| Facet | Current state | Remaining work / limit |
|---|---|---|
| Product/API | GET-carried inner TLS and upstream HTTPS GET implemented; real Nitro diagnostic forwarding succeeded. | Upstream POST is deliberately deferred. This is not a general browser, cookie jar or arbitrary-header proxy. |
| Client confidentiality | Client verifies fresh Nitro signature/nonce/time, exact PCR0, policy and actual TLS peer binding before supplying the URL. Synthetic attack tests and real Nitro checks passed. | A literal fetch-only entity cannot execute the verifier or TLS protocol. It needs cryptographic execution or a trusted verifier. |
| Trust boundary | AWS/Nitro trusted; account owner and front-end treated as hostile. Secrets and inner TLS terminate inside measured enclave code. | Client verifier/pin, cryptography and upstream WebPKI are additional assumptions; the intended destination necessarily sees plaintext. |
| Running deployment | Nondebug Graviton5 production source 92bd475; 12 enclave CPUs/24 GiB. Fresh attestation verified. |
No active production epoch yet. Working-tree optimization candidates are different source and are not deployed. |
| Mullvad egress | One pinned device, enclave-generated private key, mandatory tunnel and fail-closed checks. Fresh signed status says tunnel up. Real Nitro diagnostic egress and offline record recovery previously passed. | Sustained operation/failover remains to be observed. A second simultaneous enclave using that device can disrupt the first. |
| Forwarding constraints | Public HTTPS443 only; address/redirect checks; five redirects, 30-second upstream timeout, 10 MiB total response capture; no incoming GET body. | Public load and adversarial traffic through Cloudflare have not been tested. |
| Request capture | Canonical CBOR record, XChaCha20-Poly1305 encryption, content-addressed host persistence ACK before response. Diagnostic exact-byte recovery passed. | Host ACK does not prove S3 upload. Host termination before capture can lose an interaction; malicious parent can falsely acknowledge persistence. |
| Public transport | Bounded GET sequencing/retry implementation and Cloudflare deployment/smoke scripts exist. Durable Hetzner→parent SSH transport works. | Public hostname/tunnel/routing/cache behavior are not live. Need actual public attested request plus recovery after readiness. |
| RandomX construction | Seven dependent unlocks; native full/light interoperability, signed manifests and key commitment checks tested. Native race, erasure and page-permission fixes are deployed. | Not a proven VDF or hardware-independent seven-day minimum. New performance changes need their own validation, measurements and release. |
| Work calibration | Current setting is 306,376,868 total dependent hashes per puzzle. Original parallel-generation estimate is 25.14 h. | Estimate exceeds the 24 h epoch; actual full-duration generation is unobserved. Faster implementation/hardware shortens solving too. |
| Epoch lifecycle | Future puzzles private; publish-before-use; expiry rejection and bounded request leases covered by local tests. | Need first production completion and a real daily rollover; late generation will create an availability gap. Restart loses private in-memory generation progress. |
| Minimum disclosure time | Public computation makes recovery possible without an operator release secret. | Delay begins at puzzle publication, not each request. Late-epoch requests get roughly one day less delay; no fixed “exactly a week” promise. |
| S3 archive | Fresh real scoped upload, readback, idempotence and conditional-write rejection passed. Artifact prefix is now public and hash-verified. Versioning enabled. | Current tests use diagnostic ciphertext; no production artifact exists yet. Conditional writes do not prevent an administrator deleting data. |
| Retention/durability | AWS and Hetzner diagnostic copies verified; live mirror runs every minute. Uploader cannot delete. | No Object Lock, no chosen retention duration, no enclave-authenticated S3 acceptance/retention check. The third-provider Cloudflare R2 copy is not deployed. |
| Continuous solving | Nine-worker Hetzner controller and persistent SSH tunnel active; native solver supports checkpoints and key commitment checks. | Waiting for first production puzzle; no full-duration production solve. All workers are on one machine and depend on origin discovery for new work. |
| Public recovered data | Public puzzles and ciphertext can be downloaded and solved independently. | Follower saves .key files locally and logs completion. No deployed publisher uploads verified recovered keys or decrypted records for ordinary public access. |
| Historical provenance | Puzzle signature binds to attested service key. Content hashes and a client-retained authenticated receipt identify original ciphertext. | Individual records lack service signatures. After key publication, AEAD alone cannot distinguish a forged new record; no complete-history proof. |
| Metadata privacy | Inner TLS protects content; WireGuard conceals client-selected upstream connections from parent. | Sizes/timing/client and VPN IPs remain visible. Exact ciphertext lengths can reveal known content; Mullvad/resolver see destination metadata; redirect hostnames can contain response data. |
| Reproducible builds | Two GitHub-hosted ARM builds reproduced production Docker identity and PCR0/1/2; separate signed measurement job. Exact CI revision verification previously passed. | Complete EIF bytes differ in unmeasured metadata. GitHub provenance and reviewed workflow are additional evidence, not proof of benign source. |
| SDK/distribution | Public Python 0.2.0a2 prereleases and native wheels exist; installed-wheel diagnostics/recovery previously passed. | These are alpha releases. New optimized native code is not yet a package/release; current pins and onboarding must stay aligned with the deployed image. |
| Security review | Nine-model panel and subsequent three Astra reviews completed. Confirmed native issues have a fix report and regression evidence in production 92bd475. |
Reviews are bounded evidence, not certification. New ARM JIT changes need regression/review; native side-channel and complete erasure proofs do not exist. |
| Capacity/abuse | 16 concurrent admitted requests, 128 enclave connections and bounded host sessions/queues. Separate solver memory/CPU limits. | No verified public throughput or sustained overload result. Anonymous clients can occupy capacity. Need privacy-preserving load tests and operational alarms. |
| Operations/recovery | Scoped tunnel/service identities, restart policies for parent/fleet, preserved files/checkpoints; parent storage currently ample. | Need tested reboot/relaunch and pin-rotation procedure, mirror lag/solver progress/epoch-expiry/disk/VPN alarms, and replica fallback. No demonstrated highly available service. |
| Documentation/release state | Threat model, native-fix report and current CI evidence are available. Root README and deployment status corrected during this review. | Historical reviews/release documents still refer to their older measured revisions; use exact source/PCR identities and this dated status, not “current” in an old snapshot. |
Before opening
- Complete and observe the production lifecycle. First ready epoch, an actual request, public archive readback, expiry/rollover, and an independent production-work key recovery. Short-work diagnostics are useful but do not substitute for this evidence. Resolve the generation-versus-epoch capacity gap and recalibrate any final optimized implementation on actual generation and sequential solving workloads.
- Deploy and validate public ingress. Revalidate Cloudflare access, deploy the dedicated tunnel/DNS/cache policy, then run public transport and authenticated client smoke tests against the pinned production image.
- Finish public recovery delivery. Publish commitment-verified solver outputs and provide a usable public index/decryption path. Keep archival provenance evidence alongside each record; validate the whole path with a diagnostic first.
- Close the desired durability guarantee. For administrator-resistant retention, select a duration and apply S3 Object Lock compliance retention to ciphertext, puzzles and evidence, preserving version IDs and their public retrieval path. For “response returned implies durably archived,” change the measured enclave to verify authenticated storage/retention acceptance before response release. Add the independent third replica and test retrieval during origin loss. These are separate from making the bucket public.
- Make operation and claims ready for users. Add load/overload and recovery drills, actionable privacy-preserving health alarms, and a single onboarding document with exact source/CI/PCR pins. State approximate publication-relative delay and metadata/recipient limits explicitly.
For a limited experimental opening, some long-duration evidence could still be pending if plainly disclosed, but public routing, an actually ready epoch, working public archive/recovery delivery and basic operations are prerequisites. For the stronger promise that requests remain secret for at least a week and then reliably become publicly readable regardless of operator behavior, the current design does not yet provide that guarantee. A software optimization alone cannot establish a wall-clock secrecy minimum.
Background optimization
The separately requested randomx_optimization agent is continuing bounded ARM
JIT optimization and validation. Its interim paired screening is roughly
570→677 sequential hashes/s on the Graviton parent, about +19%, with matching
hashes. This is candidate evidence, not production-enclave calibration or a
released build. Existing production warm-up was preserved. See
optimization artifacts.
Retention references
AWS documents that Object Lock compliance mode protects specified object versions against account-user deletion until expiry, including root; account deletion remains an exception. New versions or deletion markers can obscure retained versions. Immutability also does not compel an account owner to keep anonymous access enabled, which is why independent copies and prior version/digest evidence matter.