This Is Why We Built This Service

VitalSend is built around a single, uncompromising rule:

A file should be accessible exactly once.
After that, it should no longer exist.

No archive.
No backups.
No recovery.
No “just in case”.
No logs.
No traces.

That rule makes VitalSend unsuitable for everyday file sharing. That is intentional.

This service exists for rare situations where persistence itself is the risk, where the cost of a mistake is higher than the cost of inconvenience.
Everything else in the system follows from that decision.

You can think of VitalSend less like email, and more like a dead drop: something is placed once, retrieved once, and then nothing is left to find.

Why we didn’t just use email

We are often asked:
“Why not just send it by email?”

Email works well for communication. It is a poor model for containment. It is not designed for containment or privacy.

In many organizations, email is not private correspondence. Corporate mail systems may be monitored, logged, indexed, or accessed by the organization itself: for compliance, security, or legal reasons. Or simply by management as a routine business decision.

In public-sector and government environments, email can, in many jurisdictions, become part of the public record, regardless of sender intent. Deleting a message afterwards does not undo that.

Once an email is sent, it is immediately and irreversibly copied:

• across multiple mail servers
• into inboxes, backups, archives, and logs
• outside your control the moment it leaves your outbox

Even if the attachment is encrypted, the transaction leaves traces:

• sender and recipient addresses
• timestamps
• metadata
• server and client backups

A typo in an email address is permanent.
A forwarded message cannot be recalled.
An attachment can live on for years.

Email is designed for delivery, not disappearance.
If a file must not linger, email is the wrong model.

“But what about secure email?”

Another common response is:

“Why not Proton Mail or similar secure email services?”

These services improve security within their own infrastructure. Email is only end-to-end encrypted as long as it stays inside the same private system.
The moment a message is sent to:

• Gmail
• a corporate mail server
• any external provider
  …it leaves that encrypted environment.

At that point:

• the message is decrypted for delivery
• it passes through external servers
• it is stored, logged, and backed up outside your control
  This is not a flaw in those services.
  It is a property of how email works.

Email is a federated, store-and-forward protocol designed decades ago. Persistence is the default. Security is not.
Even when the sender uses a secure email provider, the recipient’s infrastructure determines the real exposure.

Why file-sharing and cloud storage don’t solve this either

We are also asked:

“I just send files via Dropbox / Drive / a shared link — works fine.”

Those tools are built for collaboration.

They assume:

• files should remain available
• links should be reusable
• access should be flexible
• history and logs are features
• backups are needed

That breaks down in high-risk situations.

Common failure modes:

• links are forwarded
• files are forgotten in shared folders
• access is revoked too late
• copies exist in caches, sync folders, and backups

Even with passwords and revoke buttons, the damage happens before you have a chance to react.

These tools assume mistakes are acceptable and recoverable. Sometimes they are not.

The real problem: persistence

Most modern tools are already “secure” in the traditional sense.

The real risk often comes later:

• files that still exist
• links that still work
• data that resurfaces at the wrong time

We didn’t want better control.

We wanted an end.

What VitalSend does differently

From the one-time-access rule, everything else follows:

• Files are encrypted on your device before upload
• Exactly one download is possible
• Any deviation destroys the file
• No download after a short timeout triggers automatic destruction
• No archives
• No backups
• No logs
• No traces

This makes VitalSend impractical for normal file sharing.
That is the point.

When this makes sense

VitalSend is for situations where:

• a leaked link would be a real incident
• you do not want files living on in inboxes or folders
• convenience is less important than finality
• the system should prevent mistakes, not help you recover from them

If you don’t need this, you shouldn’t use it. But when you do need it, you will remember why it exists.

Note on acceptable use

VitalSend may not be used to transmit illegal material or for illegal purposes of any kind.