Local Encryption vs Classic Cloud: What Actually Changes When Your Data Leaks

If you run a small business or work solo with client documents, the question is not really "could my data leak". Breaches happen to companies far bigger than yours, and to the vendors they trust. The useful question is: when a leak happens, what actually spills out? That answer depends almost entirely on one thing most people never check: who holds the keys to your files.

This article is not legal advice. It is a plain-language walk through what a data breach exposes under two setups: your files sitting on a classic cloud service (Google Drive, Dropbox, Notion, most SaaS tools), versus your files encrypted locally on your own machine before anything leaves it.

Quick Answer

In a classic cloud service, your files are usually encrypted "at rest" on the provider's servers, but the provider holds the decryption keys. So a breach of that provider, a rogue employee, or a valid legal request can expose your actual content in readable form. With local, client-side encryption, your files are scrambled on your device with a key that never leaves it; the server (if you sync at all) only ever stores opaque encrypted blobs. If that server leaks, attackers get ciphertext they cannot read without your password. The difference in a breach is stark: cloud-at-rest leaks your documents, client-side encryption leaks noise.

Why this keeps small teams and freelancers awake

When you handle other people's data (client contracts, health notes, financial records, source files, HR documents), a breach is not just your problem. You may owe those people, and possibly a regulator, an explanation.

Under the GDPR, a personal data breach can trigger an obligation to notify your supervisory authority (in general within 72 hours of becoming aware of it) and, when the risk to individuals is high, to notify the affected people too. That is the principle; the exact thresholds and wording live in the regulation and your national authority's guidance, so treat this as orientation, not a legal ruling.

Here is the part that changes everything, and where encryption stops being an abstract security feature: regulators and their guidance generally treat data that was rendered unintelligible to unauthorized parties (for example, properly encrypted with keys the attacker does not have) very differently from data that leaked in the clear. Strong encryption does not magically erase every obligation, but it can be the difference between "the exposed data is unreadable to whoever stole it" and "we have to tell 4,000 clients their contracts are in the wild." That is the real stake behind the boring phrase "who holds the keys."

The core difference: where encryption happens and who holds the key

Almost every serious service encrypts data "at rest." That phrase sounds reassuring and is quietly misleading. It means the data is encrypted on the provider's disks, with keys the provider manages. It protects against someone physically stealing a hard drive from a data center. It does not protect against the provider itself being breached, because the same infrastructure that serves your files also holds the keys to decrypt them.

Client-side encryption flips the order. The file is encrypted on your device, with a key derived from your password, before it is ever written to disk or uploaded. The service, if there is one, receives something it cannot read. This is the property people call zero-knowledge encryption: the host stores your data but is structurally unable to decrypt it.

Those two ideas, end-to-end and zero-knowledge, get used interchangeably and are not quite the same thing; if you want the precise distinction, we broke it down in end-to-end vs zero-knowledge encryption. For a breach analysis, the shortcut that matters is simple: does the server ever have the key, yes or no?

What a breach exposes, side by side

Scenario	Classic cloud (encrypted at rest)	Local / client-side encryption
Provider's servers hacked	Attacker can reach files in readable form if they also reach the keys	Attacker gets opaque encrypted blobs, useless without your password
Rogue or compromised employee	Can potentially access content (support tools, admin panels)	Cannot read content; keys are not on the server
Legal demand to the provider	Provider can be compelled to hand over readable data	Provider can only hand over ciphertext it cannot decrypt
Your own laptop stolen	Depends on disk encryption; app data may be readable	Files stay encrypted per file; still need your password
Backup or misconfigured bucket leaks	Readable documents exposed	Encrypted blobs exposed, not the content

Notice the last two rows. Client-side encryption is not a magic shield: if your laptop is unlocked and your workspace is open, an attacker with physical access is inside your trust boundary. The protection is strongest exactly where classic cloud is weakest, which is the server side, the place you do not control and cannot audit.

But is "at rest" ever enough?

Sometimes, yes, and honesty matters here. If your threat model is a stolen data-center drive or a lost backup tape, at-rest encryption handles it. If you need the provider's servers to actively process your content (full-text search they run, AI features, server-side collaboration, format conversion), they must be able to read it, and client-side encryption would break those features. That is a real trade-off, not a marketing footnote. Many teams accept it deliberately.

The problem is that most people never made that trade-off consciously. They assumed "encrypted" meant "the company can't read my stuff," and for classic cloud tools that assumption is usually wrong. Notion, for example, encrypts data at rest but is not end-to-end encrypted and holds the keys, which we covered in detail in is Notion encrypted.

What good client-side encryption actually looks like

Not all "encrypted" apps are equal, so it helps to know what a serious design includes. The pieces worth checking:

A strong authenticated cipher. The current standard is AES-256-GCM, which both encrypts and detects tampering. This is the same class of primitive used by TLS, Signal, and WireGuard.
A sane key hierarchy. A single global key for everything is fragile; if it leaks, all your data leaks. A better design uses a per-file key wrapped by a master key derived from your password, so one compromised file does not unravel the rest. This two-layer approach is the KEK/FEK model.
Slow key derivation. Your password should be stretched with a deliberately slow function so brute-forcing it is expensive. PBKDF2 with a high iteration count or Argon2id are the usual choices.
A recovery path that does not hand the key back to a server. A written recovery phrase (BIP-39 style) means you, not the provider, are the fallback.

If you want the full mental model of threat models and how to choose a tool, how to encrypt your notes is a practical starting point.

What this means for you, concretely

Whether or not you ever change tools, these steps lower your exposure the day a leak happens:

Inventory who can read your sensitive files. For each tool, ask the vendor one question: are the files end-to-end or client-side encrypted, or only "at rest"? If it is only at rest, assume a breach of that vendor exposes readable content.
Turn on full-disk encryption on every device (BitLocker on Windows, FileVault on macOS, LUKS on Linux). This is your baseline for the "stolen laptop" row above and it is free.
Separate high-sensitivity data. Client contracts, health records, and financial documents deserve client-side encryption even if your general notes do not.
Keep an encrypted local copy of anything critical, so a cloud vendor outage or account lockout does not also lock you out of your own work.
Write down your recovery method and store it offline. Client-side encryption means nobody can reset your password for you, which is the point, and also the risk.
Have a breach reflex ready. Know who your supervisory authority is and roughly what your notification duty looks like before you need it, because the clock is short.

Where Filarr fits (and where it does not)

Filarr is a local-first encrypted workspace: notes, files, and a graph connecting them, all living encrypted on your own disk. Concretely, every file is encrypted individually with AES-256-GCM using a per-file key (the FEK), which is wrapped by a master key (the KEK) derived from your password with PBKDF2-SHA512 at 600,000 iterations (following OWASP guidance), with Argon2id available as an option. Recovery is a 24-word BIP-39 phrase you hold, not the server.

Cloud sync is optional. When you do enable it, files are uploaded already encrypted, and the backend stores only opaque blobs; the key never reaches it in cleartext. So in the breach scenarios above, a leak of Filarr's sync storage exposes ciphertext, not your documents. If you want the exact mechanics, we opened up the code in how Filarr's cloud sync stays zero-knowledge, and the full defensive architecture is documented in Filarr security, layer by layer.

What Filarr does not do, stated plainly:

It does not make you GDPR-compliant. Encryption is one technical measure; compliance depends on your entire processing, contracts, retention, and legal basis. A tool cannot certify that for you.
It does not protect an unlocked, open workspace on a compromised machine. Client-side encryption guards data at rest and in transit, not a session you left running.
It is younger than Obsidian or Notion, with a smaller plugin ecosystem and mobile still in progress. If you need a mature app store of extensions today, that is a real gap.

The honest pitch is narrow: if your worry is specifically "what leaks when my vendor gets breached," client-side encryption changes the answer from "my clients' documents" to "unreadable noise," and that is the whole point.

FAQ

If a service encrypts data "at rest," isn't my data safe in a breach? Not necessarily. At-rest encryption protects against stolen physical disks, but the provider holds the keys, so a breach of the provider's live systems, a rogue employee, or a legal order can still expose readable content. Client-side encryption is what keeps the content unreadable to the host itself.

Does encryption remove my GDPR breach-notification duty? No, but it can change the risk assessment. Guidance generally treats data that was unintelligible to the attacker (properly encrypted, keys not compromised) more favorably than data leaked in the clear, which can affect whether affected individuals must be notified. This is orientation, not legal advice; check your national authority's guidance for your situation.

What is the catch with client-side encryption? Two things. The provider cannot offer features that need to read your content (server-side search, AI on your data, some collaboration), and nobody can recover your account if you lose your password and recovery phrase. You trade convenience and a safety net for the guarantee that the host cannot read your data.

Is local-first the same as offline-only? No. Local-first means your data lives on your device and works fully offline, but you can still sync across devices. The difference from classic cloud is that sync is optional and, done right, carries only encrypted blobs the server cannot read.

My laptop could still be stolen. Does encryption even help then? Yes, partially. Files encrypted per file plus full-disk encryption mean a thief with the powered-off machine faces your password, not your documents. What it does not protect is an unlocked device with your workspace already open, which is why device-level habits still matter.