Security claims need an adversary, an environment and evidence. Our current results establish bounded software behavior. Protected-device enforcement and independent review remain open.
The alpha tests recognised possession, section access, transfer and selected recovery paths. It runs in an ordinary software environment with simulated access nodes and endpoints.
The host operating system can inspect secrets and plaintext. An attacker controlling that host can cross the boundary that a future protected device would need to enforce. No security certification or completed independent cryptographic audit is claimed.
After freeze, the prototype denies new seller authorizations and retained, unconsumed capability use. If an authorization receipt commits before freeze, that delivery may finish afterward. The software cannot recall plaintext already disclosed, and it does not demonstrate ongoing protected display clearing.
Inspect the freeze-order evidenceThe assets include owner authority, access secrets, content confidentiality and current-state integrity. The following adversaries and failures shape our acceptance gates.
The present process or operating system can read keys and plaintext. Ordinary browser code and hardware-backed key generation do not establish protected rendering.
Required evidence: a complete attested, non-exporting processing and display path on a named device and build.
Sufficient colluding share holders can decrypt retained old ciphertext. Threshold access is not protection from a malicious quorum with the required material.
Required evidence: a reviewed custody model, independent deployment, key lifecycle and explicit quorum-compromise assumptions.
An untrusted state source can lie. A valid signature or inclusion calculation alone does not establish a fresh, authoritative ownership state.
Required evidence: authenticated observations, challenge binding, freshness policy and refusal when required evidence is missing.
Old requests, capabilities and device state can be retained. Local hash chaining does not prevent coordinated rollback of both records and their stored head.
Required evidence: nonrollbackable state inside the protected boundary, plus replay and restart tests.
Transactions may conflict, observations may reorganise, and a process can stop between steps. Bounded private-node recovery is not production durability.
Required evidence: canonical-state reconciliation, uncertain-access quarantine and reproducible fail-closed recovery.
Device replacement and owner-key recovery are different. In the current profile, losing the sole owner signing key is unrecoverable.
Required evidence: reviewed recovery that preserves one recognised possession without creating a hidden bypass authority.
A future device claim needs measured attestation, boot and patch state, trusted freshness, non-exporting key use, decryption and rendering within the selected boundary.
Reboot, app backgrounding, partitions, expired display leases, lost devices, clipboard and screen-capture behavior all need testing. External photographs and transcription remain outside a promise to recall information.
View the gate and dependenciesThe proposed hardware test gives the evaluator control of the ordinary OS. Protected keys and content plaintext must remain outside that host’s reach, while the endpoint permits only the approved display or computation.
Only the authorised unit and a strictly bounded protected working set should exist. A book is not fully decrypted into any reader buffer. Reflowable pages and codec dependency windows need explicit authenticated unit/range limits.
Test caches, dumps, parsers, graphics surfaces, accessibility paths, zeroization and output accumulation, not just the application’s main buffer.
The planned composition requires eligible remote participation and an independent protected-device factor. Provider competition must preserve eligibility and trust separation.
The current alpha’s malicious threshold quorum can decrypt retained ciphertext. A stronger device-indispensability claim requires a separately reviewed construction and coalition tests.
A minimal hardware trust anchor may resist ordinary software overwrite, while authenticated firmware and recovery still evolve. Anti-rollback rules must cover firmware, possession state and access state separately.
Test unauthorized flash, debug/lifecycle changes, power interruption, fault conditions and rollback; do not equate immutability with invulnerability.
Key use, decryption, parsing, computation and display must stay inside the declared protected path. A permitted computation needs a cumulative output policy, or repeated queries can become an export API.
The complete path needs vendor-supported hardware/API access. A secure element or screenshot-blocking flag alone is insufficient.
This website build includes no analytics, advertising, third-party fonts, account system or contact form. The interactive illustration uses synthetic state in memory and does not store it or send it to a service.
The static site contains no signing functionality, product credentials, committee shares, private-node endpoints or reader decryption. The hosting provider may process request information such as IP addresses under its own logging and privacy controls. That is separate from this site’s browser behavior.
The eventual product needs a separate privacy model for linkable ownership histories, access metadata and recovery information.
No public bug-bounty program or guaranteed response window is currently offered. Do not send credentials, private content or exploitable secrets through an unverified channel.
The site is designed with semantic headings, visible focus, responsive layouts and reduced-motion support. The lifecycle also appears as plain text. The explanatory content remains available without running the interactive illustration.
