Jason Page submits Seal, an inheritance app that publishes its own weak spots

Jason Page, a University of Oregon computer science student, has submitted Seal to Apple's App Store, turning a solo software project into a test of whether radical transparency can earn trust for an app designed to hold a family's most sensitive instructions. Page's source code is public.

Seal lets an owner prepare separate encrypted envelopes for particular recipients. Each envelope can contain a letter, passwords, photos, audio, video, files and instructions. The owner appoints trusted key holders and sets a rule governing release after a prolonged absence.

Under Seal's default release sequence, two of three key holders must act after 90 days without an owner check-in. Seal then sends 21 days of warnings and waits through a 14-day quiet period. A single tap by the owner cancels the process. Different envelopes can use different rules, allowing urgent medical instructions to open sooner than other material.

Seal remains available as a free TestFlight beta while Apple reviews the submission. Page plans to charge once, without a subscription, although Seal has not published the price.

Page is building Seal alone in Portland, Oregon. His GitHub profile identifies him as a University of Oregon computer science student, while his App Store catalog includes the on-device word game Wick, recipe app MakMak, habit-blocking app Pawl and several small games. Seal is a larger security bet than those consumer projects: failure could expose private credentials, block a family from recovering them or release material while its owner is still alive.

A vault without a Seal server

Seal's published design stores encrypted envelopes and public records in Apple's CloudKit infrastructure, but Page says Seal operates no backend of its own. Content is encrypted on the owner's device, and the keys needed to release it remain tied to participating devices.

Each recipient gets a separate encrypted key table. The estate key is divided among trusted key holders using Shamir secret sharing, and a recipient still needs the key bound to their own device after the required shares are combined. That structure is designed to prevent the people authorizing a release from reading envelopes addressed to somebody else.

For cryptography, Seal uses AES-256-GCM for content encryption, device keys held in Apple's Secure Enclave, WebAuthn credentials for identity and X25519 for key wrapping. Devices running iOS 26 can add ML-KEM-768, a post-quantum key encapsulation mechanism, while older supported devices use X25519 alone. Seal requires iOS 18 or later and has no Android version.

The product addresses a gap left by platform-level inheritance features. Apple's Legacy Contact system can give a designated person access to photos, messages, notes, files and backups after the account holder dies. Apple explicitly excludes iCloud Keychain data, including passwords and passkeys. Seal is designed for the private instructions and credentials that fall outside that system.

The design requires participants to exchange identity information in person. Each phone pins the public key presented during that meeting and rejects later substitutions. The choice adds friction, though it avoids relying on email addresses, phone numbers or support agents to establish who should hold a share.

Claude wrote code and reviewed it

The App Store submission commit is co-authored by Claude Fable 5.1, an Anthropic coding agent. Seal's own documentation says the same assistant wrote much of the code and performed the only pre-release design review.

That review found two flaws. One could have allowed a key holder to backdate a claim and skip the warning period. Another could have let one recipient read newly sealed envelopes early after an earlier release. Page says both were fixed in the submitted build.

An AI agent reviewing code that it helped produce does not amount to independent scrutiny, a distinction Page states repeatedly. Seal's published limits say it has no outside cryptographic audit, no reproducible build process and limited testing of physical security keys. One documented security test suite is not registered to run, while most other tests execute inside debug builds watched by Page.

The project also has no cryptographic time lock. The countdown is a signed record that compliant Seal clients follow. The required key holders and the intended recipient could use modified software to combine their material and open an envelope early. Seal's design makes that collusion harder and visible in its threat model, but does not make it impossible.

Seal's technical documentation says CloudKit exposes metadata. An observer can see public identities, release rules, event times, key-holder account identifiers, the number and approximate size of envelopes, and unencrypted reasons entered for claims or objections. Letters, passwords, media and recipient identities remain encrypted, according to the published design.

The documentation is part of the product

Page has turned those limitations into an unusually direct public warning label. The page lists the missing audit, lightly tested security-key support, public metadata, lack of reproducible builds and the risk posed by a stolen unlocked phone. It advises hardware-wallet owners to keep live seed phrases out of Seal until an independent audit has been completed.

That candor is also a practical distribution strategy. Seal's limits page says the project is built by one developer, with no company, team or funding, and that nobody outside the project has audited it. Its GitHub repository had one star and no forks on September 19th. Page cannot borrow credibility from a security firm, established password manager or venture backer, so the source code, threat model and written admissions have to carry the argument.

The repository uses the Mozilla Public License 2.0, allowing outsiders to inspect and fork the code while requiring modifications to Seal's own files to remain public. Page has also published a standalone Python verifier that checks signatures and timestamp records in an exported estate capsule without contacting Seal.

Independent review remains the decisive missing layer. Page is accepting donations toward a professional audit and says any eventual report will be published in the repository. Until then, Seal is better suited to instructions that help a family locate and interpret existing backups than to serving as the only copy of a bank password or cryptocurrency seed phrase.

Seal's strongest feature at submission is Page's refusal to disguise that boundary. He has shipped the beta, opened the code and documented the ways it can fail before asking families to place irreplaceable material inside it. Apple approval would make Seal easier to install. Trust will depend on what security reviewers find after they take Page up on the invitation to inspect it.