“I tell folks that a lot of people have lauded our GUI as the best in crypto and that may be true. That said, Bram and I consider it a piece of poo and is totally the minimum viable product we could ship!” This is the response I get from Gene Hoffman, President and COO of Chia Network, while chatting with him about their Windows client. I wouldn’t necessarily say its that bad, but the reason we are sitting down to chat is that there is a lot of room for improvement. I fully agree it looks great and is highly functional especially for less technically comfortable users. But that is the problem we are facing.
When Chia Network launched, less than 2 months ago let’s remember, there wasn’t a chance in the world they expected it to blow up like this. Most people would expect that the majority of serious farmers would be running this on Linux as a series of microservices each handling their specific task. And that is likely true, when you consider their proportion of netspace. However, there are also hundreds of thousands of Windows home PCs connected together in an open network and that is a huge accomplishment, from one perspective – but a huge risk from another.
I have conducted a pretty thorough review of the Chia Network windows client, and having spoken to Gene about what I have uncovered it comes as no surprise to them. The architecture of the client is a series of trade-offs between functionality and security. They know that python is potentially not the most performant option in all cases, but it does have a highly secure network front end. So they use it, because they can’t take other hardening options without too much sacrifice to the user experience.
First, the service deployment. Each of the Chia services runs as the local (usually administrative) user and has access to all the files available to every other service, including configuration and private keys. Also to the rest of the system. There is an obvious solution to this problem, but it will make running and managing the Windows client extremely difficult, especially for the novice users that cannot be discounted. When I suggested it to Gene he agreed it was the best solution, and a total non-starter as it would set the bar of entry too high for new users. I don’t love it, but he’s probably not wrong.
Another issue with how the services are deployed is that they are each running a Python3 instance that calls the rest of the code required to run the full_node, wallet, or farmer applications. Again, Python3 itself isn’t the issue, it is as secure as it gets for something of this nature. But it is a shell and with the correct exploit it can be a very permissive compromise. Which is why the user account that runs that Python shell should always be setup with the least permission security mode. It also requires opening the Windows Defender Firewall to the application rather than a specific set of ports.
The answer to both these issues is to run each service as its own user account with explicit permissions to exactly what they need in the chia-blockchain and .chia folders. This will mean that even if the full_node is compromised it won’t have access to the rest of the files or keys. But most importantly it won’t have full administrative access to the user account running the Chia application. This will also lead into my next suggestion:
Separate the GUI from the production services, either by running it as a webservice that talks to the other services through a websocket or internal API or by just launching it as a separate client without a node, farmer or wallet that talks directly to the others through an API. A lot of this work is already done, and it is simply a matter of repackaging. And then once we are doing this, I have a laundry list of ideas including changing how certificates are stored and issued to changing how they authenticate the client users.
But this is actually where I begin to step out of my lane. I can identify security issues with the application and make high level recommendations on how to architect it better. But I am not a developer or programmer. In order to fix it and develop a real Windows application that could be legitimately run in a datacenter or conscientious home network we would need some serious community involvement. The ROI isn’t there for the Chia Network team to develop and maintain a serious Windows client for serious Windows admins. And it likely never will be.
But this is an open-source project for a reason, and to be blunt – we don’t need them. Actually, we would need them, probably a lot, but we don’t need them to lead the project. What we need is a real developer willing to sit down and design a real Windows Server application with a roadmap and everything. This will take a lot of time, but it is important to me. So what I am going to do is put 1 XCH into a fund with the following address and implore everyone who wants a better Windows client to donate. I have a companion post coming to address the details, but basically, I want to incentivize the development of better Chia software. We got a better plotter thanks to Mad Max, now lets get a better client.
Contest Address: xch1hew8r5fw70fv6rlk5ur4axlsjzkl4d5uy4d6lj8fme3t5mvwuacq37kgff