EIP 6963

Background:

Metamask was the pioneer in Browser wallets, it was developed by Consensys back in 2016. After that a series of wallet extensions were developed during the last bull cycle. Few mentionable are Trust, WalletConnect, Zerion, Rainbow, Phantom, Talisman, Brave, Coinbase and more. Each wallet targeted different blockchain community and use cases. Some of them supported multi-chain operations too. 

Why The Need?

If you have been a Crypto Enthusiast and a Blockchain supporter you might have found yourself in a place where you have to use 2 or more wallets in your browser. Maybe to get an Airdrop or any other reason. Here is where EIP-6963 comes into play. EIP-6963 is all about streamlining Ethereum wallet providers. And enhancing the UI experience of Users. 

EIP-1193:

To understand the impact and importance of EIP-6963 we have to look into its predecessor EIP-1193. It outlines a method to how a DApp and Wallet will connect. Wallets will inject into a function called window.ethereum to load into a DApp. Here comes a race condition issue where the last one to load usually wins.

What’s the Issue?:

This race condition hinders the user experience. If you have 2 or more wallets in the browser you would have experienced this issue that you can’t get to load the wallet which you want. Rather an expected behaviour happens and a random wallet is chosen or the wallet which wins the race condition. More often you would have disabled an extension from the chrome extension manager and then your favourite wallet is loaded in connected with the DApp.

EIP-6963:

A new EIP is proposed to tackle this issue. It aims towards optimising the interoperability of multiple Wallet Providers. This solution aims to foster fairer competition by reducing the barriers to entry for new Wallet Providers, along with enhancing the user experience on Ethereum networks. Basically the decision to use a specific wallet lies in the user's hands now. DApps will list the wallets which are present in the browser and user will be able to interact by his choice.

Working:

Each Wallet Provider will be announced with the following interface

EIP6963ProviderInfo 

/**
 * Represents the assets needed to display a wallet
 */
interface EIP6963ProviderInfo {
  uuid: string;
  name: string;
  icon: string;
  rdns: string;}

Uuid	Unique Identification Id
Name	Your Wallet Name
Icon	Your awesome Icon in svg 96x96
Rdns	Domain Name System in reverse syntax ordering such as  com.example.subdomain

DApps and the Wallet are expected to emit an event and instantiate an eventListener to discover the various Wallets. 

The DApp MUST listen for the EIP6963AnnounceProviderEvent dispatched by the Wallet via a window.addEventListener() method. EIP-6963 is backward compatible and doesn’t hinder if the wallets are still under consideration to upgrade or doesn’t want to upgrade.

Implementation:

WalletSide:

DApp Side:

Security Considerations:

1. Prototype Pollution of Wallet Provider objects

Prototype pollution is a JavaScript vulnerability that enables an attacker to add arbitrary properties to global object prototypes, which may then be inherited by user-defined objects. Browser extensions, and therefore Wallet extensions, are able to modify the contents of the page and the Provider object by design. Wallets are considered to be a trustful source hence there's a tradeoff that needs to be made between security and web compatibility that Wallet implementers are expected to consider.

2. Wallet Imitation and Manipulation

Since Wallets can specify the UUID and Svg in the EIP6963ProviderInfo, there is a great possibility of wallet’s imitation and impostring. DApps are expected to look for this behaviour and make sure that in case of UUID duplication proper sanitization steps are followed to not interact with imposter DApps.

3. Prevent SVG Javascript Execution

Since Wallets can pass SVG in EIP6963ProviderInfo, there is a possibility of Cross Site Scripting via SVG images. Javascript executes within the context of the page and can therefore modify the page or the contents of the page. DApps are expected to apply sanitization techniques on prevention of such executions via SVG images.

4. Wallet Fingerprinting

Wallet providers can now consider whether or not they wish to announce themselves to all pages or attempt alternative means in order to reduce the ability for a user to be fingerprinted by the injection of the window.ethereum object. An example, of alternative flow to consider would be to wait to inject the provider object until the DApp has announced the eip6963:requestProvider. At that point, the wallet can initiate a UI consent flow to ask the user if they would like to share their wallet address. This allows for the Wallet to enable the option of a “private connect” feature.

Final Thoughts:

Overall EIP-6963 is going to be a game changer in the user’s experience of interacting with DApps and it will allow new players to come into the wallet space and have a fair chance of competing with other wallets. The security considerations should be kept in mind while racing towards the newer implementation and often security is neglected to be the one to implement the newer things.

References:

https://eips.ethereum.org/EIPS/eip-6963

https://eips.ethereum.org/EIPS/eip-1193