We’re excited to announce that the Internet Computer (IC) now allows users to have more insight into a canister’s history, both in terms of which code has been running and who deployed this code. To achieve this, the IC tracks a canister’s history of deployed canister Wasm module hashes and controller changes.
This feature provides a new audit trail that can, for example, be helpful for users in the following use cases.
- A user of a canister can verify that a canister’s controller does not maliciously change the canister’s code. Let’s take as an example a malicious canister controller that tampers with the code by deploying a malicious Wasm module (e.g., with a backdoor) and shortly after redeploys the original Wasm module. If a user checked the Wasm module hash before and after this “attack”, the user would not see anything suspicious. With the newly available canister history, the user can detect such behavior as the user would see in the canister history that a different Wasm module was installed for a while.
- A user of a canister can verify that a canister’s controller does not maliciously change the canister’s controllers. Let’s take as an example a malicious canister controller that deploys a malicious Wasm module (e.g., with a backdoor) and then sets the NNS governance canister as the new controller of the canister. If a user checked the current set of controllers, the user would only see the NNS governance canister as the single controller and could thus believe that the canister’s code is trustworthy. With the newly available canister history, the user can detect such behavior as the user would see in the canister history who deployed the current canister’s code and that the controllers were changed afterwards.
A concrete example of how to get and interpret the canister history is available in the “canister-info” sample dapp.
The relevant replica code change to enable this feature was approved and released by the NNS DAO in proposal 122617.
The canister history information is available via inter-canister calls to the
canister_info method of the management canister taking a canister id as argument. Please refer to the Interface specification for more details including the precise types. The above mentioned example might also be helpful to understand the details.
The canister history stores the 20 latest relevant changes, which include canister creation, Wasm module installations, reinstallations, upgrades, and uninstallations, as well as changes to the canister’s controllers. Note that the canister history only stores the changes that happened after the feature has been rolled out (since 2023-06-05, 9:47:46 AM UTC, on all subnets).
The fact that only the 20 latest relevant changes are stored means that the canister history cannot be used for auditing canisters that are subject to many changes within a short period of time, as changes beyond the limit will be dropped from the history, and thus no longer traceable. However, this is not expected to be a practical issue because the changes can be periodically fetched and stored in a dedicated canister.
We hope that you find this new feature useful.
If you have any questions or feedback, please drop a line in this thread!