Changing devices can break access to an encrypted advisory document even when the order is still visible. The order identifies the delivery, but the new browser also needs the private reading key. In Fone ProofDesk's inspected browser implementation, that key can be recovered from an encrypted backup using the reading password.
The backup and password have distinct jobs. A password unlocks the saved private key; it does not regenerate a missing key pair. The public key attached to an order enables delivery to the customer, but it cannot supply the private key needed to read the result. A recovery screen should explain those requirements before a customer places an order.
Know what the backup contains
The current browser code generates an RSA-OAEP key pair. It exports the public key for the delivery workflow and encrypts the private key with a password-derived AES-GCM key. The backup is a versioned JSON object containing the public key identifier, salt, initialization vector and encrypted private-key bytes.
The source requires a reading password of at least 12 characters and uses PBKDF2 with SHA-256 and 310,000 iterations. These are inspected implementation choices, not an independent security recommendation or proof that a chosen password is strong. Browser key derivation is supplied through Web Crypto, whose API requires a secure context. MDN deriveKey reference
The app can save that encrypted backup in browser local storage and offer it as a download. Local storage makes returning to the same browser convenient. A downloaded copy provides the material needed when moving to another device or after local browser data disappears. The recovery plan should therefore include the download as a customer action, with clear confirmation that the file has been retained.
| Material | Where it is used | What happens if unavailable |
|---|---|---|
| Encrypted delivery | Retrieved through the original order | There is no document to decrypt |
| Matching key backup | Imported into the new browser | Password cannot recreate the private key |
| Reading password | Unlocks the encrypted private key | Backup remains encrypted |
| Original order context | Authenticates the delivery envelope | A different context must fail verification |
Restore into the original context
During import, the implementation checks the backup version and public key format before attempting to unlock it. It also places a size limit on the serialized backup. The password-derived key decrypts the private key, which is then imported for reading.
The delivery envelope uses a fresh symmetric key for the answer and wraps that key for the customer's public key. Its authenticated context includes the chain, escrow address, order identifier, question hash and question type. The reader supplies that context when decrypting. A copied encrypted payload therefore cannot simply be relabeled as a different order and read under the new context.
After decryption, the reader checks the structured answer against the recorded commitment. This is a separate step from successfully unlocking the private key. A recovery exercise should inspect both outcomes, because opening the backup only establishes that the browser has a usable key.
Make failure states useful
A wrong password should leave the backup unchanged and keep the document unreadable. A backup for a different public key should not silently replace the expected key. A modified encrypted delivery should fail authentication or commitment verification. These cases need distinct support instructions even if the underlying cryptographic API reports a general decryption error.
The application should never ask a customer to paste the reading password or private key into a support conversation. For diagnosis, a proposed support record can include the backup version, a non-secret key identifier, the order identifier and the stage that failed. That record is an extension design for support operations, not a feature verified in this source review.
A complete drill starts in a browser with no saved reading key. Import a retained backup, supply the password and reopen the original delivery. Then repeat with a wrong password and a mismatched backup. Record the observed result without placing secret material in the worksheet. This article has not executed those recovery cases.
The new-device recovery worksheet provides the case list and evidence fields. Fone ProofDesk shows the advisory delivery workflow and its current local demonstration scope. For a project, specify who keeps backups, what recovery guidance customers receive and how delivery deadlines interact with a customer who cannot read the document.
