I see that you outline the design of the API within the execution environment, but not yet how this will be expressed on the level of the System API towards the actual Wasm canisters. Is there a design for that as well already? Will it be new synchronous Wasm calls? If so, how will the data be represented as Wasm types? Or will the functionality be exposed using the virtual management canister (same as secure randomness and ECDSA signatures)? If so, can you give the candid interface of that? Or is that simply future engineering work?
2 Likes
The current plan is to expose the functionality using the virtual management canister; however, there is no firm decision on that. And yes, figuring out the most suitable candid interface is part of future engineering work.
2 Likes
I suggest that you ask this question in the Threshold ECDSA Signatures thread.
If there is a trace proving that multiple node providers colluded, their nodes could be removed (via NNS voting).
2 Likes
Good question! While there is a lot of interest in this integration, weâd love to hear more from the community what functionality they would use personally or build applications around.
Please feel free to drop ideas and wishes right here in the forum!
6 Likes
Iâm most excited for an all-in-one crypto wallet that can hold BTC, ETH, other Ethereum tokens, ICP, and other IC tokens. This wallet will be integrated with Internet Identity, and will have advanced features like social recovery and other features that are impractical to do on decentralized blockchains currently because of their computational cost.
I probably wonât build this, but I hope someone else does.
17 Likes
NNS Motion Proposal for BTC Integration is live!:
5 Likes
I am getting worried about the security of canisters running on non-system subnets, that hold large amounts of monetary value.
Iâm not sure enough security precautions have been taken to feel confident that canisters running alongside possibly malicious canisters will be safe.
I did not realize that each canister was running within the same process on each replica within a subnet, at least that seems to be the case.
Perhaps a prerequisite to this project moving forward is process sandboxing, so that even if malicious canisters break out of the Wasm environment, theyâll be stopped by the process boundary.
See here for more information: Enable Canisters to Hold ICP - #30 by lastmjs
11 Likes
Can you clarify what you mean by each canister running within the same process on each replica within a subnet? By definition, arenât canisters running in different processes since they are running on different machines/replicas?
2 Likes
The security concerns you refer to are indeed something we are concerned about as well.
We have a feature on our roadmap that is concerned with protection against WASM jailbreaks. I.e., the execution of WASM code for a canister will be sandboxed in the future inside a separate OS process. This will, for example, be important to better protect high-value smart contract canisters.
But thereâs more to the security in the domain of Bitcoin integration: Think of âBitcoin blocksâ that are specially crafted messages by an attacker and served to us from an attackerâs Bitcoin node we connect to and the attacker trying to mount an attack by exploiting a flaw in our Bitcoin block parsing code. This is something we are currently planning to protect against as well by sandboxing code that touches untrusted input, e.g., parsing of Bitcoin blocks, such that we mitigate much of the risk coming from untrusted content. Our networking architecture for the Bitcoin integration currently foresees that we sandbox the Bitcoin protocol logic including parsing code to mitigate the aforementioned risk.
Does that answer your question?
5 Likes
By definition, arenât canisters running in different processes since they are running on different machines/replicas?
Indeed, each replica deterministically executes canister code as governed by Consensus and Message Routing. This ensures that on each machine we perform the same computations and go through the same state change in each round. This is the basic behaviour of the Internet Computer.
What @lastmjs means is that different canisters within a replica are executed by the same OS-level process of the replica, which is currently true. This would be something our canister sandboxing feature will change in the future to better isolate canisters from each other.
4 Likes
An acknowledgement that my thinking is generally correct is great!
My next question would be, how long will canister process sandboxing take, and what do you think about making that a pre-requisite to deploying the Bitcoin integration?
And the extra insight on the Bitcoin block processing sandbox is very interesting, thanks for that information.
3 Likes
Holy crap, I didnât know that. That definitely sounds like a potential security risk. Where is this documented, if anywhere?
1 Like
I agree with @lastmjs that this (just the potential of a wasm jail-break)is a significant serious security issue for EXISTING dapps on IC.
For example :
The NFT Cronic Critters have an average value of about 10 icp for about 600 odd critters today based on sale listing after removing the ridiculously priced critters from the average calculation. There are roughly 5000 critters currently in existence. These are worth 5000x10 = 50,000 icp. At current approx $60/ICP , this is roughly $3M USD at risk in ONE nft type. Isolating canister executing in a sandbox would substantially reduce the risk; even if there are no known instances of WASM jail breaks.
It will only take one successful jail-break to completely erase trust from the community that we have tried, so assiduously, to cultivate. I would anticipate that TODAY we have close to $30 m in just NFT assets that are under risk. This estimate is based on the ROM of 10 different NFTs that are estimated to be on the IC today.
While arguments could be made to say that we have never seen an jail-break successfully occur in the wild, the amount of money is sufficiently large that it will attract hackers. I would think that securing canister execution should BE AT THE TOP of the priorities.
7 Likes
Thanks for the analysis! I guess one could rephrase your post as âthere is a community driven bug hunting bounty program in place, with a bounty of ul to 30M$. As of today, the bounty was not claimed, which is a testament of how secure the IC isâ 
(Oh, and BTW, your browser runs untrusted Wasm in process. If someone has a jailbreak for the Wasm sandbox, at least if it also works in browser, they can get much more there, I assume.)
1 Like
I feel like the honeypots created by canisters are much larger than you would find by breaking out of the Wasm sandbox in most web apps (the web app is just the frontend, not the actual server where a bank account is managed). And each application (tab) in the browser has a Wasm sandbox, and that sandbox is also sandboxed within its own process. Weâre pointing out that the IC does not meet the standard of the browser. If all of your tabs and domains shared the same process, that would be more equivalent.
Itâs also only been a few months since the value inside of canisters started accruing, so not much time to feel too comfortable.
I think it comes down to this: there is an obvious vulnerability with an obvious solution, and we should make implementing that solution a priority.
9 Likes
Iâve voted no on this proposal mostly to make a point about security. If there is an obvious vulnerability that could lead to catastrophe, and an obvious solution, I think the priority should be to patch that vulnerability.
I would like to see canister sandboxing per process before deploying these features.
The same sentiment is reflected in this proposal: Enable Canisters to Hold ICP - #75 by lastmjs
10 Likes
I think that is a very commendable and engaging way to show your classic well-earned reputation for clarity of thought
5 Likes
I am bitcoin hodler from 2013 and very early supporter of dfinity since 2018 i truly support them. My Vote is YES
3 Likes
Thanks for such ringing endorsement!
1 Like
It nearly did make it itâs post. (âAn inadvertent community driven bug hunting bounty program for ICâ). I will articulate why I did not make it itâs own post with all the rationale here (as opposed to a provocative new post).
At first, an free airdrop doesnât really cost end users any real money. As the NFTs begin to percolate the eco-system, people begin to pay real currency for acquiring NFTs. For example, i got a free nft (starverse) for my participation on dscvr.one. At the beginning, on the entrepot.app, the lowest price of one of those nfts was around 0.8 icp. Currently the lowest price is 1.89. Doubling of the price from nothing. This begins to cause a sense of entitlement (âitâs mineâŚI own itâ) for the average end-user. Imagine if they log into the account one fine day and they donât see that NFT. This causes anger, fury etc. They will begin to blame someone else (nobody buys the argumentâŚâbut it was betaâ). They have lost something of value.
All participants do understand that crypto is inherently risky. But they also expect that reasonable protection be afforded to them on any platform. An ICAntagonist can make significant noise. i.e. " oh that dfinity foundationâŚ200 cryptographersâŚand they FORGOT to put in basic sandboxing that WE have known for yearsâŚ". Unfortunately logic (the fact that we have it in the roadmap) cross raw emotion and logic, in that case, has no chance. It can cause a catastrophic cascade with the right shills.
The reason that my articulation is here as opposed to top level is that most people will not bother to read a post 50 levels buried. But concerned discerning teams will⌠and hopefully take action as appropriate.
2 Likes