Breaking Change: No Accounts Exposed by Default
On November 2nd, MetaMask and other dapp browsers will stop exposing user accounts by default. Instead, dapps must request access using a new provider method: provider.enable(). The privacy-preserving strategy is outlined below.
This post was edited on 9/13 to reflect updates made to EIP-1102.
Since MetaMask’s first release in 2016, we’ve aimed to make using the decentralized web simple. When a user loads a webpage, MetaMask automatically injects an Ethereum provider and a Web3 instance for the webpage to use. This allows dapps to access the blockchain, propose transactions, and read their users’ account addresses.
But there’s long been a serious privacy issue with the way this exposure works in the current generation of dapp browsers: malicious websites can use these injected objects to view a user’s active Ethereum address, which in turn provides access to their balance, transaction history, and other potentially-sensitive information. Bad-acting sites can also initiate many unwanted Ethereum transactions on a user’s behalf in the hopes that the user will accidentally approve one.
To improve privacy across the decentralized web, MetaMask — along with other privacy-conscious dapp browsers like Status, Mist, and imToken — plan to adopt a new, safer strategy that will require updates to existing dapps. This article contains everything developers and their end-users need to know about this necessary breaking change, along with code to help future-proof dapps today.
In order to better protect user privacy, MetaMask and other dapp browsers will stop populating the injected Ethereum provider with user accounts by default. Instead, dapps must request access to user accounts, which will in turn ask the user to approve or deny access to the Ethereum blockchain. If the user approves access, the provider will be populated with accounts and the dapp can initiate account-requiring transactions as they normally would.
While MetaMask generally avoids breaking APIs to protect the longevity of existing sites, we believe that a privacy flaw that exposes user accounts and allows unrestricted transaction submissions on a user’s behalf to be sufficient justification.
In order to provide the smoothest possible rollout, dapps must be allowed adequate time to make the necessary updates. We plan to release this breaking change on November 2nd, 2018, to commemorate the EIP proposing this change, EIP-1102.
What this means for users
Over the next few months, users may begin to see more “Login” or “Connect” buttons on dapps. These buttons will prompt a popup from MetaMask (or other dapp browser of choice) asking if the user wants to grant the site access to their public account information. The extension will cache which sites have been approved until the user clears their list.
This UX pattern of requiring user approval before exposing user accounts is very similar to requesting access to a user’s camera or microphone. Ethereum users can reject account access on websites they feel are untrustworthy, making it impossible for such websites to identify, track, and target them. By only populating the injected Ethereum provider with accounts after user approval, users have control over their own privacy.
What this means for developers
The Ethereum provider injected by MetaMask and other dapp browsers will now be available at
window.ethereum for convenience. Before reading user accounts or initiating RPC method calls that require user accounts, such as
eth_sendTransaction, dapps must now request access to user accounts by calling a new method on the provider:
ethereum.enable(). This method returns a Promise that’s either resolved with user accounts after user approval, or rejected with an Error after user rejection.
The following code shows a new way to start up a dapp that can be used today in both legacy and modern dapp browsers:
Making a breaking change has been a difficult decision for us, but we believe it is better than leaving our users prone to privacy violations. We hope this method of provider requesting will pave the way for a variety of more advanced login strategies, such as requesting a specific network, accounts of particular type, or even user-approved personal information.
As dapps switch over to this new pattern, we believe we can begin paving way to a more secure, private, and user-centric web.