Reflecting on this whole situation, I suspect MCP is fundamentally insecure, in which case Supabase should refuse to implement it.
MCP's goal is to make it easy for end user developers to impulsively wire agentically running LLM chats to multiple tools. That very capability fundamentally causes the problem.
Supabase's response (in the top comment in this post) of making it read-only or trying to wrap with an LLM to detect attacks... Neither of those help the fundamental problem at all. Some other tool probably has write capabilities, and the wrapping isn't reliable.
> MCP's goal is to make it easy for end user developers to impulsively wire agentically running LLM chats to multiple tools. That very capability fundamentally causes the problem.
That's exactly the problem here: the ability for end users to combine MCP tools means that those end users are now responsible for avoiding insecure tool combinations. That's a really hard thing for end users to do - they have to understand the lethal trifecta risk in order to make those decisions.
>> My question to those who support big brother any lawful but awful speech is - do you really think it won’t be used to silence any dissent of the ruling powers?
My question to those that use this line of reasoning is do you really think a ruling power willing to silence dissent would do so whether or not it is supported?
A salient point no doubt. There is ample evidence that some are silenced by a range of methods. I’m simply not going to support codifying that sort of thing in law.
I would argue if we have people in positions of power who would make decisions like that then it is our duty to our progeny to relieve those in question.
Its true, any specific open source project will have a limited and influential contributor base. But the fact that its open source code also allows it to be fluid and dynamic; ie. you and anyone who has different ideas about the direction of said project can build their own forks. You can convince people to support your network.
And then your network will compete with all the other open networks and protocols. And may the better ones win.
I call this the "Vulnerability view" instead of a "Remediation view" and its something I feel a lot of Security people and tooling gets wrong when sharing information with those outside our bubble.
It is dead easy to export a vulnerability scan or penetration test report and throw it at the developers, but you will get much better outcomes and better rapport if you tell them what they need to do (i.e. patch to version x.x.x) versus telling them what is wrong ("the sky is falling!").
Person that has worked on the defensive side of Money Laundering here.
The Tornado Cash sanction has been fascinating to watch and my key takeaway has been that there are two camps: that TC is a Money Laundering service or a Privacy service. Both are talking past each other, when it can in fact be both. Each camp see the service as their primary concern and consider the other camp as an unintended secondary.
I am seeing a lot of bad takes. "Money laundering requires all three aspects" particularly irks me because you can just point to KYC regulations to disprove that.
"Code is just code" is another, but that is just because the code isn't why someone would be sanctioned or arrested. In the same way that The Pirate Bay was just code, its is how complicit they were in the offence that will get them.
Ultimately, the dichotomy feels like a problem unique to public blockchains, and will only be solved with a ZK L1 chain, whatever that looks like. The solution would require the blockchain equivalent of end-to-end encryption, one where intermediaries have zero knowledge but doesn't require co-mingling of dirty and clean money.
While I think money laundering is a more serious crime than piracy (at least the predicate offenses can be). Watch this play out like Megaupload, never ending legal issues for the first parties, and a technical solution like Mega.
I totally concur to your view. The issue would be the level of complicity in the offense of TC hosts... which will not be studied in theory by analysts studying the code, but by investigators looking at mails, meetings, money, interviewing people, etc.
Tech bros tend to forget that there are real people on the side of Law enforcement and that they can actually investigate in a very real and traditional manner, with surprisingly good results.
> Ultimately, the dichotomy feels like a problem unique to public blockchains, and will only be solved with a ZK L1 chain, whatever that looks like. The solution would require the blockchain equivalent of end-to-end encryption, one where intermediaries have zero knowledge but doesn't require co-mingling of dirty and clean money.
But then either only ever use Monero for everything (like pre-2013 bitcoin), or exchanges will need the will to "proof" the source of funds aren't illicit.
How does Montero solve the problem of co-mingling dirty and clean money. As far as I understand there is still considerable illicit transactions within a block thus supporting indirectly bad actors (in e2ee I do not see that problem that clear)
Is there any cryptocurrency Blockchain (or research) that can limit the amount of currency held by each natural person (e.g. to an equivalent of roughly 10000 USD purchasing power) while providing anonymity for individual transactions to the outside? I would actually be willing to adopt such a trade-off roughly equivalent to cash (even paying transaction fees). At the moment I would not use crypto currencies because I do not feel that I share the values of the block chains.
>one where intermediaries have zero knowledge but doesn't require co-mingling of dirty and clean money
how would that be different from tornado? There's no legal difference between a contract with a balance and an internal utxo tree, and a blockchain with a total balance and an internal utxo tree.
yeah you should ignore the hot takes and just read this article from the EFF and the linked Coin Center article on this.
otherwise nobody else knows what you are talking about and it just reads like strawman arguments to discredit something nobody here actually said.
The issues are that the order does not distinguish between an un/incorporated organization of humans called Tornado Cash, and the autonomous smart contract that those humans do not control. The autonomous smart contract has no way of petitioning to removing itself from the SDN list, which is a prerequisite for inclusion in the SDN list, and a prerequisite for an American to get a license or have any remedy under the Administrative Procedures Act. Another division of the Treasury, FinCEN already has knowledge on this distinction and has said it in the past, while the OFAC division is acting like it is not aware of that guidance at all. There are other issues with that.
The follow-on issues are that this creates a chilling effect on speech and expression. Nobody knows their liability surface, and alters their own behavior because they aren't sure if they're going to prison or not.
> solution would require the blockchain equivalent of end-to-end encryption, one where intermediaries have zero knowledge but doesn't require co-mingling of dirty and clean money
How would you draft a statutory safe harbor for GitHubs and Coinbases when it comes to handling mixers as well as the wallets connected to them?
As someone else has stated elsewhere in this discussion, I don't think GitHub have much to worry about. Tornado Cash the service was sanctioned, and MS would choose to censor the repo out of an abundance of caution.
In the same way that the pair that open-sourced the ransomware PoC didn't get arrested because they are further away from the offenses.
I have mixed thoughts on safe harbor for centralised exchanges, they are the closest thing we have to banks in cryptoland. Mostly because with grey areas like that, a prosecution is only going to be pursued with clear evidence they knew but did nothing.
> In the same way that The Pirate Bay was just code, its is how complicit they were in the offence that will get them.
Can you explain what you mean by this? To me, publishing code that can be used to do something is very different from running it and allowing people to use it.
A smart contract doesn't run on it's own, you still need computers to run it. Not to mention for Tornado cash, you also need people interacting with the contract and sending money to it, since it doesn't do anything on its own
> Typically, it involves three steps: placement, layering and integration. First, the illegitimate funds are furtively introduced into the legitimate financial system. Then, the money is moved around to create confusion, sometimes by wiring or transferring through numerous accounts. Finally, it is integrated into the financial system through additional transactions until the "dirty money" appears "clean."
More-so than that, I see a conflation and confusion on the different stakeholders and components of Tornado Cash, on both sides of the ML/privacy split you describe.
Note that the TC smart contracts are completely autonomous now (no entity with privileged permission or receiving a fee). They are truly non-custodial and necessary functionality is either executing on-chain or locally on the client.
So a user can make full use of tornado cash suite (smart contracts + UI) without ever having to interact with or pay a fee to anyone involved in the project.
Now, if a user withdraws manually, they will still need to submit a withdraw transaction and pay some ETH for gas (transaction cost), which will link that ETH with the withdrawn funds. So there is a chicken-and-egg problem here. To solve this, the UI integrates with a network of relayers who will facilitate the withdrawal transaction and cover the gas for a percentage fee. Relayers aren't hardcoded in the UI or smart contract and users can choose their own third-party relayer. The relayer network is permissionless and autonomous as well - anyone who sets up the software and commits enough funds will be one. In newer versions of the TC UI, only relayer nodes which have staked a minimal amount of TORN tokens are showed for selection, and there is a ranking and preference of relayers who have higher amounts staked.
This relaying, on the other hand, can absolutely be seen as a service. There could be a case for ML to have against that network of relayers. And potentially (though this is new territory for courts I think) TORN token holders and/or governance participants. This clear separation between the components and stakeholders and the removal of the need of privileged actors is precisely what makes TornadoCash different from legacy mixers.
I think it's very unfortunate that even people in the space characterize this TC as such as a "service", as I think it's best viewed as "not a service" - to this point, there are no service providers apart from the serving of the self-hostable client web UI. Which is optional. It's hard to tell in which cases this is a conscious oversimplification and in which cases people aren't aware of the nuance.
If I'm allowed to make a rough comparison from the best of my understanding to Bittorrent for those who remember the TPB saga:
Ethereum nodes: Bittorrent DHT
Tornado Cash UI: Bittorrent client in a web UI
Tornado Cash smart contracts: software executing in the "DHT" (by every node)
Relayer server-side API (old UI): Bittorrent tracker
TORN DAO smart contract (new UI): Bittorrent tracker, except there's no server anymore and it all executes in the DHT
Having the DHT stand in for blockchain is not fully accurate of course but should hopefully get the major point across. Makes sense?
> Person that has worked on the defensive side of Money Laundering here.
Would love to have a follow-up from you with thoughts on the above.
I think mainly that I do not envy the lawyer that has to make the service argument.
We could get lost in the technical details of why it is or isn't a service but ultimately they only need to prove that x person of the project knew about the issues, could have done something about it (like shut it down), and didn't do enough.
It was just the one contract wasn't it? i.e. someone was responsible for deploying the contract that inputs and outputs the blending between addresses. In this scenario, the other permission less stuff is theatre.
My understanding is that a good chunk of the TORN tokens issued by "DAO" are earmarked for developers of TC, and these token could be sold for money, etc.
Plus the initial developers could run relay nodes to make money, and can even do it in a way that is basically impossible to prove, by using TC itself when withdrawing the profits made by their relay nodes. Back before sanctions, even at a centralized exchange, nobody would think anything is odd about TC developers exchanging out coins previously transferred through the TC system. After all they care about privacy and don't want people to be able to trace back to all their previous transactions.
They profited from issuance of the TORN token but they did not take fees out of every deposit. Relayers are the ones who receive fees for withdrawals (about 0.1 ETH) and depending on your point of view could be unlicensed money transmitters (and if they are still operating after Tornado was designated then sanctions violators).
I for one do not miss hosts never being patched because all those slight modifications to systems files that were tweaked several builds ago and now everyone is too scare to touch.
I won't miss the 12 month projects to upgrade some dated software to a slightly less dated version of that same software.
From my perspective in Security, DevOps has made life much better.
The ability to spin up a box, have it run insecure code, and then spin it down; and the ability to do that all day long, is worth it for the security benefits that all this complexity entails.
> The ability to spin up a box, have it run insecure code, and then spin it down; and the ability to do that all day long
What's the best way to do that? I have some insecure code that needs to run about 6x a day, and so far my best thought has been an isolated box outside my network that does the internet based fetches, translates the data and then submits them over the web to another service that verifies/checks the output.
The only novel benefit, as you say, is "decentralized trust".
The blockchain portion of the NFT in most cases is simple a pointer to the asset and the owner, with the actual asset being off-chain managed by a single entity that can do whatever they please with it.
Why does the ownership need to be decentralized if ultimately, the asset is mutable?
I still don't understand why this needs to be decentralised?
> without having to solely trust the company issuing the nft ticket
For the transaction yes, but what about the thing you are buying? Perhaps I am not thinking creatively enough, but I can't think of a use case where there isn't ultimately some trust required other than solely digital assets.
Using your hotel example, you will end up at the hotel where they can choose to honor your ticket in the same way as their traditional booking system. There was no need for this to be on a distributed ledger as the asset (a hotel stay) was between you and the hotel.
You are not cutting out the middle man of some SaaS provider, you are substituting them.
Perhaps, but its ok either way, it's not really limiting the DAO or the places leveraging the DAO to pursue this stuff.
> Using your hotel example, you will end up at the hotel where they can choose to honor your ticket in the same way as their traditional booking system. There was no need for this to be on a distributed ledger as the asset (a hotel stay) was between you and the hotel.
Its not just about honoring the ticket for the duration of any particular booking, but also mitigating the risk between multiple parties and being able to easily integrate such information with as many decentralized protocols are needed for the parties involved without extra dev overhead to connect them.
For some places, you need to have a card on file in case of damages (this is where the decentralized escrow/dispute and resolution protocol come in) and rely soley on visa/mastercard and the hotel unilaterally being able to say that you were the cause of an issue that may come up or being able to decided whether or not you are on the hook.
Incentivized actors (these need not be people, it could be automated, but since everything has an address, no one can tell the difference) of those other protocols on chain need visibility with the address that held the nft. So yes, its trust the protocols and incentives associated with them around handling dispute and resolution and non custodial locking of collateral in escrow (or allowing another protocol to time lock collateral on ones behalf).
And this assumes that the place someone buys an nft stay has the in house capability to do all that without using a particualr nft stay protocol (which alot of places dont esp for random bnb) or ok with giving a large cut to airbnb/booking.com/visa etc if they don't.
> You are not cutting out the middle man of some SaaS provider, you are substituting them.
Yes, for code that can take a lot less of the cut than existing SaaS providers (if any at all). A protocol != SaaS provider, even though a SaaS provider could manage a protocol[0], or a protocol can just be an set of immutable contracts deployed on chain, or anything in between.
I think the subtext that is implied with the no use case statement is really: "that couldn't be done with an existing technology (such as a database)".
Seriously, decentralized, pseudonymous money that is censorship resistant and doesn't rely on any single government or organization is the killer app. That's how I'm using it, it works perfectly for my use case and even though it's a sample size of one, there's at least one person who relies on it and can sleep at night a bit more soundly knowing that their money won't suddenly be gone the next morning because PayPal or their bank looked at them funny because they were born in a spicy patch of land. Anything else comes as a plus.
Do please spare me the whole "it's boiling the oceans" and "only hackers and druggies are using it" spiel though as they're both [0] untrue [1].
As a platform, where do you draw the line between offering a product vs not because a developer could do something stupid with it?
edit: keeping in mind the use cases they are pushing in their documentation are for local development