Metamask-extension: Deactivating privacy mode doesn't seem to have effect

[wbt]

Describe the bug clearly & concisely
The Privacy Mode setting description (in Settings) says "Websites must request access to view your account information." There is a slider. Whether this is activated or not, the request popups appear. If I click "Cancel" instead of "Connect," the website does not have access to the account information.

To Reproduce
Steps to reproduce the behavior:

1. In Settings, clear privacy data and deactivate privacy mode (set the slider to the left, gray, "off" position).
2. Visit a dapp that requests identification of accounts, which may have been tested working with privacy mode active, where the popup in step 3 is expected.
3. See the popup requesting access to the account.

Expected behavior
When Privacy Mode is disabled, Metamask has different behavior than when it is enabled. The difference should be the one described just above that setting toggle, namely that when privacy mode is active (and only when Privacy Mode is active) websites have to request access to account information.

Browser details:

• OS: Windows 10 Pro
• Browser: Chrome up-to-date (71.0.3578.98 (Official Build) (64-bit))
• MetaMask Version 5.2.2

Additional context
It's possible there is an issue in the coding of the dapp front-end, but if so it must be a common issue.

For example dapps where this can be observed, check out games like https://www.cryptokitties.co/ (click "start meow" for the popup) or https://monkey.game/ (load homepage for popup). If you click "cancel" on the latter, there is a Javascript popup saying "please allow access or disable metamask privacy mode" but per this Issue, disabling privacy mode and reloading won't be enough.

If there is an intentional decision that the Privacy Mode setting not offer any meaningful choice to the user or change in behavior, it should be removed from the interface; I would not recommend this decision at present.

[ghost]

can you please try your reproduction steps whilst using

• https://gitcoin.co
• https://www.cryptokitties.co

My tests show that gitcoin asks depending on the setting, and cryptokitties asks always, independent of the setting.

Possibly its a bug on the cryptok. side, or they choose to always ask for a permission (which feels like a good practice to me)

[wbt]

If privacy mode is OFF, the expected behavior is that the website automatically has access to all of the information it would get if I clicked "Connect" in the popup. The call to enable() should resolve true immediately (without caching that site as having received explicit user permission) instead of presenting a popup. There is a blog post about this as optional here.

[ghost]

can you please check with gitcoin.co?

EDIT: you are of course right that MM behaviour should be consistent with its messages to the user.

[wbt]

Yes, I still have to login with Metamask on Gitcoin using the popup to connect, even when Privacy Mode is disabled. However, the fact that it happens on any site is enough to demonstrate the bug; it does not have to happen on every site or any specific site, even though it apparently does.

[bitpshr]

Hi @wbt, thanks for reaching out. The issue you describe is intended behavior, though we will update verbiage on our end. Check out the response at https://github.com/MetaMask/metamask-extension/issues/5699#issuecomment-436967312 for more information, and don't hesitate to let us know if you have additional questions.

[ghost]

@bitpshr , you should not close issues that fast. This issue here requires an action before it is closed, as @wbt has clearly a point.

@wbt

Yes, I still have to login with Metamask on Gitcoin using the popup to connect, even when Privacy Mode is disabled.

This is not the case on my system: gitcoin.co clearly "listens" to the "Privacy Mode" setting.

However, the fact that it happens on any site is enough to demonstrate the bug;

I attempted to isolate the issue, and cross-check, and asked for feedback.

In any way:

The problems are:

• Asking for permission should have been a functionality right from MM version 1.0
• The positive step to introduce it later had a flaw: the misleading naming of the option ("Privacy Mode"), as stated already here: https://github.com/MetaMask/metamask-extension/issues/5699#issuecomment-437539274
• The team closed the issue #5699 without taking an action to eliminate the flaw (thus new users don't hit on the same issue).

Possible Actions

• Remove "Privacy Mode" immediately, both, as a term and as a functionality (e.g.: dapps MUST ask for permission).
• dapps which fail to adopt to this new security measure can stop functioning (this is a good thing, live dapps must be maintained and apply security-fixes immediately).
• If it is necessary to keep Legacy-Apps functioning, then this should be done via an "Expert" Option (not accessible for normal users).

[bitpshr]

@wbt: The blog post we published on privacy mode already describes the behavior you've filed here:

At first, Privacy Mode will be opt-in (and turned “off” by default). Even if you haven’t turned Privacy Mode “on” yet, we want to make it clear what’s happening under the hood, so you may start seeing the “Connect to this site” dialog as you use your favorite dapps.

@lazaridiscom: Thanks for your input. We've already been planning to remove "privacy mode" on a future date that's coordinated with other browsers including Coinbase Wallet, Status, Mist, and others. This date is still being discussed and will be communicated to developers soon.

To summarize:

1. The settings option description is accurate: "Websites must request access to view your account information." This does not say anything about stopping the dialog from showing.
2. The blog post is accurate: "Even if you haven’t turned Privacy Mode “on” yet, we want to make it clear what’s happening under the hood, so you may start seeing the “Connect to this site” dialog as you use your favorite dapps."
3. Privacy mode will be removed in the near future, so this all goes away regardless.

As far as I can tell, there is no additional action to take, so this issue should remain closed.

[ghost]

As far as I can tell, there is no additional action to take, so this issue should remain closed.

It is sometimes fascinating to see how you (the MM team) don't see how you confuse your users.

A tiny explanation within the UI can fix things for now (see #5993)

[wbt]

1. The settings option description is accurate: "Websites must request access to view your account information." This does not say anything about stopping the dialog from showing.

Yes, it does. It indicates what happens if the option is TRUE, which also indicates that the absence or inverse of that corresponds to setting the option to FALSE. If the behavior of the software described is not different between TRUE and FALSE, it is not the proper description for that setting as it does not distinguish between the options.

It would not be hard to implement the previously implemented behavior. When user approval is requested, there is already code to check the cached permission list and return approval pretty close to right away if user approval has been previously given. It would not be hard to return approval at least that quickly if(privacy mode = false). Then, the software behavior would be consistent with documentation, explanations, and user expectations.