Retyc logo blue
All articlesSecurity

Sending a file through a free transfer service: what you are really handing over

Drop a file, type an address, click "Send". Consumer file transfer services have become a reflex at work. Without end-to-end encryption, they see everything that goes through them. Five professional situations to understand what that means.
EM

Emilien Mantel

The file is too large for an email. You open an online transfer service, drop the folder, type the recipient's address, and off it goes. Two minutes, no account to create, often free. These services have become a reflex in almost every company, including for documents that should never have travelled this way.

The problem is not the simplicity. It is what happens once the file is sent: on most of these services, it arrives readable on their servers. It is encrypted in transit, often on their disks too, but the service holds the key. We explained this difference in our article on the three levels of encryption. Here, we look at the practical consequences, through situations we come across with our customers.

What really happens when you click "Send"

On a classic transfer service, without end-to-end encryption:

  1. The file leaves your computer in plaintext, protected only by HTTPS while in transit.
  2. The service receives and stores it. It can open it to generate a preview, scan it for viruses, index it, or hand it over to whoever makes a legal request.
  3. It also keeps all the context: the file names, your address, the recipient's address, the accompanying message, the date, the size. This information often says as much as the content itself.
  4. The recipient gets a link. On most of these services, that link is enough to download the file, whoever clicks on it.
  5. When it expires, the link stops working. What becomes of the file in the service's backups and logs, you have no way of checking.

At none of these steps are you in control. You are trusting the service, its employees, its subcontractors, its security, and its future terms of use.

Case 1: the accounting firm and the payslips

An accounting firm runs payroll for a small company with forty employees. Every month, it sends the manager an archive with the payslips, the payroll ledger and the social security filings. The archive weighs 30 MB, the mail server rejects it, and the accountant uses a free transfer service.

What the archive contains: the names, addresses, social security numbers, salaries, bank details and sick leave of forty people. In other words, exactly what a fraudster looks for to commit identity theft or a fake change of bank details.

Under the GDPR, the firm has just entrusted this data to a provider that can read it. That provider effectively becomes a processor (Article 28), with no contract, no audit, sometimes without the firm even knowing in which country the files are stored. And Article 32 requires the firm to ensure a level of security appropriate to the risk. If these files leak, it is the firm that will have to explain it to the data protection authority and to its client.

Case 2: the lawyer and their client

Between lawyers, and with the courts, the question is largely settled in France: submissions and case documents are exchanged over the RPVA, the profession's secure network, through the e-Barreau platform. But that network stops at the door of the law firm. The client has no access to it. And it is between lawyers and their clients that the most delicate documents circulate.

Take an employee challenging their dismissal before the employment tribunal. To prepare the case, they have to give their lawyer their payslips, their contract, years of work emails, sometimes medical certificates or recordings. The whole thing weighs several hundred megabytes. They use the transfer service they know. In the other direction, the lawyer sends them their analysis of the case, draft submissions, the documents disclosed by the other side. The same goes for the executive having a draft sale agreement reviewed, or the couple preparing a divorce.

In France, the law of 31 December 1971 (Article 66-5) places under professional secrecy the lawyer's advice and the correspondence exchanged between lawyer and client, and more broadly all the documents in the file. This secrecy protects the client: what they entrust to their lawyer must not be readable by a third party. A transfer service that can open the files has no reason to read them, and most of the time it does not. But it has the technical ability to, and so does anyone who gains access to its servers, or any authority, domestic or foreign, that asks for them.

The difficulty specific to this relationship is that the lawyer does not always choose the channel. The client sends their documents by whatever means they know, and the lawyer receives them without having had a say. The simplest way to stay in control is to offer the client, as soon as the case opens, an end-to-end encrypted drop-off channel, as easy for them as a transfer service, rather than hoping they find one on their own.

Case 3: human resources and the sensitive file

An HR manager has to send the company's lawyer an employee's file as part of a dismissal procedure: appraisals, email exchanges, medical certificates, meeting minutes. They use the transfer service everyone in the company uses.

This file contains health data, which the GDPR classifies as sensitive data. It concerns a person in dispute with their employer, who may one day ask what happened to their data. And the name of the archive, visible to the service in plaintext, is often as explicit as "Dismissal_file_Martin.zip". Without even opening the file, the service already knows what it is about.

Sending to the wrong recipient happens quickly: according to the CNIL, the French data protection authority, sending data to the wrong person accounted for 13% of the breaches notified to it in 2025. With a classic transfer service, the link goes out, and there is nothing to be done to take it back, other than deleting the transfer and hoping nobody has clicked yet.

Case 4: the engineering firm and the plans of a sensitive site

An engineering firm is working on the extension of an industrial site: a factory, a logistics warehouse, a data centre. It exchanges with subcontractors the building plans, the location of entrances, the electrical diagrams, the CCTV network. The files are heavy, they go out through a transfer service, to dozens of recipients, for months.

These plans are of obvious value to anyone wanting to get into the site, or to a competitor. Yet they go through a service whose host, storage country and retention policy you do not know. And because the links circulate between companies, by email or instant messaging, a single compromised mailbox among the dozens of recipients is enough to expose every link that is still active.

Case 5: the agency and the embargoed campaign

A communications agency is preparing the launch of a product that will only be announced in three weeks. It sends the visuals, videos and press kit to the client, then to the printer, then to the photo studio. Everything goes through a transfer service, because it is the tool the whole industry uses.

In July 2025, one of the most widely used transfer services in the world changed its terms of use. The new version required users to grant it a worldwide, perpetual, transferable and sublicensable licence to their content, including for training machine learning models. Faced with the reaction of photographers, designers and agencies, the service withdrew the clause before it came into force. The corrected version still allows files to be used to "improve the service".

The episode does not prove that any file was misused. It shows something else: when a service can read your files, what it is allowed to do with them depends on a text it can change. A service that cannot read them has nothing to change.

The overlooked risk: fake notifications

These services have a side effect that is rarely mentioned. After receiving so many "You have received files, click to download" emails, everyone has learned to click on them without a second thought. Attackers understood this long ago: fake file transfer notifications are among the most common phishing templates. The link leads to a fake login page that harvests the password of the work mailbox.

A transfer service everyone uses for everything, with emails that all look alike, is ideal ground for this kind of attack. It is not the service's fault, but it is one more reason not to make "clicking a download link received by email" a daily, automatic gesture.

"But I put a password on my transfers"

Some services let you protect a transfer with a password. That helps: the link alone is no longer enough, the password is needed too. But in most cases, this password protects access to the download, not the file itself. The file remains stored in readable form by the service, which checks the password before serving it. The service, its administrators, an attacker who gets in or an authority making a request still have access to it.

A useful password is one that is used to decrypt the file, on the recipient's device, and that the service never knows. The question to ask remains the same: if I forget this password, can the service still send me the file? If so, it can read it.

What changes with end-to-end encryption

Let's go back over the five cases with an end-to-end encrypted transfer service. The file is encrypted on the sender's computer before it leaves, the service only stores unreadable content, and only the recipient can open it.

  • The service cannot read the files, nor their names, nor the message that goes with them. The payslips, the documents entrusted to the lawyer, the HR file, the plans and the visuals remain unreadable on its side.
  • A breach of the service only yields unreadable data. That is the difference between a document leak and a leak of worthless encrypted blocks.
  • A request from an authority to the service can only obtain what it holds: files it cannot open.
  • The terms of use cannot change the picture. A service that cannot read your files cannot use them either.
  • You stay in control after sending: expiry date, deactivating the link at any time, including after sending to the wrong recipient.

This is how Retyc Transfer works. The recipient has nothing to install: they click, and the file is decrypted in their browser. And for the other direction, when you are the one expecting documents from a client or a candidate, an encrypted drop box saves you from asking them to use the first transfer service that comes along.

Four questions before sending a file

  1. Would I be comfortable if this file were published tomorrow? If the answer is no, it should not go through a service that can read it.
  2. Can the service open my file? If it shows a preview, or can send it back to you after a forgotten password, yes.
  3. What happens if the link is forwarded? If anyone can download with the link alone, your file is only as well protected as the least secure mailbox among those that will receive it.
  4. Can I cut off access if I send it to the wrong person? If the only option is hoping nobody has clicked, that is not an option.

In short

Consumer file transfer services solved a real problem: sending files too large for email. They were never designed to protect those files from the service itself. For a holiday photo, that does not matter at all. For payslips, documents entrusted to a lawyer, an HR file or the plans of an industrial site, it engages the responsibility of the company sending them. Simplicity is not the problem, an end-to-end encrypted service is just as easy to use. The problem is handing sensitive documents to someone who can read them, without really having decided to.

Sources:

Anatomy of an encrypted upload in the browser

A post-quantum key pair per transfer, 8 MB chunks encrypted one by one in a Web Worker, an API that refuses classic keys. What the browser does between the moment you drop a file and the moment the last byte leaves, with the code to show for it.

Retyc and AI: connecting your agent to your transfers and datarooms with MCP

Retyc embeds no AI. But your agent can drive Retyc: the command-line client exposes an MCP server that runs on your machine. What it enables, how to install it, what the agent sees and does not see, and the limits to know before using it.