From ZeroDrive to ZeroSheet

ZeroDrive began with an idea that was not mine.

It came from my elder brother before I joined my first company, at a time when I had built a few small projects but nothing that asked people to place real trust in my work.

His idea was simple to explain: encrypt a file on the user’s device before it reaches Google Drive. Google should receive only the encrypted version. The key should remain with the user.

He did not have the time to build it. He already had work, projects, and more ideas than he could pursue. He also wanted me to build something substantial enough to help me start my career.

So he gave the idea to me.

The first commit landed in August 2024. I did not know then that the project would follow me through my first job, a security incident, a long beta, a relaunch, and eventually into an entirely different question:

What would encryption look like if the thing being protected was not a file, but a spreadsheet cell?

My first serious project

Before ZeroDrive, most of what I had built felt forgiving. If I made a mistake in a small project, I could fix it and move on.

Encryption did not feel forgiving.

If I made the wrong decision here, somebody could lose access to important files. A privacy tool also makes a promise that most users cannot easily verify for themselves. They have to decide whether the software, and the person building it, deserve their trust.

That responsibility made the project feel different from the beginning.

The first version followed the original idea closely. A file was encrypted locally before it was uploaded. Google Drive stored the encrypted file, and decryption also happened on the user’s device.

The encryption key lived in a separate file. As long as the user kept that key file, the data could be recovered. If the key disappeared, the encrypted data was effectively gone too.

Technically, the design worked. As a product, it left me with a much harder question.

Where was a normal person supposed to keep that key file?

They could not safely put it beside the encrypted files in the same Drive account. Carrying it around on one device made recovery fragile. Asking someone to remember a random encryption key was not realistic.

I had solved the encryption step, but not the human part of encryption.

Twelve words instead of a key file

I started looking at how cryptocurrency wallets approached recovery. They had already dealt with a similar problem: how can a person recover a secret without having to remember a long, random value?

That research led me to mnemonic recovery phrases.

A sequence of twelve ordinary words was easier to write down, store somewhere safe, and verify than a key file with an unfamiliar format. The order still mattered, and losing the phrase still meant losing the data, but it gave the user something they could realistically manage.

I remember finding it and thinking: this is exactly what ZeroDrive needs.

The implementation has become more careful since that early version. The twelve words do not literally divide a file’s AES key into twelve pieces. In the current design, the phrase produces recovery material from which ZeroDrive derives a wrapping key. Every encrypted file still receives its own fresh, random data-encryption key. The recovery-derived key protects that file key, while the file content and its metadata are encrypted separately.

The distinction matters. Reusing one key directly across every file would make the system more fragile. A recovery phrase should unlock the keys that protect a user’s data; it should not become the one key used for every operation.

The phrase made recovery more usable, but it did not remove the responsibility. ZeroDrive cannot reset it. I cannot recover it for someone. That is part of end-to-end encryption: the server has less power, including less power to rescue the user from a lost secret.

The name I almost used

My original name for the project was CryptoDrive.

My brother suggested ZeroDrive instead. It was shorter, more distinctive, and eventually became more appropriate than either of us could have known. The project was moving toward a model where the storage provider needed to know as little as possible about what it was storing.

He reviewed the first version too. Some of the later choices were mine, including turning the interface into something much more minimal, but his influence remained throughout the project. It began with his idea, carried the name he chose, and became the first product through which I learned how much exists between making a feature work and making it trustworthy.

Because it is open source and MIT licensed, nobody has to accept my preferred interface or deployment. They can inspect it, modify it, and run it themselves.

Open source is not automatic proof that software is secure. It does, however, make scrutiny possible, and for a privacy product I think that matters.

A launch almost nobody saw

I launched the early version on Product Hunt.

The response was small. If I remember correctly, it received roughly a dozen upvotes. The GitHub repository reached somewhere in the high teens in stars.

At the time, that felt disappointing. I had spent so much time thinking about the technical work that I assumed releasing it would be the moment people discovered it. Instead, I learned that building and distribution are separate problems. A working product does not explain itself, find its audience, or earn trust on its own.

Later, during a security incident, I made the repository private while I worked through what had happened. When it became public again, the earlier GitHub stars were gone. The number visible today tells almost none of that history.

I wrote about the incident itself separately because it deserves its own story. But it changed how I looked at ZeroDrive. Security stopped being an abstract quality I wanted the product to have. It became something I had to practise across source code, dependencies, publishing, infrastructure, and recovery.

The project stayed alive after that, but parts of it remained in beta for a long time. At one point, even I was no longer using it regularly.

That was an uncomfortable fact about a tool I had built for other people to trust.

The sharing problem

After the basic encryption flow was working, I started looking for the next useful feature.

I opened Google Drive and spent time using its sharing flow. Drive sharing usually means granting another account access to the same stored object. That is useful, but it is different from delivering a separate encrypted package to a recipient.

I began asking whether ZeroDrive could support that second model.

The obvious version would allow one person to send an encrypted file to another. But if I was going to add sharing to ZeroDrive, I wanted it to fit the privacy model of the rest of the product.

That led to a more interesting question:

Could the recipient receive and decrypt a file without ZeroDrive storing who sent it?

Designing anonymity on paper

I first worked through the sharing design with a notebook and pen.

The system needed to know enough to deliver the encrypted package, but it should not need a permanent link between the package and the sender’s account. The recipient needed a way to decrypt it. The sender needed a way to manage or revoke it later. The server should not receive the plaintext file, filename, message, or decryption key.

Once the flow made sense on paper, I discussed it with ChatGPT as a design sounding board. That helped me challenge parts of the idea, but a conversation is not a security review. The real confidence had to come from defining the threat model, implementing the design, and testing the boundaries.

The current flow works like this.

The recipient has a public encryption key that a sender can look up. The corresponding private key remains protected for the recipient and can be recovered using their twelve-word phrase.

When a file is shared, the sender’s browser creates a fresh encryption key and encrypts the file, its name and type, and an optional message. That fresh key is then wrapped for the recipient using the recipient’s public key. The server stores an opaque encrypted package and enough protected metadata to deliver it.

The share record does not contain the sender’s user ID or email address. It also does not need to store the recipient’s email in plaintext. The sender’s browser keeps a separate random management capability that can later be used to manage or revoke the share.

The recipient downloads the package and decrypts it locally.

This is the sense in which the sharing is sender-anonymous: ZeroDrive does not attach the sender’s account identity to the share, and the recipient does not receive that identity unless the sender reveals it in the encrypted message or the file itself.

It is important not to make the claim larger than it is. This is not network anonymity. It does not hide every possible signal from internet providers, hosting infrastructure, or a compromised device. It also does not provide cryptographic proof of who the sender is. It is recipient-only encryption with sender-unlinked application records.

That boundary is less dramatic than saying “completely anonymous,” but it is much more useful because it explains what the system actually protects.

Building the tool I wanted to use

The sharing feature remained in beta while the rest of my life moved forward.

Then, during my first full-time role, I found myself with files I wanted to keep somewhere safer. I did not want their contents exposed to a storage provider, and I wanted access across my own devices.

I had already built a tool for this exact problem, but I was not using it.

That realization changed the way I worked on ZeroDrive. Instead of imagining an abstract user, I started rebuilding it into something I personally wanted to open every day.

I simplified the interface. I improved the upload and recovery flows. I worked on folders, queues, previews, encrypted metadata, cross-device recovery, documentation, and the many small states that turn a demonstration into a usable product.

The minimalist design was partly a matter of taste. It also matched the nature of the product. Encryption software already asks the user to understand unfamiliar concepts. The interface should remove noise rather than add more of it.

The sender-anonymous sharing flow is no longer just an unfinished beta attached to an early experiment. The major product work is complete, and ZeroDrive has been relaunched. What remains now is mostly the work around the product: clearer content, better explanations, and helping the right people understand why it exists.

The source remains public, so the product can be inspected and self-hosted instead of requiring blind trust in my deployment.

The package that changed the direction

At one point, a senior developer I knew wanted to use some of ZeroDrive’s encryption methods in a personal project.

The request exposed a design problem. The cryptography was useful beyond ZeroDrive, but too much of it was tied to the product around it.

So I separated the core encrypted-container work into a reusable package.

That boundary forced me to distinguish between cryptography and product behavior. The package should not know about Google Drive, databases, HTTP requests, or the ZeroDrive interface. It should take data and keys, produce an encrypted container, and reverse that operation when given the correct key material.

What began as a way to help another developer made ZeroDrive cleaner. More importantly, it made the next project possible.

The package is now @zerodrivehq/capsule. ZeroSheet already uses it to protect the backup of one of its private keys.

That is one of the benefits of a package that I did not fully appreciate when I started: a good boundary turns work from one product into a building block for another. It also makes the security-sensitive part smaller, easier to test, and less dependent on whichever storage system happens to sit around it.

From files to cells

For a while, I had a broader idea in the background: what if privacy tools could form an encryption layer over more of the Google products people already use?

For Drive, I had ZeroDrive.

The next place I looked was Google Sheets.

The reason came from watching a sales team at one of my workplaces. They understood their business data and were comfortable organising it in spreadsheets. They were not backend engineers, and they did not need to become backend engineers to test an idea.

With AI tools, they could describe a frontend, provide spreadsheet data, and quickly create something visual around it. That made the visible part of software much more accessible. The less visible part—storing, protecting, and controlling the data—was still difficult.

Google Sheets was already the tool they knew how to operate. It acted as a lightweight data layer for prototypes and internal workflows, even if nobody called it a backend.

That made me wonder whether the useful question was not, “How do I persuade these users to adopt a database?”

Maybe it was, “How do I make the data tool they already understand safer for sensitive values?”

That question became ZeroSheet.

Why encrypting the whole sheet is not enough

Encrypting a spreadsheet as one file would be relatively straightforward. ZeroDrive can already encrypt files.

It would also destroy most of what makes a spreadsheet useful.

People need to open it as a grid, change a cell, sort a table, filter a column, and work with formulas. If the entire document is one encrypted blob, none of those interactions can happen until it is downloaded and decrypted as a whole.

ZeroSheet takes a different approach: selective encryption inside the sheet.

Imagine a sheet containing names, roles, regions, and salaries. The first three columns might be safe to leave readable for an existing workflow, while the salary column should remain protected. A user could choose that column, a group of cells, or eventually an entire sheet and encrypt only that range.

Google Sheets would store ciphertext in those protected cells. Someone opening the document in the normal Google Sheets interface could still see the unprotected columns, but the protected values would look like encrypted data.

An authorised user would open the same workbook through ZeroSheet. The protected values would be decrypted in the browser, used inside the local spreadsheet editor, and encrypted again before changes were written back.

This creates an unavoidable tradeoff. Google cannot search, sort, calculate, chart, or filter values it cannot decrypt. Those operations have to happen locally inside ZeroSheet for protected data. Encryption can reduce what the storage provider learns, but it cannot preserve every server-side feature as if the values were still plaintext.

That limitation is not an implementation detail to hide. It is part of the product.

What ZeroSheet protects today

ZeroSheet is not finished. It is currently a technical alpha and a place where several parts of the architecture are still being tested.

The current cryptographic model encrypts protected cells independently. Each cell receives a fresh nonce, and its encrypted value is tied to its workbook, sheet, row, column, and key version. That binding is important: copying ciphertext from one protected location into another should not silently turn it into a valid value somewhere it was never meant to be.

The design supports different spreadsheet value types, including numbers, booleans, text, formulas, and blank protected cells. It also includes early work on sharing workbook access and recovering the private keys used by the system.

The editor is still a local technical preview. Some flows use temporary in-memory key material. Synchronisation has a limited working range, and conflict protection around Google Sheets cannot yet make every check-and-write operation atomic.

There is another important access-control limit in the current architecture. A workbook presently has one workbook key. If a person is authorised to decrypt that key in ZeroSheet, they can decrypt all protected cells in that workbook. Selectively hiding different encrypted columns from different authorised ZeroSheet users would require separate keys for those ranges and a more detailed sharing model.

The salary example works today when the goal is to hide selected values from Google and from people who only view the native sheet. It should not yet be described as field-level permission between multiple ZeroSheet users.

Those details make the project sound rough because it is rough. I would rather describe that state accurately than write about the final product as if it already exists.

A product and a classroom

Both projects have become places where I learn by putting ideas under real pressure.

ZeroDrive currently runs in containers. I understand the concepts behind Kubernetes, but I have not yet operated the project through it in the way I want. My current work gives me a reason to understand that layer more deeply, so ZeroDrive is becoming the environment where I can practise it on a system I know from top to bottom.

ZeroSheet is doing something similar for enterprise identity and access management. I am exploring policy engines, workload identity, lifecycle controls, and auditability because encrypted data is only one part of the problem. A real organisation also needs to answer who should receive a key, under which policy, for how long, and what happens when access changes.

Not every enterprise component belongs in the smallest useful ZeroSheet release. Some of the current architecture is intentionally there because I want to learn it. Keeping that distinction visible helps me avoid presenting an experiment as a requirement.

This is one reason personal projects remain valuable to me. They allow learning to become concrete. A concept stops being a diagram when it has to survive deployment, recovery, failure, and an actual user’s expectations.

Showing the unfinished work

For a long time, my instinct was to wait until a project was finished before talking about it.

ZeroDrive showed me the weakness in that approach. I built a large part of it quietly, launched it, and then discovered that very few people knew the problem, the decisions, or the story behind it. The finished code could not communicate those things on its own.

Reading Show Your Work! has pushed me to think differently about that. The process is already worth sharing while the project is being planned, tested, and changed.

That is what I want to do with ZeroSheet.

The blog can hold the longer explanations: the threat model, the failures, the architectural decisions, and the reasons a feature changed. Posts on X can capture the smaller steps as they happen—a working cell-encryption flow, an access-control question, a UI decision, or something I learned while an idea was still incomplete.

Building in public does not require pretending that every unfinished experiment is a product announcement. It can simply mean leaving an honest trail of the work.

What one idea became

ZeroDrive started because my brother gave me an idea he did not have time to build.

At first, I thought my job was to implement that idea: encrypt a file locally, upload the encrypted version to Google Drive, and let the user keep the key.

But every answer created another question.

How should a person recover a key? That led to twelve words.

What does file sharing mean when the storage provider should not read the file? That led to recipient-only encryption and sender-unlinked sharing.

How could the cryptography be useful outside one product? That led to a package.

What happens when the thing people already use is not a folder, but a spreadsheet? That led to ZeroSheet.

The project helped me begin my career, but its larger value has been teaching me how products evolve. They do not always begin with a grand plan. Sometimes they begin with somebody else’s unfinished idea, one problem that feels worth solving, and the willingness to keep following the next honest question.

ZeroSheet is the next question.