The Misconception of Decentralized App Promises
Nothing in this world is guaranteed. If you see a company claim they provide a censorship-proof solution, run. If you see a company claim to provide guaranteed security, run. If you see a company use decentralization as all the proof they need that their software is private or secure or even worth considering compared to the incumbents, run.
Anytime a decentralized application protocol arises, there are always questions from that protocol’s community (whether from developers or people just interested in the technology stack) about what promises are made by the apps or the protocol in regards to privacy (or security). It’s a fair question, but any answer should be treated with skepticism. The fact is, the protocols themselves *cannot* make promises about the privacy or security of the apps built on the protocol. The protocol can make promises about what the underlying software can do, but the second that software is transferred into the application’s code base, the trust basis is shifted entirely to the app maker.
Graphite is built on Blockstack. Blockstack does not promise privacy, nor should they. They promise user-ownership of data and identity. To a certain extent, user-owned data is private data, but it is still susceptible to breaches of the underlying cloud storage choice the user makes. So, let’s just operate under the assumption that Blockstack offers the potential for privacy (through encryption) and offers user control of their own data. What they do not offer is any sort of promise as to how apps use their open source tools. So, questions and answers like this forum post are well-intentioned but misguided.
No user, group, or company should rely on the guarantees Blockstack or any other decentralized protocol makes. They need to look to the applications themselves. They need to look to the companies behind those applications. A protocol can only offer so much, and then it turns over control to the apps using the protocol. It’s like parents teaching their children values. Those values are set, but the application of those values are ultimately determined by the children when they are set free on the world. The same is true of decentralized applications (the children) and the protocols they use (the parents).
So, what is the right question? There are many that I think are applicable. Let’s explore them.
- Does the protocol audit apps using their software?
- Is the application I’m wanting to use open source?
- Can I verify outside of the code what network requests the application makes?
Does the protocol audit apps using their software?
This is a tricky question. I can understand a desire for end users, community members, and even developers to want some sort of audit. But the line decentralized protocols must walk carefully is that of decentralization. Too much control thus negates the decentralized aspects of the protocol.
For example, Blockstack just recently announced the addition of New Internet Labs as an app reviewer as part of their App Mining program. New Internet Labs acts as an auditor of sort, but there are two main differences in this announcement compared to the protocol itself auditing apps. First, New Internet Labs is an independent third party. Second, the audit is specifically designed for the App Mining program. It has no bearing on what apps can develop on the platform and who uses them. New Internet Labs has a narrow focus.
If Blockstack were to broadly apply an auditing system, then users of the apps being audited would have to trust the app and trust Blockstack. There’s an added level of trust in a world where we are trying to become trust-less.
Is the application I’m wanting to use open source?
Graphite is open source for this very reason. Well, the truth is, Graphite is open source for many reasons and this is just one of them. But how far does being open source actually get you? Users who do not have the technical knowledge to audit code have no use for open source repositories. They literally mean nothing to those users aside from some tiny reassurance that if the code is open source, the app must work in good faith.
To a certain extent this is true. An open source repository is sort of like a safety blanket. It makes you feel good but it doesn’t actually protect you. So, you should hope for decentralized apps to be open source because it removes a layer of trust required, but an open source repository does not prove the hosted application uses the actual code displayed in the repository.
Can I verify outside of the code what network requests the application makes?
That brings us to the final question. Can you, the user of the application, understand network requests and get a sense for what data is being sent where by the application? If not, this is sort of the end of the line for you. You have to decide based on the previous two questions if you have enough to trust the application or not.
However, if you do have the knowledge to read network requests, you can start to verify some of what the application developer (or company) has promised. You can watch each GET request, POST request, PUT request, etc. You can see the payload. You can tell where the data is being retrieved from and posted to. It’s not a perfect solution, but it gets you a lot further than the trust you have to apply after the first two questions are satisfied above.
Here’s an example of the network requests in Graphite. There’s a lot going on, so you may have to sift through the noise to find what you’re looking for, but below you can see the documentscollection.json file loaded.
In that image, you can see the payload returned from the GET request. This is important, because you can see the payload is, in fact, encrypted (which is a promise Graphite makes to users that they can now verify). What’s missing is where that data is fetched from. Let’s look at that.
On the headers tab of that same request, we can see the Request URL which tells us where the data is being fetched from. In this case, the example is from a user that has chosen to use Blockstack’s default storage (which is hosted by them and provided through Azure). As a user, I can verify that the URL shown is the one that is mine and mine alone. In fact, I can pull up that URL in another tab and see the actual content:
Going to the URL from the request loads the encrypted file. You’ll see that the file contents are what was returned in the response we saw in the first screenshot.
As you can see, someone without a technical understanding of network requests would have a hard time parsing this information. But if you have such an understanding, you are a big step closer to no longer having to trust the application or the protocol. You are much closer to being able to verify the promises being made.
Conclusion
It’s right to ask what proof there is that anything anyone says is actually happening (or not happening). But it is entirely misguided to expect the protocol layer to promise the activity of the application layer. You, as a user of any application, are inherently trusting the application the second you use it. No one can guarantee anything for you if you’re using an application hosted anywhere besides on your computer using any code other than that you have complete control over.
So, if you have to trust applications, start by asking the right questions.
