Add Durin support #2478
Anyone watching this repo/issue, I'm working on the initial security model for CCIP Read, and would love to bounce these ideas off you. :)
The concern with CCIP-read is that is allows a contract author to manipulate a caller (via normal blockchain interactions) into calling an external server, which could be controlled by the author running IP tracking software or targeting a specific URL to DDoS the service. Here is a short article outlining some of the concerns which have been found in the wild (largely for PoC).
For an example of my concern, imagine running an ERC-20 token, where the
So, for v5.6 CCIP Read support, these are my planned default security considerations:
"enabling it will prevent all CCIP Read attempts to fail" should be "enabling it will cause all CCIP Read attempts to fail" right?
I like the idea of not enabling by default yet. And I would vote to keep it disabled until there are options in popular wallets to:
If it just gets enabled in v6 without any ability for users to disable it (if they're using a wallet/client that uses ethers) or at least have some transparency into what external servers are being called with what data, I think that would be a very poor security/privacy outcome for the average person.
@serenae-fansubs Yes, you are correct. I've corrected the OP.
In v6 there is a whole plug-in system for Providers which will be used for much finer-grain support for vetting each request allowing, for example prompting the user, whitelists, blacklists, etc. as well as allows intercepting and fetching it for the user, allowing for example MetaMask to proxy all requests through their own anonymizing proxy.