A browser-native protocol for private file delivery

Modern file-transfer platforms have made exchanging large files remarkably simple. Services such as WeTransfer, Dropbox Transfer, Smash, and similar platforms allow users to upload a file, generate a temporary link, and share it within seconds. Their success stems from reducing friction rather than introducing new cryptographic models. Storage, identity, authorization, billing, analytics, and lifecycle management are consolidated into a single platform that coordinates every stage of the transfer.

This architecture has proven commercially successful but it also concentrates trust. The transfer provider becomes responsible not only for delivering encrypted data, but for managing encryption keys, storing metadata, enforcing authorization, retaining user information, processing payments, and determining when transferred content is ultimately removed. As platforms evolve, the amount of trust placed in the provider increases alongside the number of services it offers.

Sharebox explores a different architecture. Instead of asking how centralised transfer platforms can become incrementally more secure, it asks a simpler question:

| What is the minimum amount of trust required for a third party to coordinate secure| file delivery?

Sharebox answers this by moving encryption to the browser, separating encryption keys from stored objects, minimizing retained metadata, and treating the transfer provider as a coordination layer rather than the primary custodian of user data. Files are encrypted before upload, storage receives only ciphertext, recipients decrypt locally, and commercial systems operate independently from transferred content.

The objective is not to eliminate trust. The objective is to reduce it.

Temporary file transfer has become critical internet infrastructure. Every day users share confidential material through cloud-based transfer platforms.

Although these services differ in appearance and pricing, they are all built upon the same architectural principle: a trusted intermediary coordinates the complete lifecycle of the transfer.

The workflow appears straightforward. A sender uploads one or more files, the platform stores them, generates a temporary download link, and delivers the transfer to its intended recipients. The recipient later retrieves the file through the same provider.

From the user’s perspective this interaction is nearly effortless but behind the interface the platform becomes responsible for everything else.

Each additional feature increases the responsibilities assumed by the provider. Password recovery requires identity management. Temporary downloads require authorization systems. Expiration requires lifecycle management. Subscription billing requires customer records. Analytics require behavioral events. Customer support requires privileged administrative tooling.

The transfer platform therefore evolves from a transport mechanism into the central authority governing every aspect of the exchange.

This concentration of responsibility can be expressed as a trust surface.

where

• •$T_s$ represents trust in storage,
• •$T_k$ trust in key management,
• •$T_i$ trust in identity systems,
• •$T_m$ trust in metadata handling.

Traditional file-transfer platforms attempt to secure each component independently. Sharebox instead attempts to reduce the total trust surface itself.

This distinction forms the foundation of the protocol.

The centralised model is not inherently insecure. Millions of transfers occur successfully every day using existing platforms. The question is not whether these systems function. The question is whether the provider requires access to more information than is necessary to coordinate delivery.

The first limitation concerns encryption. Most providers encrypt data during transport and while stored in cloud infrastructure. These protections are valuable, but they do not necessarily prevent the provider from accessing plaintext or controlling the keys used to decrypt stored files. Encryption algorithms remain strong; the trust model remains centralized.

The second limitation concerns metadata. Even when document contents remain confidential, filenames, MIME types, transfer timestamps, recipient identities, object sizes, and download history frequently remain visible to the platform. In many cases, this surrounding information reveals almost as much as the transferred document itself.

Authorization presents a similar challenge. Most transfer services ultimately rely on possession of a download link, optionally strengthened through passwords or email verification. While practical, this approach extends the trust boundary beyond the transfer platform itself. Every email provider, messaging application, clipboard manager, browser history entry, and forwarded message potentially becomes part of the security model.

Commercial architecture also influences technical design. Subscription-based platforms naturally encourage persistent accounts, long-term storage, collaboration features, administrative tooling, and continuous engagement. Over time, temporary file delivery becomes one component within a broader cloud ecosystem.

None of these characteristics represent implementation flaws. They are consequences of the architecture itself.

The objective of Sharebox is not to criticize existing platforms. It is to explore whether the same user experience can be achieved while reducing the amount of trust concentrated within the provider.

The limitations of the conventional transfer model do not arise from weak cryptography or unreliable infrastructure. They arise because the platform performs more functions than are strictly required to deliver a file. Sharebox therefore begins by redefining the role of the transfer provider itself.

Instead of acting as the trusted custodian of transferred information, the provider becomes a coordination layer responsible for authentication, transfer state, recipient authorization, and lifecycle management. Confidential information remains at the endpoints.

The resulting architecture separates responsibility into four independent layers.

This separation changes the provider’s responsibilities. Rather than protecting plaintext information, the platform coordinates encrypted objects that it cannot directly interpret. Cloud storage stores encrypted files, while recipient devices perform decryption after successful authorization.

The objective can therefore be expressed as reducing the provider’s knowledge rather than increasing its responsibility.

The platform still performs essential operational tasks, but these tasks no longer require persistent access to transferred content.

Every transfer begins inside the sender’s browser. Before any network request is made, Sharebox generates an independent symmetric encryption key for each uploaded file.

For file $P_i$,

where $K_i$ is a cryptographically secure 256-bit key generated using the browser’s Web Crypto API. The plaintext is encrypted locally using AES-256-GCM.

where only the encrypted object $C_i$ is uploaded.

This changes the upload pipeline fundamentally. Traditional platforms receive plaintext before encryption or maintain the ability to decrypt stored objects. Sharebox treats encryption as a prerequisite for upload rather than a property of storage.

To prevent key reuse across an entire transfer, every file receives its own encryption key. Compromising one encrypted object therefore provides no information about any other object within the same transfer.

Encrypting files alone is insufficient if encryption keys are stored alongside encrypted objects. The confidentiality of the system depends equally on how keys are protected after encryption.

Sharebox separates file keys from storage through a transfer secret. A random transfer secret $S$ is generated for every transfer. Rather than storing $K_i$ directly, a wrapping key is derived.

the file key is then encrypted.

the platform stores only $W_i$, $\mathit{salt}$, $\mathit{IV}$ while the original file key is discarded from memory after encryption. Cloud storage therefore contains encrypted objects. The application database contains wrapped keys. Neither component independently possesses sufficient information to reconstruct the original file.

Separating encrypted content from key material significantly reduces the impact of storage-layer compromise. Access to encrypted objects alone does not reveal plaintext, while access to wrapped keys alone does not reveal reusable encryption keys.

The protocol deliberately separates content, keys, and storage into independent trust domains. Rather than relying on a single system to protect every component, Sharebox distributes responsibility so that compromising one layer does not automatically compromise the transfer itself.

Encryption protects information only if the correct recipient can recover the correct keys. For this reason, Sharebox treats identity, authorization and decryption as independent stages rather than a single authentication event.

Most file-transfer platforms authorize access through possession of a download link. Additional controls such as email verification or passwords may strengthen this model, but the transfer ultimately remains dependent upon a bearer URL. Anyone obtaining that URL becomes part of the trust boundary.

Sharebox instead separates authorisation from decryption.

Recipients first prove they are authorized to access a transfer. Only after successful verification can they recover the encrypted material required to decrypt the files.

The authorization process can be expressed as:

where each component is optional depending on the sender’s chosen security policy.

Authorization alone is insufficient to decrypt the transfer. For Sharebox users, every account generates a public-private key pair during onboarding. The public key is cryptographically linked to the user’s identity allowing senders to encrypt the transfer secret specifically for the intended recipient.

where

• •$PK_r$ is the recipient public key,
• •$S$ is the transfer secret.

Only the recipient’s private key can recover the original secret.

The transfer provider never requires the recipient’s private key and therefore cannot recover the transfer secret on the recipient’s behalf.

For recipients who do not use Sharebox accounts, the sender may instead distribute the transfer secret independently through a QR code or private link. This preserves the separation between recipient verification and content decryption without requiring account registration.

Unlike traditional bearer-link systems, compromising a download URL does not automatically expose the encrypted contents. Authorization and decryption remain independent operations.

Separating identity from decryption significantly reduces the number of systems that participate in the trust model. The transfer provider determines who may receive the encrypted data, while only the recipient possesses the information required to transform that data back into plaintext.

Once the cryptographic foundation has been established, the transfer itself becomes a coordinated sequence of independent operations. Unlike conventional systems, encryption, storage, authorization, payment, and decryption are deliberately isolated from one another. No single stage possesses all information required to reconstruct the original file.

The lifecycle begins when the sender creates a transfer manifest describing the files that will be uploaded. This manifest contains only operational information required for coordination, including encrypted object identifiers, file sizes, recipient records, and expiration policies. File contents remain local to the sender’s device.

Each file is encrypted independently before upload and transmitted directly to cloud storage as ciphertext. The Sharebox platform records transfer state while verifying that uploaded objects match the expected manifest. Once payment has been confirmed, the transfer transitions into an active state and recipient notifications are issued.

Recipients first complete the configured verification requirements before receiving a short-lived download grant. This grant authorizes retrieval of encrypted objects but does not itself reveal decryption material. After the encrypted objects have been downloaded, the recipient recovers the transfer secret, unwraps the individual file keys, and decrypts the files entirely within the browser.

The protocol intentionally enforces expiration independently from encryption. A transfer may become unavailable because its authorization has expired even though the encrypted objects continue to exist until scheduled cleanup removes them. This distinction avoids making cryptographic claims about instantaneous deletion while ensuring that expired transfers cannot be accessed through the application.

Transfer validity is therefore defined as

where $t$ represents the current time.

This separation between authorization and storage is important. Revoking access does not require modifying encrypted objects themselves. Instead, the platform simply stops issuing valid download grants after expiration or revocation, while scheduled cleanup removes the remaining ciphertext according to platform policy.

By decomposing delivery into independent stages, Sharebox minimizes the information available to each component of the system. Storage stores encrypted objects. The platform coordinates state. Recipients perform decryption. No individual layer independently possesses everything required to reconstruct transferred information.

The objective of Sharebox is not to eliminate trust, but to reduce the amount of trust concentrated within the transfer provider. Security therefore depends on separating responsibilities across multiple independent components rather than protecting a single centralized system.

Traditional transfer platforms assume that protecting the provider protects the transfer. The platform stores the files, controls authorization, manages encryption, and coordinates delivery. While this architecture is practical, it also creates a single high-value target. Compromising one administrative domain may expose storage, metadata, authentication systems, and potentially the information required to recover transferred content. Sharebox intentionally distributes these responsibilities.

Cloud storage stores encrypted objects but does not possess the keys required to decrypt them. The application database stores wrapped key material but not reusable file keys. Recipient devices perform decryption locally after successful authorization. No individual component contains every element required to reconstruct the original transfer.

The security objective can therefore be expressed as

instead

where

• •$\mathit{Risk}_s$ is compromise of storage,
• •$\mathit{Risk}_d$ is compromise of the application database,
• •$\mathit{Risk}_e$ is a compromise of the endpoint.

An attacker must compromise multiple independent trust domains before confidential information becomes accessible. This architecture significantly reduces the impact of infrastructure failures. A leaked storage bucket exposes ciphertext. A leaked database exposes wrapped keys and operational metadata. Neither event alone is sufficient to recover plaintext.

The remaining trust assumptions are explicit rather than implicit. Sharebox still relies on correct browser code, secure authentication, trusted cryptographic libraries, and uncompromised recipient devices. These assumptions cannot be eliminated by protocol design alone and are therefore treated as part of the documented threat model rather than hidden implementation details.

Rather than claiming perfect security, Sharebox narrows the consequences of individual failures by ensuring that storage, coordination, authorization and decryption remain independent operations.

No browser-based protocol can guarantee absolute confidentiality once information reaches a recipient’s device. The purpose of Sharebox is to minimize the trust required during transport, not to solve every endpoint security problem.

If the sender’s or recipient’s device is compromised before encryption or after decryption, the protocol cannot protect the transferred information. Malware, malicious browser extensions, screen recording software, operating-system compromise and physical access remain outside the scope of the protocol.

Likewise, Sharebox cannot prevent an authorized recipient from redistributing decrypted files after download. Once information has been intentionally revealed to its recipient, cryptography can no longer control how that information is used.

The protocol also depends on the integrity of the delivered application. Browser-side encryption assumes that the JavaScript executing within the browser has not been modified before execution. Protecting the delivery pipeline therefore remains an essential operational responsibility. These limitations are common to virtually every browser-native cryptographic application and are explicitly acknowledged rather than treated as exceptions.

The goal of Sharebox is therefore not perfect security but measurable reduction of unnecessary trust and privacy.

Modern file-transfer platforms transformed digital collaboration by making the exchange of large files almost effortless. Their success demonstrates that convenience is one of the most important characteristics of internet infrastructure. Sharebox proposes an alternative architecture.

Rather than treating the transfer provider as the trusted custodian of user information, Sharebox reduces its role to that of a coordination layer. The protocol does not eliminate trust but it minimizes the amount of trust required for secure delivery.

In development: