Who really controls your data? Bringing Git to web apps

Ever since I started using web applications that store my data on someone else's servers, two things have bothered me: I can't easily keep my own backups, and the people operating the service can look at my data. Over the years I've been working on ways to give that control back to the user — and my main contribution is to take the tool that software developers use to protect their most valuable work, and use it for your data in web apps.

Your data, with full history

Imagine that every app you use kept a complete journal of your data: every change recorded, the ability to look at how things stood at any point in time, a backup on your own computer that is truly yours, and synchronization between your devices whenever you want it. Not a snapshot taken once a night — a running history of every single change.

Software developers have had exactly this for decades. The tool is called Git, and it is how the world's source code is tracked, backed up and synchronized. Git keeps track of changes in text files over time, and lets you keep multiple copies in different places that can be synchronized at any moment — not just the latest state, but every change made since the last sync. And here is the thing: source code is text, and web application data is, to a large extent, text too.

So my idea was simple: why not run Git in the browser, on the user's own computer, and use it to store and synchronize application data — including the full history of every change? This became realistic nearly ten years ago when WebAssembly arrived in browsers, making it possible to run software there that was never written for the web. I ported the engine behind Git to the browser and started the project wasm-git back in 2020. It is open source, anyone can build on it, and it has since gathered a steady following of developers.

With wasm-git, a web application can keep your data on your own device, and use Git to back it up to other places, complete with the history of every change. The application doesn't need to show you any of this: a single "synchronize" button can do all of it behind the scenes. But as we will see, some understanding is still asked of the user — giving people control of their data is hard without also giving them some responsibility for it.

What this means in everyday use

Keeping the data on your own device, rather than only on a server somewhere, changes a few everyday things.

It works without an internet connection. The app reads and writes a copy that lives on your device, so you can keep working on the train or on a plane, and synchronize when you are back online. Anything that needs the network — such as fetching new transactions from a blockchain — has to wait, but reviewing and editing what you already have does not.

It works across your devices. Make changes on your phone, and pull them down to your laptop when you want them. Because every change is recorded, the two copies can be brought back in step even if you have used both in the meantime.

You can look back, and you can undo. Since the full history is kept, you can see what your data looked like last month, or recover something you deleted by mistake.

The app can disappear, and you keep everything. Services get shut down, bought up, or change their terms. If your data only lives in their database, it goes with them. If it lives on your device, in a standard format that many other tools can read, it stays with you.

And it is your legal right. In Europe, the GDPR gives you the right to receive a copy of your data from any service, in a form you can take elsewhere. Most services meet this with a "download your data" button that produces a one-off export. Here the export is not a special feature — it is simply how the app works.

Private, even in the cloud

A copy on your own device is good, but most of us also want a copy in the cloud — as a backup, and to reach the same data from several devices. Normally, Git repositories are synchronized to cloud services built for sharing code, and that is fine for open source. For personal, sensitive data we need more: the data must be encrypted before it leaves your device, with keys that only you hold, so that not even the cloud operator can read it.

For this I created an addition to wasm-git, the encrypted-git-storage project. Everything is encrypted and decrypted on your device, inside the browser, with a key that only you have. The server only ever stores scrambled data that it cannot read. There is also a companion tool for the regular Git software that developers use, so you can fetch your own application data — decrypted, with full history — straight to a folder on your computer and work with it using any tool you like.

Diagram: the Ariz-Portfolio web app in the browser uses wasm-git and encrypted-git-storage to encrypt data locally, pushing encrypted Git packfiles to ariz-gateway which stores them in Tigris object storage. A native Git client with the encrypted-git-storage remote helper can clone and sync the same data, decrypted locally.

The catch: the keys are yours

This is where responsibility enters the picture. If the keys are lost, the data cannot be recovered — by anyone. If the keys leak, whoever holds them can read the data. Keeping keys safe is much the same discipline as protecting the passwords to your online bank, your email or your iCloud account. But there is one important difference: those operators can usually help you if you lose access or make a mistake. When you hold the keys to your own data, you have also cut off the possibility for anyone to rescue you. That is the price of privacy in its strongest form — where not even the application operator can access or recover your data.

"Not your keys, not your coins"

If you have listened to any of the many podcasts about investing in Bitcoin and other crypto assets, you have probably heard that phrase. It is exactly the same trade-off. Keep your crypto on an exchange, and you are trusting a custodian — they can help you if you forget your password, but you depend on them staying honest and solvent. Hold your own keys, and nobody can freeze or take your assets — but nobody can help you if the keys are lost, either. Many people invest today without ever thinking about who actually controls the keys to their funds. Maybe letting a custodian handle it is the right choice for most people — but it should be a conscious choice, not an accident. And the very same question applies to all the other data you keep online.

This is not just theory for me. One of the real-world uses of wasm-git is Ariz-Portfolio, an application for tracking crypto asset balances, profits and losses on the NEAR blockchain. It keeps your portfolio data with wasm-git, and lets you download a copy — with the full change history — to your own computer, whether just as a backup or to process it with other tools. Transactions on most blockchains, NEAR included, have traditionally been public for anyone to look up. That recently changed with NEAR's Confidential Intents, where balances and transaction history are encrypted with the account owner's own key, so only the account holder can see them. With the transactions themselves becoming confidential, it was only natural that Ariz-Portfolio's optional cloud synchronization got the same treatment: the data is encrypted before upload, and even though it rests in a cloud service, the keys stay with you.

Can we ask this of users?

Web design today focuses on hiding complexity — ideally the user should never have to learn anything new. But data custody, like handling money, is something worth learning. Maybe most people are best served by trusted custodians, for their funds and for their data alike. Maybe not. I honestly don't know where the line goes — but I believe the choice should exist, and that it should be made consciously. Are we able to require that responsibility and understanding from web application users?