If a dashboard casually shows plaintext filenames or note bodies, users will naturally assume the service operator can see them too. That is why DMS defaults to placeholders like “Encrypted file” and “Encrypted message” until the browser locally unlocks the vault.
The server stores encrypted vault materials while the user's browser handles the session-based reveal of filenames, messages, and files after a local unlock. An optional secondary unlock code can add one more local hurdle before reveal.
Admin tools stop at status, counts, dates, reminder state, payment state, and release workflow visibility. No plaintext vault contents appear there.
Users still need to choose trustworthy trusted contacts and verifiers, keep recovery instructions safe, review the recovery pack, and test the full workflow before relying on it.
“We process the operational data needed to run reminders, verification, and release. We do not read the encrypted contents of your private vault in ordinary use.”
Users can review recent delivery failures so broken beneficiary, legal-contact, or verifier email paths can be corrected before a real release depends on them.
DMS uses strong authenticated encryption for vault contents together with a clear separation between encrypted payloads and service metadata. Encrypted owner backup exports add an offline recovery path without exposing plaintext vault contents.
DMS explains what is encrypted, what is not, what the service depends on, what the recovery pack proves, how printable legal packets are prepared, and what risks remain, without pretending any system can guarantee every outcome.