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 — plans 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.

Breaking change

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 remember 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 sites 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.

Draft UI for MetaMask’s user-approved account access implementation

Privacy mode

The MetaMask settings menu will expose a new “privacy mode” option that can be used to opt in to and out of this privacy-preserving behavior. If “privacy mode” is enabled, MetaMask will not automatically expose users’ account addresses to the sites they visit. Instead, sites must specifically request access to see users’ accounts. If “privacy mode” is disabled, legacy behavior will be maintained and MetaMask will automatically expose users’ account addresses to websites. This means that legacy dapps that are not immediately updated to support this change can still be used by disabling privacy mode.

On November 2nd, 2018, MetaMask plans to release these changes with “privacy mode” disabled by default. This option will eventually be enabled by default in a future release.

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:

Preparing your dapp

As of MetaMask v4.14.0, the provider is already available at window.ethereum and it exposes the new enable method. Calling this method today won’t trigger an approval popup and accounts will continue to be exposed to dapps until November 2nd; still, dapps can and should be updated as soon as possible to call the new enable method to ensure compatibility with the upcoming change.

To fully test a dapp against a version of MetaMask that includes this breaking change:

  1. Download a custom build here.
  2. Install the build following these instructions.
  3. Enable “privacy mode” in the MetaMask settings menu.
  4. Report any issues on Github.

Conclusion

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.