EIP-1102: Opt-in provider access

So, re: The UX of EIP 1102 - looking for a way to guarantee both user control of privacy and preserve the relative ease of UX available with current Metamask/web3.

My general idea to solve this is basically to find a way to automatically push a refresh and injection of window.ethereum based on an application requesting that, upon install of Metamask, their still-open tab will be able to have a pending request of availability somehow notify the user that they’ve requested access, and then upon access being granted, initiate the reload and window.ethereum injection. Doing so would not expose any user information without their request, while still allowing applications to have relatively seamless UX flow (with the workflow, 1. Request Metamask install and/or request acceptance, 2. Detect Metamask has been opened and accepted). The en-queuing of such a request could be easily accomplished by storage of a specially keyed cookie or localStorage object (e.g., _web3_permission_pending_request). Any risk of accidental acceptance of a website’s pending permission requests could be mitigated by a combiation of (a) only showing requests originating from open tabs or domains, and (b) sufficiently clear UX on the part of the ethereum provider (e.g. Metamask). I strongly encourage an approach like this for keeping UX simplicity.