EIP-5749: The 'window.evmproviders' object

Speaking for MetaMask, I second the reservations put forth by @kdenhartog / Brave, and we also have no intention of implementing this standard as written. While the problems noted by the EIP authors are real, we believe that injected providers are fundamentally flawed, and we should seek to abandon that practice and window.ethereum entirely. We encourage all wallets to invest our collective resources in provider standards that support non-EVM chains and do not rely on injection, such as CAIP-25 and its related standards (WIP).

In addition to @kdenhartog’s points, we oppose this EIP in its current form because:

  • Extensions must possess extremely broad powers over every webpage in the user’s browser in order to inject a script tag. The Google Chrome team recently fixed a bug such that it is now possible for an extension to receive messages from any webpage using chrome.runtime.connect and/or .sendMessage. This makes it relatively straightforward to abandon injection entirely, which is what MetaMask intends to do.
    • See the externally_connectable permission in the Chrome extensions documentation for more details. Valid matches patterns now includes http://*/* and https://*/*.
  • The EIP does not specify who will maintain the namespace for wallets, or in what manner they will do so.

Solving the problem of injection race conditions is fundamentally a social coordination problem for wallets. While this standard could help facilitate that coordination, we don’t believe that laying claim to another global name is the solution. We should instead invest our energies in provider standards that avoid injection entirely.