I need to harp on an issue that I’ve raised a few times in the past, and that issue is access to the front-end source code.
As you may know, Tornado.cash is made up of two principal parts - the contracts and circuits, and the front-end. The contracts and circuits are all open source, and a good chunk of the JS that is used to interact with them is open source. However, the code for the front-end is closed-source, and it’s not clear to the community who actually has access to it.
The problem with this is that there is little overlap between those who offer support to Tornado.cash’s users, and those who have access to the front-end code. So, when there’s a flood of questions in Discord and Telegram about why user are unable to withdraw their notes, all that most people who want to help can do is throw up their hands and say “I don’t know, maybe try a VPN?”
If all that the front-end did was call off to open source contracts, it’d be feasible to made educated guesses about what’s going on. However, the front-end is seemingly much more complicated than that. It’s using prepared caches of data served as ZIP files. It’s calling off to random, closed-source contracts (does anyone know what 0x8cb1436f64a3c33ad17bb42f94e255c4c0e871b2 does?). It’s processing logs from Infura in order to generate proofs, but it’s not at all clear how it’s doing that, and why it might be failing.
I’ve been providing support to TC’s userbase for several months now. I have enjoyed doing it, and I’ll probably keep doing it. But the fact that many questions are having to go unanswered because nobody has access to the code, or has access but doesn’t offer support, is super frustrating.
I think that the multisigs should fund a snapshot vote on this issue. Either the front-end should be made open-source, or there needs to be a transparent decision-making process for how people are given access.
Tornado.Cash is one of the most complex DApp itself so the source code of the frontend is important for the support as well as for solving various issues raised by users.
Source code is closed source for now to make it hard to create low effort ponzies and scam and phishing copies of tornado cash website. The security of the protocol is defined by smart contracts and snark circuits, the UI only handles user interactions and doesn’t affect the security of the protocol. There is also an open source CLI version that demonstrates how to generate snark proofs and interact with smart contracts.
In practice it is very unlikely that anyone apart from Tornado Cash team would actually contribute something meaningful to the UI repo. Tornado Cash CLI was open source since the beginning and has very small code base that is much easier to understand than UI. Yet it had 0 pull requests from the community for 2 years, only very recently one developer started contributing something to it. Nodody will be making PRs to much more complicated UI repo.
0x8cb1436f64a3c33ad17bb42f94e255c4c0e871b2 is https://github.com/tornadocash/tornado-aggregator, but we forgot which exact version to verify it. If someone is willing to pay the gas fee to redeploy the latest version it can be easily verified. The contract contains only view methods, no transactions are made to that address, so it does not impact security.
the same way as CLI, it downloads commitments and nullifiers and builds a merkle tree from them. Caches contain the same commitments and nullifiers up to a certain block to speed up this process.
This has not stopped anyone from making rugpulls using TC’s contracts. We’ve seen at least two likely examples of that in recent months (e.g. “Smash Cash”).
It is also trivial for an adversary to spin up ui-minified under their own domain, with additional code injected to steal user notes. Keeping the UI closed-source doesn’t create any level of improved security. Security through obscurity is a fundamental anti-pattern of information security.
This is objectively untrue. The security of the protocol includes the security of the interface by which users interact with the protocol. There is no way for you to demonstrate that the UI is not transmitting user notes and identifying information to adversaries in a closed-source UI.
Users should assume that it is the case that you are recording their information. We should be informing users of TC that they shouldn’t trust the front-end, since they cannot audit it.
All that we have is your word that you’re acting benevolently. That means that TC isn’t a trustless privacy solution.
Yes, the CLI version demonstrates a subset of the functionality of the TC protocol. For anyone simply interested in how to interact with the smart contracts, it’s adequate. That’s not relevant to this discussion.
This comes off very ivory tower of you. You’re saying that because nobody contributes to a tool that very few people have any interest in using, that somehow means that you’re the only one who needs access to the code of the application that everyone uses.
How about we invite some contributions to the UI, instead of firmly telling off anyone who suggests that they might want to contribute to it, and see what happens? I’ve been saying for literal months that I’d like to make some contributions, and have been consistently stonewalled.
Apparently you do, because that wasn’t at all obvious from the errors available in the browser console. There have been several different kinds of errors mentioned by users, and they haven’t all seemed related to fetching the proving keys.
Correction. That contract posts obfuscated data to Infura. It is not at all clear what information that contract call is leaking. It substantially impacts the security of the application.
We have only your word to back this up. To be clear, despite my critical tone, I only have respect for your abilities and motivations. My trust in you shouldn’t matter whatsoever. I, and everyone else, should have some way to verify the integrity of the front-end. Those offering community support should have access to the front-end code so as to be able to back their answers up with evidence - not making guesses and hoping they’re right, or parroting what others have told them to say.
If the community multisigs are intended to represent the interests of the community, then they should be doing so. They shouldn’t be representing the interests of the developers. We should hold a snapshot vote in favour of opening up the UI sources.
I agree, trust is an assumption and as we all know contrasts to the trustless nature of open organisations. The frontend interface is the means of access to the protocol, it should be accessible to the demographic who gives it value. Not only to optimise it through peer production but to mitigate any concerns about individual sovereignty as a user.
Where else are the proving keys hosted? It might be feasible to have a fallback methods directing to a ipfs instance or github on failure, where it’s already served in the tornado-cli repository.
Governance is still in it’s infancy, and decoupling from any remnants of central control should be a priority. Tornado has done a excellent job thus far, but it is industry standard to adhere to open source every element of the stack. Uniswap and Balancer being two notable mentions to reference. Contributors cannot propose any improvements without knowing the anatomy. I’d argue the protocols core contributors have not matieralised yet, so to assume there would be no beneficial exposure is not feasible.
I also think the phishing defence, is only adequate for the inception of a protocol, not it’s entire life span. The malicious instances already use the minified UI pretty effectively to do what they need to victimise. Perhaps the halfway solution here would start with assigning access to relative contributors.
Could be an order of magnitude more of them if UI was open source. Most tornado based pump and dump projects had to build their own UI which is way harder than doing a low effort fork. Interestingly, almost none of them open sourced their work.
I rather call it security by making an attacker do additional work. Most choose an easy way of forking some other project, like Uniswap, and use that to scam users.
We thought this is insignificant. If someone thinks otherwise and is willing to redeploy and verify it, we will use the new address. I see no problems here.
There’s always some degree of trust involved with the frontend, even if UI is open source. Users have to trust that obfuscated files they got served contain the same code as GitHub repo. This is one of the reasons Tornado Cash still doesn’t have an .onion endpoint: the team doesn’t want to host an official one, and if someone else does it there is no good way to verify that it doesn’t serve a malicious version.
It’s very hard to audit a huge UI codebase, so if someone wants to eliminate this trust the better way would be to use a CLI tool that contains much less logic and is more predictable and straightforward.
Or someone could build a simpler version of UI that is easy to audit, that would be really cool. One of (smaller) reasons the main UI is closed is to incentivize this behavior to decentralize the frontend more. Unfortunately almost everyone who’ve built alternative versions up to this point didn’t open the source code. But I much rather see alternate versions emerging, with different teams supporting them, so that we have more distributed way to access the protocol.
A very important point. An important part of privacy is the ability to safeguard one’s own information in a fulsome way. It’s not just the absence of surveillance, but the defense against it as well.
My understanding is that a fix has just been deployed to add redundancy for IPFS gateways to the app’s internal asset loader. This should be adequate, so long as there is redundancy as well in the serving IPFS nodes.
I asked our internal devops team at EF to pin TC’s assets to our IPFS cluster, and they’ve done so, so that should add some redundancy, and geographic availability. TC could also use some IPFS pinning services to add additional availability.
This is certainly a good starting point. More eyes makes better security. If we aren’t open to immediately making it available to all eyes, then we should at least have the code available to anyone who’s otherwise already recognized as a contributor in the project.
Yeah, keeping their sources closed certainly does enable them to more easily get away with acting badly. Let’s not have that behaviour in common.
It’s really not much more work. Fork ui-minified, add a script to the head that posts whatever’s in the deposit/withdrawal field to their server, publish to fake domain. Done.
Or even just take the HTML from the existing app deployment, copy it to a fake domain and edit it in the same way. So far as I can tell, there’s no content integrity mechanisms being used in the TC app that would prevent this.
Happy to help with the redeployment. I imagine that governance could pay for the deployment costs.
There are solutions to this problem that are well-established. It’s a bit more complicated for web applications, but the name is Reproducible Builds.
We don’t have to go full deterministic compilation, but we could use a public build service like Travis CI to perform the builds, and publish them with content hashes that could enable Subresource Integrity validation.
From there, there are additional mitigations that can be applied to enable users to verify that they’re being served the legit application, that it corresponds to a public build - that has, say, been approved by snapshot for deployment.
User don’t want to use the CLI. This isn’t a good argument. We should make the UI simpler, through refactoring, the use of public auditing tools (e.g. dependency checking, strict linting to prevent code complexity, etc).
This could certainly be an option that I would get behind, and may be able to find funding for. However, there is certain functionality that would require access to the existing code in order to understand, and TC would have to commit to switching to the open source implementation as soon as it’s stable (not just saying “Well, ours is closed-source and the one that we recommend, but if you’re so worried about your security, go use this unmaintained open source thing someone else made”).
