The Internet Computer Blockchain’s Privacy Advantages
How canister smart contracts on the Internet Computer protect the privacy of end users better than on the traditional web.
By Jens Groth, Director of Research | DFINITY
Online privacy is about shielding you from outside intrusion, whether this involves data usage restrictions, unwanted advertising, surveillance and tracking, or protection from abuses. This principle is central to the Internet Computer blockchain, where users interact with canister smart contracts that developers have created and deployed to run decentralized applications (dapps), DeFi platforms, NFTs, websites, and tokenized internet services directly on the open web.
Anyone can develop and deploy a canister on the Internet Computer — and a developer’s intentions may range from privacy-conscious to intrusive. This article explains the privacy bounds under which canisters operate, and how they provide better protection for end users than on the traditional web. It also describes the underlying Internet Computer architecture and its implications for privacy.
Application layer privacy
We’ll first discuss the privacy offered on the application layer by the standard canister interfaces. Developers can launch dapps in the form of canisters on the Internet Computer. Users can use software to interact with canisters through query calls, which are processed in milliseconds, and update calls, which can take a few seconds. A query call allows your software to read from a canister — you can, for example, query for your latest received messages on OpenChat or read another user’s profile on Distrikt. A query call cannot change state on a canister though, which means the canister cannot store any information about your request. Developers can offer arbitrary read-only interfaces on their canister allowing you to do sophisticated data processing, but the canister does not recall any information from your query. It does not even know that it has processed your query.
To store something in a canister, your software must make an update call. When you send a message on OpenChat or update your profile on Distrikt, the information has to be stored in the relevant canister such that it can be displayed to other users. Canisters differ in how they process data. A canister could, in principle, record all update calls you send to it and sell your update call history to third parties.
One way that data collection is counteracted is through pseudonymity. An update call has a sender identifier — a principal. If the canister permits it, you can connect using a special anonymous principal. In this case, the canister does not learn who sent the request. If a canister requires a sender principal, you may have a principal you use just to interact with this canister such that it cannot be easily linked to your interactions with other canisters.
Internet Identity is a cryptographic authentication system that provides pseudonymous principals. Internet Identity applies a pseudorandom function seeded with a salt to create a distinct principal on your behalf for each application you use it to authenticate in to. For someone who does not know the salt (whose security is discussed in the platform privacy section below), the principals are unlinkable to each other. Canisters can of course track multiple accesses with the same sender principal, and may from the payloads themselves and timing of update calls learn information about you, but compared to software on the traditional web, they are more restricted in what they can do.
Implicitly, we trust user software to issue query calls and update calls as appropriate. The Internet Computer Interface Specification details the interface to canisters, and anyone can write software to interact with the Internet Computer. If the software you use circumvents your privacy, the Internet Computer cannot fix that. Now, the software may not be independent of the canister you are using, the developer may have provided it to facilitate interaction with her canisters. Indeed, if you access the Internet Computer through your browser, usually you will access a canister through a front end provided by the dapp itself. A malicious front end could try to issue update calls instead of query calls to leak information to a canister; it could also leak information to the canister through the payloads or transmit it directly to a third party. But compared to the traditional web, such attacks may be harder to disguise. Since query calls are usually processed within milliseconds, while update calls may take a few seconds, replacing one with the other results in significant timing differences. Leakage to third parties could be detected by monitoring the communication pattern. The best solution is to use honest software in the first place, and as described below, it is easier than on the traditional web to verify that software delivered from the Internet Computer is correct.
As the Internet Computer grows more sophisticated, we expect transparency to increase. One option is verifiable builds of canisters. Canisters are provided by developers in the form of WebAssembly (Wasm) modules. Deterministic compilers can link the Wasm module directly to the original source code. Inspection of the source code of a verifiably built canister makes it possible to see exactly how data is processed, as well as what information the canister shares with other canisters and users. Since canisters execute deterministically on the Internet Computer, we may also get guarantees about what they serve to users, e.g., that the front end they serve to users accessing them through browsers is benign. Even if some canisters do not want to disclose their source code, there may be help on the way. For instance, there may be verifiably built canisters that offer privacy protection as a service and act as an intermediary between users and closed source canisters to guarantee your privacy. Internet Identity can be seen as an example of a privacy-protection service, offering access to other canisters via a pseudonymous principal.
Platform privacy
Looking beneath the application layer where canisters are running, we must also understand the privacy implications of the platform itself. The Internet Computer is running a decentralized network, where data and computation is replicated across nodes in data centers located around the world. This decentralized structure is good from an availability and integrity perspective. The ability to process data and to guarantee correct processing comes from this decentralized architecture. Another salient decentralization feature is that ICP token holders vote on proposed changes to the Internet Computer network by staking tokens in voting neurons within the Network Nervous System. Changes to the Internet Computer can be publicly reviewed, scrutinized, and discussed before they are adopted or rejected by the community, and voters are incentivized to support changes that increase user demand and satisfaction.
The question that remains centers on confidentiality. In its current design, the Internet Computer consists of a decentralized core run by a diverse set of nodes. To protect the core against denial-of-service attacks and to route user messages to the right canisters, communication with the Internet Computer relies on a set of boundary nodes. Those boundary nodes can see, for example, the IP address of the sending user, as well as which canister the user is sending it to and the payload. (All communication to the Internet Computer and within it is encrypted, but the boundary nodes decrypt incoming traffic and then re-encrypt it.) In the future we expect a decentralized boundary node structure to guarantee availability and, for example, use onion routing to maintain confidentiality of user data.
We now turn our attention to the core of the Internet Computer, where the replicated computation takes place. Since data is replicated across multiple nodes, with each node owned by a distinct node provider and independent of the others, there is a risk that one of them is malicious and may try to sell user data to third parties or otherwise abuse the data. We are currently working on two strategies that the Internet Computer can use for confidential data processing: hardware-supported confidentiality and secure multi-party computation.
Hardware manufacturers are developing secure enclaves to provide isolated computing environments. A key goal is to protect user data in the cloud. In cloud computing, hypervisors allocate computation from users to separate virtual machines. In traditional cloud computing the cloud provider has full access to all data. Placing virtual machines inside secure enclaves reduces this risk. The most recent solutions in this space, such as AMD’s Secure Encrypted Virtualization (SEV), provide attestation guarantees that a piece of code is running inside a secure enclave, and confidentiality through encryption of memory and registers. The Internet Computer can require nodes to run replicas inside secure enclaves, which restricts even malicious node providers from accessing user data. The community will need to decide, however, whether to trust only one hardware manufacturer or to use hardware-based security solutions from multiple vendors, at the risk of potentially leaking data if just one of them is flawed.
We believe that hardware-based confidentiality will suffice for many users. But for highly sensitive data — key material, for example — we envision secure multi-party computation as a service on the Internet Computer. Secure multi-party computation offers integrity, availability, and also confidentiality when a supermajority of nodes are honest. In this approach, security is not based on hardware assumptions, it is instead baked into the secure multi-party computation protocol and achieved collaboratively. Not only is hardware diversity tolerated, but it even strengthens the privacy guarantees. The downside of secure multi-party computation is a large efficiency overhead. We therefore expect the two solutions to co-exist: for very sensitive data, canisters can use a secure multi-party computation service offered by the Internet Computer, while for private but not critical data, they will want to run on subnets with secure enclaves.
____
