100%. And I do think the NNS subnet is the most natural starting point, especially because it plays such a crucial role in the IC, so for verifiability you’d probably want to start verifying the NNS first.
7 Likes
I agree as long as it can be done in a way that user data will still remain private.
There are inherent limitations to the use of blockchain. If you put private data directly on the chain, you can’t count on a gatekeeper to keep your privacy for you. Is that gatekeeper worthy of your trust? Are you comfortable that the user can’t see your data, and the gatekeeper can?
The right thing to do is for the Dapp to deal with privacy issues before the data is submitted to the chain.
6 Likes
Yeah. Blockchain should be trustless. If no mathematical proof that data is fully encrypted, it should be regarded as public. Private subnets won’t protect your privacy nor SEV
Please elaborate what you mean here, including how your suggestion would avoid the trillions of dollars per year on firewalls and other cybersecurity costs, along with trillions of dollars more per year on cybercrime like the IC apparently can. To me, this is the biggest obvious benefit – along with much more open integrations between organizations – of putting the entire IT stack on the IC blockchain. If your suggestion involves going back to primitive AWS-type firewalls, VPN tunnels, extreme trust in pimply-faced network IT guys, etc., then that’s simply a non-starter.
Also, based on my understanding, why would you have to rely on a trusted gatekeeper for private data on the IC blockchain if the blockchain protocol is all open source and only updated via decentralized NNS proposals (excluding the side argument that the NNS is not sufficiently decentralized yet)? Is that not analogous to saying we all have to trust some shadowy figure named Satoshi to keep our bitcoins safe from his blockchain back doors, which might include an undocumented way to reverse engineer our private keys from successive hashes and his code?
I thought the whole magic of blockchain technology is that public blockchains could not be successfully hacked/edited (assuming < 50% of nodes edited) even though both their data and their protocol code are fully transparent for everyone to see. So why would the IC be any different for private data? Maybe I’m missing something here due to gaps in my understanding.
While, NNS provides to Chainkey to coordinate the consensus on its subnets. Considering this scenario, 9/13 subnet nodes fakes the transaction to modify the on-chain by modify the node’s code to pass verification. If the subnets are open, we can then find the Nodes are cheating by figuring who fakes the data because you can’t fake signature with wrong private key. But if the subnets are not open. Nobody knows.
And for privacy, the end users don’t know the data, but the node providers do. Then you have to trust the node provider to keep your secret. With SEV, then you will have to trust AMD to keep your privacy and the nodes need to be configured properly. That means you have to trust the infrastructure to keep your privacy. That simply violates the principle of blockchain as a trustless network. Why not use AWS then?
2 Likes
Not as you understand it. I suggest you review the comment log on this thread and my views and claims.
Building a product on the blockchain only does not require any trust (A true blockchain is a trustless environment), any private data is kept by the users themselves, the Dapp needs to handle this in its business logic. In general, the endpoint (e.g. Web H5) can cache data and only the user’s private key can handle this data, and if the data is to be put on the chain, it needs to be encrypted with the user’s private key as well. If the data is put on the chain directly, Dapp developers need to think whether this data will expose user privacy.
If your privacy needs to be protected by the nodes of IC by not opening the data, then you are just using another AWS by using IC. your payment is totally unnecessary and I think Amazon is more credible than the 13 nodes of IC.
So it needs IC to open the subnet data so that the 13 nodes cannot cheat openly or all users will leave them.
Sunlight is the best disinfectant and the best safety measure!
3 Likes
OK, I think I understand a bit better. Thanks, @Astrapolis-peasant and @bitbruce, and sorry for not being fully up to speed yet.
If a private key is also required for querying, not just updates, wouldn’t that private key also be able to validate any updates to one’s personal data? Obviously, that is more limited that allowing the general public to validate private data updates (i.e, which updates were done with valid signatures), but couldn’t that work in theory?
I had a similar concern with this private subnet issue. Wouldn’t data have to be decrypted on a host machine or boundary node at some point in time (even if just in cache) in order to do SQL queries, searches, etc. (e.g., “select all records with social security numbers that start with 12345”). So even with perfect encryption while the data is stored, what could protect this data in cache without a firewall or similar measure?
In other words, perhaps a better question is what does “private” really mean on the IC, and are we still trusting a nearly anonymous node provider not to go on a treasure hunt into this private data if they are the only ones who can access it (perhaps via the cache or some other means)?
FYI - I’m not trying to be difficult or contrarian here. I’m just trying to grasp this more fully as part of my due diligence, since I see cybersecurity benefits as the biggest selling point of the IC in terms of direct dollar savings/efficiency. However, if there are significant holes in this argument, then that could be a devastating argument against the IC value narrative.
You never reveal your data. To store encrypted data, you encrypt the data first then send it to the server, when you fetch the data you can then decrypt it by your private key. If your encrypted data is exposed at any sense (transferring even https, storage). The secret is compromised. The arguments souds like someone can send the private key over internet(considering all transfer and storage safe, eg. https, SEV), which obviously nobody does
1 Like
Yes, @Astrapolis-peasant that makes sense. So to take my business intelligence (BI) example further, if my phone is searching a 20 GB private database that includes social security numbers and other sensitive info stored on the IC, would the only way to do this securely be to download the entire 20GB encrypted database to my phone and then run my BI platform on a little phone app rather than a web server app? That would seem to be necessary given the requirement not to decrypt anything until it gets to a user-controlled endpoint.
There could be many other examples like this too, even for transactional applications. If so, then I don’t see how any sensitive information could ever be handled by web server functionality on the IC. That would rule out almost every enterprise web application ever being able to run on the IC. The IC could really only run small mobile or wallet apps when they are business or financial in nature. That would explain why the current web use cases for the IC are mostly gaming, social media and other entertainment applications, which require no sensitive enterprise data during interactions. All of this doesn’t sound right vs. the DFINITY sales pitch, though, so am I missing something obvious here?
1 Like
Yeah. That’s correct. If you tend to save like social security numbers on IC, you would have to trust CA(https), Node Providers, and AMD SEV. The safest way is to encrypt it locally and then save it to IC. That’s how Encrypted Messages(You send message encrypted by receiver’s public key and the receiver decrypts it with own private key), Notebooks(Symmetric Encryption) work. You could take a look at IC notebook(git example)
1 Like
Yes, that part is a given - the initial encryption would have to be at the phone or PC endpoint/client as well before it even touches the IC. However, my use case was more focused on the querying part after it is encrypted and stored, since that is what seems to result in the most shocking implications from my perspective.
In short, nearly every enterprise web application relies on decrypted data to process queries, transactions or other functionality on a substantial, multi-user web server. As a result, this encryption limitation would essentially rule out the IC as a viable platform to run any enterprise web application. That means the Web3 world per the IC really involves a huge step back to the pre-Web world of client-server architecture, where many enterprise/business applications were essentially run on the client side. The viable use cases for the IC would be far more limited if all this is true, which I still find difficult to believe.
If you want to build traditional apps, you can’t choose IC. “Everything is possible on IC” is a slogan, but it’s not true, you can’t simply implement traditional apps on IC, you have to refactor your app.
On AWS, at least the server is managed by you, so you can upload private data via https. But on IC, at first you just connect to an IC node via https, but that node is not yours, and if that node tries to expose your privacy or it has been hacked, your private data is leaked before it even enters the IC subnet. IC is far inferior to AWS when it comes to private data.
A Dapp’s private data never leaves the user’s endpoint; it doesn’t travel over the network, much less into the blockchain. If you want to put private data on the chain, you must first encrypt the data in the endpoint with the user’s private key. This is the real logic of blockchain to protect privacy, because it doesn’t receive your private data in the first place.
Don’t hope to put private data on the chain and have someone hold it for you. What’s more, don’t have the idea of querying data in such a way using SQL. No database engine can be built on the blockchain, and the data on the blockchain is not prepared for retrieval. If you have such an idea, we suggest you continue to use AWS. so far, AWS still can not be replaced.
1 Like
So to summarize, it sounds like the IC is not a viable platform for B2B (enterprise) applications or any applications requiring a large amount of private data to be downloaded by a single user (e.g., BI). The IC is really only for certain B2C applications, which makes it more appropriate for independent end users running personal apps on their phone or PC. Please speak up if anyone disagrees.
You are right to be skeptical. You should not have unrealistic fantasies. Because that would not be logical or consistent with scientific explanations, and you should understand that. You have to make trade-offs before you choose IC. That’s the truth.
In the blockchain world, there is no concept of an enterprise. There are only end users and DAOs.
Well said. I agree. You and @Astrapolis-peasant have been a great help to my due diligence efforts, especially in bringing all the hype back down to earth.
Indeed, almost all “DAOs” are really just tiny developer teams with lots of passive followers. As I’ve argued in other posts, DAOs will never be able to scale to become a true decentralized organization (or integrated “enterprise” in our context) without the capability to handle collective prioritization. That problem is actually the focus of my current research.
I think the Dfinity team is partially responsible for the misleading propaganda about IC. It is possible that some Dfinity engineers also had the idea that he looked at IC like a cloud server and pursued the implementation of traditional business processes on IC. A lot of this thinking can be seen in the open source code of Dfinity. It is lazy and misleading. Such ideas will eventually end up in failure on the blockchain, just like IBM’s Hyperledger project.
1 Like
As you say, not yet, but over time all those limitations that you can quote can be resolved in IC given its evolutionary nature. The DAO infrastructure allows you to make changes to the heart of the protocol and thus improve day by day. when Dom says that anything can be built in the IC, he is right. interventions like yours help to expose the current limits and consequently to focus on future solutions
On AWS Amazon can expose your private data.
1 Like