Add way to bypass privacy mode on a per-site basis

[danfinlay]

Privacy mode is a great improvement for how we expose identifiable information to sites, however if we roll it out today, we will break every site that is statically hosted or not actively maintained. This violates one of the basic principles of the web.

We should design & implement a method to force-sign-in to sites that have not implemented 1102 sign-in methods. Possibly a generic "sign in" button on the MetaMask popup.

[aakilfernandes]

One way to do this would be to use getter functions for web3.eth.defaultAccount and similar sensitive calls.

web3.eth = {
...
get defaultAccount() {
   if (!confirm('Allow this site to read your data')) {
      return
   }
}
}

[danfinlay]

You'll be excited to hear we're working on a robust system for managing permissions like that, already in working proof of concept phase.

[danfinlay]

The difference here is that this issue is for supporting sites that are not making any code changes.

[danfinlay]

Oh I see, we could also prompt for permission on request of restricted properties. That's not a bad idea.

[aakilfernandes]

Yup, and since dapps are expecting synchronous data, I think this may be your only option. Any custom user interface will have to be asynchronous. confirm has the benefit of being synchronous

[danfinlay]

Sync actually isn't an option, because we can't hit the background process synchronously. If we allow this prompt to be called in-page, then sites could manipulate its communication method to force approval. Approval has to be from the background, and so has to be async. What we can do is allow calls to eth_accounts to trigger user approval, which is actually a very old idea by @frankiebee that I have no idea how we didn't just do.

[aakilfernandes]

Ah, that makes sense.

[aakilfernandes]

Maybe just the benefit of fresh eyes :)

[whymarrh]

Duplicate of #6320, which is being used to track progress