On November 2nd, MetaMask and other dapp browsers will stop exposing user accounts to webpages by default. Instead, dapps must request access to user accounts using a new provider method:
provider.enable(). This developer-focused article contains all notable changes for the upcoming November 2nd MetaMask release.
Previously, dapps would access the MetaMask provider by using
window.web3.currentProvider. While this will still work, the new, standard way to access the Ethereum provider in a Web browser is to use
2. Call ethereum.enable()
The MetaMask provider won’t be populated with user accounts on page load. This means that any Web3 call or underlying RPC call that requires an account — such as sending transactions or signing messages — will fail by default. To access user accounts and initiate account-requiring RPC calls, dapps must first call
ethereum.enable(). This method returns a Promise that resolves to an array of user accounts once access is approved for a given dapp. Once this approval happens, MetaMask will populate its injected provider with user accounts like normal.
3. Learn about “privacy mode”
Initially, MetaMask will expose a new “privacy mode” settings option for users to opt in to and out of this privacy-preserving behavior. If “privacy mode” is enabled, MetaMask will not automatically expose user accounts to webpages. If “privacy mode” is disabled, legacy behavior will be maintained and MetaMask will automatically expose user accounts to websites as it did in the past. This means that legacy dapps that are not immediately updated to support this change can still be used by disabling “privacy mode.” However, this “privacy mode” option will eventually be defaulted to “on” and finally removed in future releases, so dapps should avoid relying on this setting and update as soon as possible.
4. Test your dapp
MetaMask v4.14.0 includes the new
ethereum.enable() method, but this method won’t actually do anything yet. For now, this method will return a Promise that immediately resolves to user accounts without showing any approval dialog to the user. This mock API is intentional: it allows dapps to update their codebase in production as if the change was already live, without bothering users with approval dialogs before the planned release date. Still, the most exhaustive and realistic way in which a dapp can be tested against this change is to download and install the very release that will be cut on November 2nd. To do this, use the following instructions:
- Download a custom build here.
- Install the build following these instructions.
- Enable “privacy mode” in the MetaMask settings menu.
- Report any issues on Github.
Thank you to the community members who have helped define and improve this proposal over the past couple weeks. As always, we appreciate your feedback!