Privacy & data

Data ownership as a practice, not a feature

No app can sell you ownership; it is a set of habits you run. The four tests that define it, the boring formats that pass them, naming that survives decades, the 3-2-1 backup actually explained, and an exit plan for every tool you use.

Aleem O'BalogunBy Aleem O'Balogun|Updated |8 min read

The short answer

Owning your data is a practice, not a feature you buy. It means passing four tests for anything that matters: you can read it without the vendor, copy it freely, back it up yourself, and leave without loss. In practice that is plain, boring formats, names that sort, the 3-2-1 backup rule, sync you control, and a tested exit plan for every tool you rely on.

Steps

  1. 1

    Run the four tests on what you rely on

    For each tool that holds something you would mind losing, ask: can I read this without the vendor? Copy it freely? Back it up myself, on my schedule? Leave without loss? Four yeses is ownership. Anything less is a tenancy, which can be a fine arrangement, as long as you know you are renting.

  2. 2

    Prefer boring formats

    Plain text and markdown for words, CSV for tables, JPG and PNG for images, PDF for documents that must hold their shape. Boring formats are the ones with a thousand readers and no owner, which is exactly what makes them durable. Metadata rides along in frontmatter: a few labelled lines at the top of a text file, readable by tools and by you.

  3. 3

    Name things so your future self can find them

    Dates first and ISO (2026-07-26, 2026-W31), lowercase, hyphens instead of spaces, and the name says what the thing is. Sortable by name is findable by eye, in any tool, forever. The habit costs nothing at write time and is the difference between an archive and a landfill ten years on.

  4. 4

    Back up on the 3-2-1 rule

    Three copies of anything that matters, on two different kinds of storage, one of them somewhere else. In practice: the copy you work on, an external drive at home, and an encrypted cloud backup. The rule is only half the practice; the other half is restoring one file twice a year to prove the backups are real.

  5. 5

    Keep a tested exit for every tool

    For each tool you rely on, know the export path, run it twice a year on a calendar reminder, and keep the latest export in your archive. An exit you have never tested is a hope. Twenty minutes a year per tool converts it into a plan, and quietly changes how every future tool decision feels.

Ownership is four tests, not a slogan

Almost every notes and planning tool now says some version of you own your data, and the phrase means anything from your files sit in a folder you control to we will let you download a zip on the way out. The way through the marketing is to stop treating ownership as a property of tools and start treating it as a practice you run, defined by four tests. Can you read the data without the vendor's software running? Can you copy all of it, freely and completely? Can you back it up yourself, on your own schedule, to places you choose? Can you leave for another tool without losing the substance of what you made?

Run honestly, the tests produce a useful map rather than a purity contest. A local folder of markdown passes all four by construction. A well-behaved app with real export passes most of them most of the time. A tool that fails all four can still be worth using for what it does; the practice just says: know which arrangement you are in, and never keep the only copy of something that matters inside a tenancy.

The substrate: boring formats and honest metadata

Durability in data is unglamorous: the formats that last are the ones too simple and too widespread to die. Plain text and markdown for anything written, CSV for anything tabular, JPG and PNG for images, PDF for documents whose layout is the point. Every one of them has more independent readers than any vendor has customers, which is the actual mechanism of future-proofing: no company needs to survive for your files to open. This is why the plain-files life OS is the reference build, and why an Obsidian vault (a folder of markdown) inherits the same guarantees.

Structure, when you need it, goes in frontmatter: a small labelled block at the top of a text file (a date, a few tags, a status) that both software and humans can read. It is the honest middle ground between no structure and a proprietary database: enough for tools to sort and query, never enough to hold your words hostage. If a tool needs more structure than frontmatter to be useful to you, that is fine, and it is exactly where a twice-yearly export earns its keep.

3-2-1, explained like you will actually do it

The rule comes from photography (Peter Krogh coined it for photographers with irreplaceable archives, and it was later recommended by the US computer-emergency establishment): keep three copies of anything that matters, on two different kinds of storage, with one copy off-site. The reasoning is plain: one copy is an accident away from zero, two copies on the same kind of storage share the same failure modes, and everything in one building shares the same fire.

The domestic version takes an afternoon to set up. Copy one is the data you work on. Copy two is an external drive that lives at home and gets refreshed on a schedule your calendar owns, not your memory. Copy three is an encrypted cloud backup running automatically. Then the half everyone skips: twice a year, restore one real file from each copy and open it. A backup you have never restored from is a superstition, and the restore test is what converts it into infrastructure. Put both rituals on the calendar now; ownership is mostly diarised chores.

Sync you control, and the exit plan ritual

Sync and backup get conflated and should not be: sync makes the same current state appear everywhere (including a deletion, everywhere, instantly), while backup preserves past states you can return to. You want both, separately. For files you own, any file-sync mechanism works precisely because the files do not care who carries them: a cloud drive folder, or a peer-to-peer tool like Syncthing if you want no third party holding a copy at all. The principle is vendor-independence: the sync layer should be swappable without touching the data it moves.

The exit plan is the practice's final habit and its quietest superpower. For every tool you rely on: know where the export lives, what it produces, and what does not survive it (Notion's own documentation, for instance, is candid that an exported workspace cannot be re-uploaded back into being: the words survive, the machinery does not). Run the export twice a year, keep the latest one in your archive, and note the date. The point is not paranoia about any vendor; it is that a person with tested exits makes every tool decision from freedom instead of sunk cost.

The ways ownership quietly lapses

Nobody loses a decade of notes on purpose. It happens in these shapes:

  • The untested backup: years of dutiful copies, zero restores. The first restore attempt is the worst possible time to learn the answer. Twice a year, one real file
  • The proprietary graveyard: the app that closed, the format nothing else read. Boring formats are the vaccine. Exotic ones need an exit tested the day you adopt them
  • The someday migration: knowing you should get your stuff out, for three years. Exports are twenty minutes. Put the reminder on the calendar and stop carrying the intention
  • The sync-as-backup mistake: one deletion propagated everywhere at the speed of light. Sync is availability. Backup is history. Run both and never confuse them
  • The offsite gap: perfect copies, all in one flat. The 1 in 3-2-1 is the part that survives the worst day. An encrypted cloud backup closes it in an evening

Where asambl stands in this

This guide is tool-agnostic on purpose, but it is fair to say where the tool this library documents sits against its own tests. asambl keeps your data in files on your machine: your plans, notes and logs live locally, readable without the app, and backup and export ship as features rather than promises, so the four tests are passed by construction rather than by policy. The fuller statement of what leaves your machine and when, including the honest AI boundary, is its own page, and the same twice-yearly export ritual this guide prescribes applies to asambl exactly as it does to everything else.

That symmetry is the point of the whole practice: a tool that expects to be tested is a tool you can afford to trust, and a reader who tests is one no tool can trap.

Sources

checked 26 July 2026

Attribution and vendor claims checked 26 July 2026.

  • The 3-2-1 rule originates with photographer Peter Krogh's digital asset management work; Backblaze's explainer documents the rule and its 2012 recommendation by US-CERT (Carnegie Mellon).
  • Notion Help, Export your content: the documented caveat that an exported workspace cannot be instantly recreated by re-upload, cited here as the working example of testing what an exit preserves.
  • Syncthing: the open-source peer-to-peer file synchronisation tool named as the no-third-party sync option.
← All guides