What does it take to actually own your own data?

Three tests a file has to pass

Data ownership sounds like a legal question. In practice it is three mechanical ones, and a file has to pass all of them. Most of what people call their data passes one or two. A photo library that exists only inside an account passes none, whatever the terms of service say about who owns the content.

• Custody: the bytes are on storage you physically control. A copy held for you on a server is a service, not custody.
• Legibility: at least one program that is not the original can open the file and get the same meaning out of it.
• Survival: the file still opens with the original program deleted, the company gone, the network down and nothing paid this month.

Why an export button is weaker than a readable file

An export is a promise about a future moment. A file is a fact about the present. The export runs on someone else's machines, on their schedule, in a shape they choose, and it exists for exactly as long as they do. On the day a service goes dark, the export button goes dark with it.

Exports also tend to lose structure. What comes back is often content without relationships: notes stripped of their links, records without the identifiers that connected them, attachments in a folder with no map back to what referenced them. You can read every line and still not be able to rebuild what you had.

Portability law helps and stops short of ownership. Under Article 20 of the EU’s GDPR, a person may receive personal data they provided to a controller in a structured, commonly used, machine-readable format and transmit it to another controller when processing is automated and based on consent or a contract. This portability right has limits; it does not give you custody or guarantee that a copy remains usable.

What makes a format readable by something else

The useful test is not the word open. It is whether the format has a published specification and more than one working implementation. Plain text, CSV, JSON, Markdown, PDF, JPEG, PNG, .ics calendar files and .vcf contact cards all pass. If every program you use today vanished, other programs could still read them.

Undocumented formats fail this test even when the file is sitting on your own disk. So does a documented format wrapped in encryption whose key lives on someone else's server: the bytes are yours and the ability to read them is not. Encryption where you hold the key is a different thing. That file is yours, and losing the key is on you.

A file you hold still has to survive the hardware

Custody moves the point of failure from a company to a drive, and drives fail. One copy on one device is a single point of failure whether or not you own the device. The long-standing practitioner rule of thumb is 3-2-1: three copies of anything that matters, on two different kinds of storage, with one of them physically somewhere else.

Formats outlive media. A drive from fifteen years ago is often unreadable while a plain text file recovered from it opens instantly. That asymmetry is the whole argument for boring formats. The cheapest way to keep something readable for a long time is to keep it in a shape many programs can read, then copy it forward as hardware changes.

Where the honest answer is that it depends

Some data only means anything inside a live service. A copy of a message history is a real file. The ability to reply is not something you can hold in a folder. Where the line falls depends on whether the value is in the record or in the connection, and it is worth deciding which one you actually want before judging an app by its export.

Sync is the case people get wrong most often. A folder that mirrors across devices is convenience, not a backup. A deletion or a corruption propagates to every copy in seconds, which is the exact failure a backup exists to prevent. Version history helps, and only for as long as the account behind it stays open.

At the application level the same three tests apply, and the first one you can check yourself is whether the app needs the network at all.