Transfer a file browser to browser without a middleman

The usual way to send a large file is to upload it somewhere and send a link. That works, and it quietly creates a copy of your document on a third party's storage, protected by a URL that anyone who obtains it can use.

Direct transfer removes the middle step.

How a direct transfer works

The direct sharing tool establishes a connection between two browsers and streams the file over it. In outline:

1. The sender opens a session and shares a short code with the recipient.
2. The recipient joins, and a direct connection is negotiated between the two browsers.
3. The recipient sees what is being offered and approves it before any data moves.
4. The file streams across the connection.
5. Both sides can compare a SHA-256 fingerprint to confirm the received file matches the sent one.

The important property is that the file's contents are not stored on an intermediate service. There is no bucket holding your document, no retention window to reason about, no link that keeps working after you have forgotten it, and nothing to remember to delete next month.

What this is good for

• Large files. Attachment limits do not apply, so the practical ceilings described in the email size guide stop being the constraint.
• Confidential documents going to one specific person.
• One-off transfers where creating an account somewhere is disproportionate.
• Cross-device moves, such as getting a scan from a phone onto a laptop.
• Situations where a stored copy is unacceptable, including regulated material where introducing a processor would require an agreement you do not have.

That last case is the one where direct transfer is not merely convenient. As the compliance guide sets out, sending a document to a storage service is a disclosure to a third party. A transfer with no third party in the path does not create one.

The trade-offs, stated plainly

Direct transfer is not universally better, and the limitations are structural rather than incidental:

• Both people must be present. There is no store-and-forward. If the recipient is asleep in another timezone, a direct session is the wrong mechanism.
• The connection has to be established. Restrictive corporate networks and some firewalls interfere with direct connections between browsers.
• Interruptions mean restarting. A dropped connection partway through a large transfer usually means going again.
• It does not scale to many recipients. Sending the same file to twenty people means twenty sessions.
• Speed depends on both connections. The transfer runs at the slower of the two, and a poor uplink is the usual bottleneck.

Verify with a fingerprint

The approval step confirms the recipient wanted the file. The fingerprint confirms they got all of it.

Compute the SHA-256 digest at both ends with the fingerprinting tool and compare. Matching digests mean the received file is byte-for-byte identical to the sent one. A mismatch means something went wrong in transit and the transfer should be repeated.

This takes seconds and is worth doing routinely for anything important. It is the same check described in the version comparison guide, used here for integrity rather than change detection. Recording the fingerprint also gives you a defensible answer to "is this the file you sent me?" later on.

Sensible habits

• Confirm you are connected to the right person before approving. A code shared in the wrong channel connects the wrong browser.
• Encrypt genuinely sensitive documents anyway. Transport and document protection are separate concerns, and the encryption guide covers choosing a passphrase and delivering it separately.
• Agree the transfer in advance. Direct transfer needs both parties present, so a quick message beforehand avoids a session waiting for someone who is not there.
• Do not leave a session open after the transfer completes.
• Check the file opens at the receiving end before the sender closes down. A fingerprint proves the bytes arrived; opening it proves they were the bytes you meant to send.