Presence of Metamask alone helps fingerprinting

[ItalyPaleAle]

Describe the bug With #4703, Metamask does not expose your Ethereum addresses until manually activated, making it less easy for websites to uniquely identifying a user across the Web.

However, the sole presence of the Metamask extension can be used for fingerprinting. When Metamask is installed, every website has access to window.web3. That is another identifying factor that can be used by websites to fingerprint users. As long as Metamask is used by a small(er) subset of users, in fact, it is a powerful factor that can be used to create individual fingerprints (together with many other factors).

A (simple?) solution to this is to disable Metamask in every website by default. Users will need to click on the extension to activate it for a website, and then the page is reloaded and window.web3 is injected. Metamask can remember websites on which it should be enabled.

To Reproduce (REQUIRED)

1. In a website, check for the presence of window.web3
2. Use the result of that (true/false) as part of the factors used to create individual fingerprints

Expected behavior

Metamask should not inject window.web3 in all websites by default.

Browser details (please complete the following information):

• OS: All operating systems (but currently on macOS)
• Hardware Wallet: none
• Browser: Firefox 79 (but should apply to every browser)
• MetaMask Version: 8.0.8

[Gudahtt]

Great point! This is not good.

We are planning to stop injecting web3 relatively soon, but the same problem remains with the provider itself (window.ethereum).

Users will need to click on the extension to activate it for a website, and then the page is reloaded and window.web3 is injected. Metamask can remember websites on which it should be enabled.

This would be a fairly drastic change in behaviour that would surely confuse and frustrate many users and dapp developers, so I doubt we would do something like this in the short term. But if we made this a setting that was off by default :thinking: That might work!

I recall seeing another suggested solution to this that would involve changing the provider API, so that dapps could connect over postMessage rather than via window.ethereum. Of course that wouldn't solve this problem until we stopped injecting window.ethereum though, so... that's years away optimistically, if we did go down that path.

[ItalyPaleAle]

Thanks for considering this! 😄

I agree on the concerns on usability. Even with caching the response, it can be confusing. For example, if the dapp redirects the user to a different page, then even reloading the page could not show the dapp.

The model of "click to enable, then reload" is not new. At work, I use an extension for Chrome called Buffer who can be set to behave that way, although it's not the default behavior.

If this behavior was available but off by default, that could be a good compromise? Users who are more concerned about their privacy could disable the auto-injection of window.ethereum and because it's something they actively do, they shouldn't be surprised by the behavior.