Revise Permissions Control

[bravetarget]

Аbstract With the ability for a user to block out an entire domain, an accidental rejection on the initial auth leads to an undesirable UX. Especially for users unfamiliar with Waves Keeper.

Motivation and Purposes It'd be nice if we did not have to teach users how to re-enable permissions for a domain. This seems like an unnecessarily overreaching security feature and ultimately creates room for user error rather than protecting them. Consider these points:

• If a user does not actually want to use a dapp, they will not visit that domain. How many scenarios include a user denying a domain to communicate with their Waves Keeper, but also wish to remain on the site for other reasons? I would say virtually zero.
• If a dapp's front end is badly designed, to the point a user would have to reject the domain, they probably should just navigate elsewhere.
• There are many other ways to protect agains potential abuse

Solution

• Domains are authorized by default, but with low limits on sign requests, messages, etc.
• If a domain meets those limits, then an auth/reject prompt arises.

Backwards Compatibility This would be cleanly backwards compatible, and improve the UX for dapps

Examples and Implementation Other browser wallets experience this same problem. However, I see this as a trait of nascent software rather than necessary security features.

[msmolyakov]

I apologize that there was no response to you for so long. And I am grateful to you for your ideas, we will take that into account.

Btw, we've already simplified the process a little at #115 - if initial auth is rejected, the domain is not added to the blacklist, so later it can resend the request. In the near future we will continue to make the process of using a Keeper more convenient for all the parties.