What a cloud node knows about you

Your assistant needs more compute than your home node has free, so a job goes out to the cloud. It might run in a large provider’s region, or on a machine in a stranger’s flat three cities away. Either way, for a few minutes, a computer you will never see is working on something of yours.

What does the owner of that computer learn about you? Most people answer with the content: “they can read my data unless it is encrypted”. That is the smallest part of the answer.

The real cause: the cloud needs to know who you are

An ordinary cloud identifies its customers because its business depends on it. Billing needs a name and a card. Abuse prevention needs an account to suspend. Support needs a history to look up. Compliance needs records kept for years. Each reason is sensible on its own. Together they mean that every job you run sits next to your identity, and anything that sits next to your identity can be linked to it.

Encryption protects the content in transit and, with more effort, at rest. It does nothing about the paperwork around the work.

What leaks even when the content is encrypted

The account. The job is tied to a user, and the user to a person. Whoever can read the account can attribute every job to you.

The payment. A card, a bank account or a wallet address links the work to a legal identity, often more reliably than the account does.

The metadata. When the job ran, how long it took, how much it moved, where it came from. Patterns in metadata reveal a great deal: a job that starts at the same hour every working day says something about your routine without anyone reading a byte of it.

The logs. Debugging, billing and security logs outlive the job by months or years, and they are copied to places the job itself never went.

The operator who can look. Whoever has full control of the host can, in principle, inspect memory while the work runs. Policies say they will not. The architecture usually says they could.

What a node should know instead

KyberFusion is built to be anonymous. That is a design goal, not a claim, and the honest way to describe it is as a list of what a node in the network should and should not see.

Work, not a person. A job arrives as a sealed cell: encrypted, with its files and processes fixed when it was created and a network that is closed except for what the work needs. The node sees a cell, a class of work and a time budget. The anatomy of that cell is in KyberCell explained, and the system that enforces it on every node is described in the same OS in the cloud.

Settlement, not an account. The network records that capacity was used and settles it in tokens on a shared ledger. The aim of the design is a record that proves the work was paid for without saying who asked for it.

Less to begin with. The best-protected data is the data that never left. Your assistant decides what a job actually needs and strips the rest before anything goes out, and whether a job should leave the device at all is the subject of where a swarm should run.

Logs that belong to the work. Every step a cell takes is recorded as a trajectory, but the record travels back with the result, to you, instead of piling up on the node.

No data business behind it. There is no advertising and no data sale anywhere in the ecosystem, so there is no internal reason to collect what the design avoids collecting.

The honest limits

Anonymity against a determined observer is hard, and it is easy to overclaim. Traffic patterns can be correlated. Hardware that runs someone else’s work can be attacked. Abuse has to be dealt with somehow in a network that does not know who its users are, and every answer to that question costs some anonymity. We will publish the method alongside any result. Until it has been tested, we will not call the network anonymous; we will say it is built to be.

A test you can run today

Pick one cloud service you use for work and ask it for a copy of the data it holds about you. In the EU the GDPR gives you the right to request it, and most services have a form or a download page for exactly this.

When it arrives, ignore the content you uploaded and count everything else: logins, IP addresses, device identifiers, timestamps, billing records, support tickets. That second list is what a node, a provider or anyone with access to them knows about you beyond your work. The KyberFusion homepage describes the network we are building to keep that list short.