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 change history and audit trail? This became realistic about ten years ago when WebAssembly arrived in browsers, making it possible to run software there that was never written for the web. I ported libgit2 — the same Git engine that powers GitHub.com and Azure DevOps in production — to WebAssembly, and started the project wasm-git back in 2020. It is published as a library that anyone can use, and has since gathered a steady following of developers on GitHub.

Wasm-git is a library that a web application can include to store user data on the user's own machine. Using Git's features — merge, push and pull — the data can be backed up to other locations, complete with the change history, recorded as log entries called "commits". The application doesn't need to expose any of this terminology: a single "synchronize data" 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.

Private, even in the cloud

Normally, Git repositories are synchronized to cloud servers, mainly to make collaboration easy. That works for open source code — but for personal, sensitive data, we need more: the data must be encrypted before it leaves your computer, with keys that only you hold, so that not even the cloud operator can read it.

For this I created an addon to wasm-git in the encrypted-git-storage project. In the web application, it encrypts and decrypts everything locally in the browser (AES-256-GCM, with a key that only the user holds) — the server only ever receives ciphertext and can decrypt nothing. There is also a companion addon for the regular Git command-line client, so you can clone your own application data — decrypted, with full history — straight to your computer's file system and work with it using any tool you like.

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. With self-custody of your 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 protocol blockchain. It uses wasm-git to store your portfolio data, 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. Like on most blockchains, transactions on NEAR have traditionally been public for anyone to look up, but that recently changed with the introduction of Confidential Intents, powered by a NEAR "private shard" — a restricted-visibility execution environment running alongside the public NEAR blockchain, connected to it through a bridge secured by Trusted Execution Environments. Confidential balances and transaction history are encrypted with the account owner's own key, so only the holder of the account's keys can see them. With transaction data itself becoming confidential for those who opt in, it was only natural that Ariz-Portfolio's optional cloud synchronization got the same treatment: the Git repository is encrypted before upload, and even though the data rests in a cloud service, the keys stay in the custody of the user.

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?