search

MetaMask / metamask-extension

:globe_with_meridians: :electric_plug: The MetaMask browser extension enables browsing Ethereum blockchain enabled websites
https://metamask.io
Other
11.86k stars 4.84k forks source link

RFC: Aim to end provider injection entirely #10600

Open danfinlay opened 3 years ago

danfinlay commented 3 years ago

Opening this issue to discuss the possibility of moving off an injected provider onto a fully postMessage based provider. This would not be a quick change, this would be a long transition, but it might be good to at least consider putting into eventual motion.

We usually talk about provider injection as a necessary evil for providing our API to websites, but really it was to remain compatible with Mist, back when the web3.js library was the assumed interface for interacting with a Ðapp browser.

I’d like to highlight a specific downside of the provider injection (Related to #1515):

Because of that permission, if MetaMask ever were hacked (god forbid), the impact could actually go beyond the user’s accounts and impact their entire online presence. Banking, social media, etc.

Fortunately, as part of the EIP-1193 changes, we have moved many developers onto our increasingly popular @metamask/detect-provider module, as well as eth-provider, which could be used to allow even more easily migrating Ðapps onto alternative provider injection schemes (with a single non-breaking dependency update).

Would require some additional research on what it might look like to make our inpage-provider a developer-provided module, and if this limits the functionality or security of our interface in any way. This might also involve publishing an additional “compatibility extension” like our legacy-web3 extension.

Anyways, comments?

shanejonas commented 3 years ago

+1

Requiring the extra permission could definitely be a deal breaker for some users, getting rid of it would be a great goal.

This also allows more focus in the future on the JSON-RPC interface (available over http/ws/postmessage depending on what you're interacting with) and less so on the specific typescript Provider interface.

danfinlay commented 3 years ago

Reviewing the docs on the Manifest v3 format, it also seems that this kind of permission may be fighting against the grain of how they’re trying to nudge extensions, too: https://developer.chrome.com/docs/extensions/mv3/intro/platform-vision/

robertdavid010 commented 3 years ago

I'm my review of the Metamask code, and of the Manifest V3 standard, it seems that it will not be possible to inject the provider at all, and the current approach of relying on web3/ethereum obj to be injected by the plugin the web3 ecosystem will have to be changed. This will also affect how developers create websites to use metamask/ethereum/web3, as their current approach will not be supported after discontinuation of Manifest V2 support. It would therefore seem necessary that the entire web3 ecosystem will have to adapt to this change, and Manifest V2 support is being dropped at the end of the year by Chrome.