The proposal need to spec out exactly what/who these permissions are given to.
Excellent point, I am surprised I didn’t include this.
Initially, as MetaMask can connect to normal DNS websites, I would use the same origin identifier, which should include a prefix of the protocol (i.e. https://dapps.metamask.io
, ens://danfinlay.eth
, or ipfs://IPFSHASH
).
I do agree that we could use this opportunity to push developers towards more decentralized protocols, so at MetaMask we are improving the origin detection of our IPFS resolution.
That said, I think loading over an eth address or ENS name would be a powerful tool, because it allows the creation of on-chain update logic.
I can even see the possible benefits of locking permissions to the hash of a page, so that any page update requires a re-authentication. That’s a big usability tradeoff, but has some pretty great security benefits.
Alternatively, if this could be possible, the web3 browser could generate an hash of the content and linked content to create the origin itself. DNS would then be simply used as a redirection mechanism.
But this would not work for any application that request data dynamically from non-hashed based data source.
Agreed, I’m not sure it’s even possible for us to dynamically check the hash of a page that is loaded, we’ll have to check that out. Some of these goals are very ideal, but may be less practical in the short term, where we’re still building largely on web 2.0 infrastructure.
Regarding the “eth_accounts” request, as I proposed in 1102 proposal, Giving permissions to eth_accounts should return a signed request so that the application can be sure the wallet is indeed in possession of the private key without having to make yet another request.
I don’t think all applications require cryptographic proof of key holding, nor do all accounts have a single key that controls them (contract accounts would be unable to sign in under this model!). We’re currently working on a proposal to integrate your Automatic Authentication Signature
proposal into an additional, optional permission that a dapp could request at its discretion, for when it truly needs to verify a key’s possession.