Any node on the IC (any of the 13 nodes) can make your data public
The expectation has to be logical and physical, otherwise it is just fantasy.
1 Like
Is there a technical possibility of having at least the same level of privacy as AWS? Or is that impossible for a blockchain?
1 Like
Would you rather keep your withdrawal password with a friend you know (Amazon), or a copy with 13 strangers each (Blockchain)?
Of course, the best privacy protection is to keep the withdrawal password in your own hands.
1 Like
The last option seems like a application design problem, or am I seeing it wrong? Is it possible to create a very secure and private app on the ICP if the dApp is created with those properties in mind?
Oh, and do all of the 13 friends have the whole password or only a small part of it?
We are in the initial stages of CI, those 13 nodes will be followed by many more, each time increasing decentralization, security and CI capacity. making AWS or Big Tech obsolete. That’s on the IC roadmap.
Don’t you see the potential for IC to become the world’s decentralized computer? That takes vision, hard work and time.
look but at Bitcoin in its first transactions, how it grew, generating more and more security and decentralization.
As long as the problems encountered are technically fixable, we are good.
1 Like
a copy of whole password!
YES! To build a dapp on the blockchain, the business must be designed rationally and the developer is the first responsible person. There are things you can’t blame IC. IC is blockchain, it can’t help you do what blockchain can’t do. It’s not something that can be solved by upgrading and optimizing, it’s in its DNA.
This is not an escalating relationship. It’s a single choice question, if you choose A, you can’t choose B. Innovation can’t violate logic and you can’t violate the laws of physics. You can learn more about the basics related to blockchain and Dapp on Google. The main function of this forum is not to spread the basics.
1 Like
Actually is perfectly feasible to implement B2B applications because you can always deploy a subnet dedicated to aparticular business withn a node provider owned or controlled by the same business.
1 Like
This way Amazon, Microsoft, IBM are doing very well already, they also have distributed architecture, and the cost is not expensive. Why are you coming to IC?
If a subnet is controlled by a single company (or a group of affiliates), that’s a failure of NNS governance!
1 Like
The implementation of business services within a propietary network driven by a IC protocol would provide native fault tolerance and tamper proof extremely hard to achieve starting from a AWS infrastructure. Supervisory control and data acquisition systems in charge of critical infrastructures like the electric grid and other civil critical infrastructures will soon require this extra reliability and security. I leave it to you to extra polate from that example other business use cases
Within the context of a private business, where services are provided uniquely to internal stake holders, it makes perfect sense to that this node provider is fully controlled by this single private business
3 Likes
By the way. Let’s get back on topic.
If IC’s subnet doesn’t open up data, then IC’s reliability and tamper-proofness is about as good as Amazon! Not even close to Amazon in terms of privacy protection! So would you still choose IC?
How do you feel when faced with this fact?
That is Consortium Blockchain. I recommend you to check out the Hyperledger project. Reliability and TPS are far better than IC. you have better options.
First, it’s clear from the previous discussion that you now decided to ignore, that IC protocol is a suitable candidate as a native framework to implement propietary business applications.
Now, let’s go back to the new topic, public subnets. Yes, I agree that some subnets should give access to their blocks so everyone can validate past transactions. I wrote “some” because in some orther cases users and service providers would still want to keep this information private. So, In the case of private sub network, the question is how private it is? well, now it is not because node providers can access it but eventually it could become fully private with adequate protocol updates
Do you mind to elaborate?
1 Like
If Amazon says that complete privacy is possible with a protocol upgrade. Do you believe it?
If you don’t believe Amazon, why can you trust IC to achieve privacy through protocol upgrades? The truth is, no matter what IC does, it’s just less private than Amazon! Without making subnet data public, IC is doing almost the same thing as Amazon! Accept this frustrating fact.
Ok, again you changed topic but whatever let’s go:
Amazon would never ever publish their code and give proof that the running code corresponds to the expected one. On the other hand, the Internet Computer protocol adhere to open source principles.
1 Like
If the subnets don’t open their data, you can’t prove that each node is running the same program that is open source. You can’t verify it! You can only comfortably believe that they are running open source code.
This is why I insist on making the subnet data public.
1 Like
Oh boy, your circular topic change is something:
This one is correct, and I already agreed and agree once more that some subnets should provide access to the blocks they generate. Even more in the case of DEX and DEFI applications like yours.
3 Likes
Once the subnet makes data public, IC will lose the privacy data protection you expect (in fact, IC has no protection for non-encrypted data since the beginning, and every node can leak your data). You can’t use IC the same way you use Amazon.
1 Like
How do you verify that the node provider is running the software as expected? Unless they open the block data and let community full nodes verify it. Even tho the code is open sourced, how do you verify the node provider’s software. Same as you can’t verify AWS even they claiming they are running the open sourced linux
You are confused, Dfinity has never said your canister state data is private. Therefore, there should not exist such expectation.
1 Like