What VitalSend will not do.

Clause 1 — No memory

VitalSend will not remember what was sent.

• File contents are encrypted in the sender's browser before upload. VitalSend stores only encrypted bytes.
• The decryption key never reaches the server. It lives in the URL fragment, which browsers never send.
• Account identity is not connected to transfer activity. What you send cannot be traced back to your account.

Clause 2 — No recovery

Once a transfer is gone, it is gone.

• After one successful download, the file is destroyed automatically.
• After expiry, the file is destroyed automatically.
• There is no archive. There is no backup of customer file content.
• VitalSend support cannot resend, restore, or reconstruct a transfer. The infrastructure does not allow it.

Clause 3 — No tracking

VitalSend will not build a record of who sent what.

• Recipients are anonymous. No login. No identity attached to the download.
• Senders may optionally hold an account for prepaid credits. The account does not see, link, or list their transfers.
• Operational logs are minimal and retained only for security and abuse handling. They are not a transfer history.

Clause 4 — No reuse

A link is not a folder.

• A transfer link works exactly once. Resending the link does not reopen access.
• There are no shared folders. There is no collaboration space.
• There is no link rotation that turns a one-time link into a persistent one.

Clause 5 — No exceptions

There is no key under the mat.

• VitalSend cannot read uploaded file contents. Not for support, not for moderation, not for compliance.
• VitalSend cannot decrypt a transfer on request. The decryption key never reached the server.
• Lawful requests for file contents can only return what VitalSend has — encrypted blobs without their key.

The client-side encryption code is public so the model can be independently verified.