Why private one-time sharing matters in the EU "Chat Control" debate
The most relevant "Chat Control" risk for an ordinary business is not an abstract argument about a URL or encryption algorithm. It is that broad automated detection could require private chat content to pass through additional analysis systems. A password, recovery code, bank detail, legal note, or employee record pasted into chat could then enter not only conversation history, but a processing chain involving classifiers, matching tools, telemetry, alert queues, and - in flagged cases - human review. A one-time encrypted link changes the input to that chain: the chat service processes a link, while the readable secret is handled separately in the sender's and recipient's browsers. That is useful risk reduction, not invisibility or a way to evade applicable law.
This is an architectural explainer, not legal advice or a claim about the proposal's current legislative stage. "Chat Control" commonly refers to the European Commission's 2022 proposal for a regulation addressing child sexual abuse online, procedure 2022/0155(COD), plus later amendments and negotiating texts. The text and status can change. Check the official European Parliament procedure file and EUR-Lex proposal before relying on any summary.
What broad automated inspection changes
The Commission's 2022 proposal would create obligations for certain online services to assess and mitigate risks, report detected material, and, where ordered under the proposed framework, use technologies to detect specified child sexual abuse material or solicitation. Protecting children and investigating abuse are legitimate and urgent goals. The difficult technical question is whether detection can be effective and targeted without turning unrelated private communications into inputs for generalized automated inspection.
If detection is applied broadly, a message cannot remain opaque to every part of the service. It must be analysed where readable content is available: on the device before encryption, after decryption, or in provider infrastructure if the provider can access plaintext. The exact design matters, but the security boundary changes in every case. Code beyond the chat interface now receives or derives a signal from message content.
The European Data Protection Board and European Data Protection Supervisor raised concerns about necessity, proportionality, generalized monitoring, error rates, and effects on encryption in their Joint Opinion 04/2022. The policy question is not whether child abuse is harmful; it is whether a proposed measure is effective, targeted, secure, and proportionate while respecting the rights of everyone else whose lawful messages pass through the same system.
A scanner is a pipeline, not a single yes-or-no operation
"Automated detection" can sound like a sealed function that reads a message, returns a result, and forgets everything. A production system is usually broader. Content or a representation of it may be normalized, hashed, classified, scored, and associated with account and device metadata. Results may feed abuse telemetry, retry and error handling, model-quality measurement, alert queues, appeals, and incident investigation. A positive or uncertain result may be retained and shown to a moderator or another authorized reviewer.
This does not mean every implementation must write every raw message to a permanent log. Careful systems can avoid plaintext logging, isolate components, retain only narrowly defined signals, and delete intermediate data. But processing is still additional exposure: more code runs against the message, more components influence confidentiality, and a bug, diagnostic setting, compromised model service, excessive retention rule, or false positive can move lawful content beyond the conversation path the user expected.
That matters for ordinary secrets. A support password misclassified by an automated system is not abusive content, but it may still enter a flagged-event pipeline. A recovery code included in a crash trace is still usable. A private HR detail shown during human review is still disclosed. Security is therefore not only about the intended purpose of detection; it is also about minimizing unrelated plaintext that enters the inspected channel in the first place.
Do not paste the raw password or private record into a channel that may retain and automatically inspect message content. Put a one-time link in the chat instead, and send its password through a different channel. The chat platform can then log, index, back up, summarize or scan that message as much as it likes: it holds a locator, not the secret, and without the password the locator opens nothing. Without a password the link itself is the key - a system that follows it can open the share once, but not unnoticed, because the share is then gone and the recipient finds it unavailable.
The risk already exists - and inspection can expand it
Chat services already commonly retain conversation history and may create copies in notifications, exports, backups, search indexes, workplace archives, moderation tools, and integrations. A detection requirement can add another processing purpose and another route from a message to an alert or review system. Deleting the visible message later does not necessarily erase every derivative record.
This is especially relevant for routine business handoffs: temporary credentials, recovery codes, bank details, customer records, short legal instructions, and employee information. These messages are lawful and mundane, but the damage from an accidental log, false-positive queue, breached integration, or over-broad internal access can be concrete.
How Klassified keeps the secret out of the chat pipeline
With Klassified, the sender puts the sensitive value into a separate browser-encrypted share and pastes only the resulting one-time link into chat. The chat service receives the link and surrounding conversation, but not the password, document text, or recovery code as message plaintext. Klassified stores an encrypted payload; the recipient's browser retrieves and decrypts it, and the stored payload is consumed after retrieval or automatic expiry.
That keeps the secret out of the places it would otherwise end up: message logs, search indexes, backups, conversation digests and AI training or "distillation" pipelines. Two things decide how far that protection goes. With a password that travels by another route, the link on its own opens nothing, for any system or person who sees it; only the recipient who knows the password can read the share. Without a password, whoever opens the link first can read it - but only once, and visibly, because the share is destroyed on that first reading.
Secret path: sender browser → encrypted payload → recipient browser
This separation reduces several forms of exposure:
- Chat classifiers and matching systems do not receive the raw secret as message text.
- Chat logs, search indexes, exports, and backups contain the link rather than the readable value.
- A chat false positive cannot quote a password that was never included in the chat message.
- The transfer provider stores ciphertext rather than a second readable copy.
- The encrypted payload has a short lifetime instead of inheriting the chat's retention period.
This is compartmentalization and data minimization. It does not stop the chat provider from analysing or retaining the link, sender, recipient, timestamp, or surrounding words. It reduces the consequence of that processing by keeping the highest-value plaintext outside it.
What this does not solve
A trustworthy security argument must include its boundaries. One-time encrypted sharing does not provide immunity from legislation or lawful process, and MAIN OÜ does not market it for concealing criminal activity. The service must comply with laws that apply to it and can be required to provide data it actually possesses.
- The endpoints see plaintext. Malware, a compromised browser, an unsafe extension, or operating-system capture can read content before encryption or after decryption.
- The recipient can retain it. A recipient can copy, screenshot, photograph, or forward anything revealed. "One time" controls the stored server copy, not human behavior.
- The surrounding platform still processes the message. A chat provider can inspect and retain the link, timestamp, sender, recipient, and surrounding words. Link-preview or security systems may also fetch the destination, so recipients should reveal the payload deliberately rather than through automated previews.
- Klassified also processes metadata. Delivery requires an identifier, payload size, expiry, request information, and limited operational records described in the privacy policy.
- A final law could address client-side services. Whether a particular service or feature falls within a regulation depends on the enacted wording, provider category, jurisdiction, and implementation. Encryption alone is not a legal classification.
- A link without a password is a capability. Anyone who obtains it before the intended recipient can open it once. In practice they cannot do so unnoticed: the share is then gone, and the recipient finds it unavailable. (Only a fetch at almost the same moment as the recipient's could go unseen.) Klassified does not say why a share is unavailable - a mistyped link, an expiry and an interception look the same - so the sender and recipient should treat any share that is unavailable on first opening as exposed, and rotate the secret. A password sent over a separate channel removes this risk: without it the link opens nothing for anyone.
Why this remains useful under regulatory uncertainty
The final legal scope may change, and a one-time sharing provider may itself have obligations under applicable law. The practical security principle does not depend on predicting the final text: do not give one system plaintext it does not need. Separating temporary secret transfer from durable conversation means a compromise, logging mistake, broad classifier, or mistaken review in the chat environment has less sensitive content available to expose.
The benefit is not that automated processing disappears. It is that each system receives less. The chat platform processes the conversation and a temporary link. The transfer service handles ciphertext and delivery metadata. Plaintext exists at the sender and recipient endpoints where it is needed. That narrower allocation of data is easier to reason about than allowing every collaboration, moderation, analytics, and archival component to encounter the raw secret.
A safe workflow for a sensitive handoff
- Decide whether the information should be sent at all. Do not transfer a permanent record through an ephemeral tool when retention or audit duties apply.
- Create a short-lived encrypted share. Select the shortest practical expiry and avoid including unnecessary personal data.
- Add a password whenever the chat channel itself is the concern. Send that password over a separate verified channel, never beside the link: it is what keeps every system that sees the link from reading the share.
- Send the link through the ordinary channel. The chat history then contains the temporary capability, not the plaintext secret.
- Confirm receipt and rotate credentials. One-time delivery is not a substitute for changing a shared password after use.
- Keep required records elsewhere. Contracts, consent records, regulated files, and business archives belong in systems designed for durable retention and access control.
Primary sources and further reading
- European Commission proposal COM(2022) 209 on preventing and combating child sexual abuse.
- European Parliament Legislative Observatory: procedure 2022/0155(COD).
- EDPB - EDPS Joint Opinion 04/2022.
- Charter of Fundamental Rights of the European Union.
- General Data Protection Regulation, including data and storage minimization principles.
- "Chat Control" is shorthand for a changing legislative debate, not the formal name of one settled rule.
- Broad automated inspection can add classifiers, telemetry, alert queues, and human review to the path taken by a lawful private message.
- A one-time encrypted link keeps the raw secret out of durable chat history and out of log, digest and AI pipelines; a password sent over another channel makes the link useless to every system that sees it.
- Without a password, the first opener can read the share once, but not silently: an unavailable share on first opening means something went wrong.
- This is compartmentalization, not anonymity: endpoints, recipients, links, previews, and metadata remain important risks.
- Encryption does not exempt a provider or user from applicable law, and the final legal scope must be checked in official sources.
- The safest use is a narrow, lawful handoff with short expiry, recipient verification, and credential rotation where appropriate.
Klassified lets the chat carry a one-time link instead of the raw password or private record. Add a password and send it another way, and nothing the chat's automated systems can see will open the secret; the separate encrypted payload is destroyed after retrieval or expiry.
Create a private one-time link