What It Actually Means to Own Your Data

On July 1, 2013, Google opened the export window for Google Reader. Users had exactly fifteen days to download their subscription data before the service shut down permanently — and most of them didn't know, because Google had announced the closure three months earlier and the internet only pays attention to shutdown countdowns in the final week. The users who did export received a ZIP file containing their feeds in OPML format. Technically machine-readable. Practically, you needed one of maybe six remaining RSS readers that could import it, and only if you found one before the deadline passed.

That experience is a useful lesson: "your data is yours" is a promise apps make about the present, not the future.

What the export button actually gives you

Most apps have an export button. What that button produces is worth examining before you trust it.

Evernote exports notes in .enex format — a proprietary XML schema that most other apps cannot read without a conversion step, and those conversion tools tend to mangle formatting in ways that only reveal themselves when you're already mid-crisis. Notion exports to Markdown, which sounds reassuring until you look at the files: relations and rollups disappear, images export as paths to files that were never included, and the folder hierarchy collapses into something that no longer matches what you built.

The GDPR gives EU residents a formal right to data portability under Article 20. What this right actually guarantees is that the format must be "machine-readable." A well-structured JSON dump satisfies that requirement. So does a CSV with column headers like id, field_1, and field_2. Technically compliant. Practically useless, if you don't know what the IDs reference or how the schema maps to anything you recognize.

This is the gap between portability as a legal concept and portability as something you can actually use.

What real ownership looks like

There are three questions I now ask about any tool I trust with important information.

Can I open the exported files in a text editor and read them? Not "can a computer parse them" — can I, personally, open the file and understand what's inside without running it through another application first.

If I restored from this export on a machine with none of the original app's software installed, would I get my data back intact — the structure, the relationships, the formatting? Not a shadow of it, the actual thing.

And will the format be readable in twenty years?

The .txt files I wrote in 2003 still open. The Palm Desktop exports from the same era are archaeologically interesting but practically gone. Markdown passes all three tests. SQLite databases pass two — a text editor won't help you, but the file is a single self-contained artifact that the SQLite command-line tool can query on any operating system for the foreseeable future. Notion's export passes none of them reliably.

Martin Kleppmann and his colleagues at Ink & Switch put a name to this in 2019: local-first software, where the user's device holds the primary copy and cloud sync is the secondary layer, not the other way around. The key property is that your data should be fully usable without connectivity, without accounts, and without the original vendor. The paper is worth reading. It also explains why the local-first model is harder to build than it looks, which is why most apps still don't do it.

The timing problem

Here's the thing about data ownership: you only discover whether you actually have it during a crisis, and crises tend to come with deadlines.

A service shuts down. An acquisition changes the terms. A pricing change makes the tool unaffordable. And now you have thirty days, or fifteen, or none, to move everything somewhere else. The export button is there. But for most apps, "export" means "here is a representation of your data that we will not help you move, restore, or understand on the other side."

I ran into this when I stopped using a tool I'd depended on for two years. The export was a JSON file, technically complete. I spent three hours writing a script to parse it into something I could actually use. Three hours on data I supposedly already owned.

The time to think about portability is when you don't need it — while evaluating a new tool, not while rushing to leave one. It should be a selection criterion: What formats does this app export? Can I restore from that export without help from the vendor? Does the company have a record of giving users meaningful time and tooling when they decide to leave?

Most apps will not volunteer these answers. You have to ask.

---

Asgeir Albretsen is the founder of Harbor.