-
Notifications
You must be signed in to change notification settings - Fork 5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add method to revoke token allowance #8174
Comments
I'd love to be able to see my outstanding token allowances
|
just found out about https://approved.zone/ - they might have some useful findings |
Would love to see some movement on this. When revoking using https://revoke.cash, https://approved.zone or https://tac.dappstar.io, the prompt makes it appear you are giving them an allowance. The ability to revoke (without trusting yet another third party) is super basic...like removing old oauth authorizations for something you used once and no longer trust. Metamask could offer this as a periodic security recommendation: "Do you still want to let these smart contracts transfer tokens on your behalf?" |
No progress? It's complicated to trust external sites. I would love to do it via Metamask |
+1 |
we should see this in metamask right away and not discover this after it is too late |
I've been working on exposing token allowances in MM UI. Also, we want to allow users to submit an allowance update directly from the UI. I've considered two primary user flows:
Also, as thinking about this UX, I'm wondering about the vocabulary we should enforce during this flow:
In order to present a coherent flow, we may want to update the confirmation screen copy; a first approach here To keep users updated about their given allowances, we should send monthly reminders to review the allowances. A proposed notification here |
Hi this seems like a basic feature with major implications that can be "easily" exploited by malicious dapps. Relying on third party sites to revoke token allowances seem like a chicken and egg problem/catch 22 for the user, how are we supposed to revoke allowances from the sites that revoke the allowances themselves ? The only safe option for the time being is creating entirely new wallets to mitigate any risks of:
the negatives of creating new wallets is that any previous contract interaction, such as being grandfathered into a protocol for being a previous user, is lost because the new wallet address does not get the old "benefits", one way around this is asking each dapp dev to change the address manually, which is highly unlikely to happen. It has been quite hard to find this thread, i found it because google had indexed the twitter page https://twitter.com/metamask/status/1245769348364603392, i believe that this issue should clearly be communicated in a blogpost by the metmask team and advise for official and "safe" ways to proceed with revoking token allowances meanwhile this feature is implemented in the wallet UI. from my understanding from the twitter post Metamask officially endorses I believe integrating this feature directly in the metamask UI would greatly benefit the security all users of the wallet. |
FYI etherscan also recently added one https://etherscan.io/tokenapprovalchecker |
EDIT:
Trying click on REvoke button it not change the network. |
some of the stakeing has been done and now my wallet is hacked as i had one address which has unlimited allowance and if i revoke the allowance whether is is possible again them to hack my account. pls inform me whether i can change the linked wallet in staking, if it possible please reply |
FYI, I developed a web dapp to provide easy control for allowances management. |
This is nice! Will you public the source code of this? Or may I ask where to find a source to map contract addresses to service names? |
How does this work |
Many exchanges and sites involve granting a token allowance, which leaves the user's token balance exposed to the delegate contract.
As the user's wallet, we should make it easy to revoke any permission that we make it possible to grant.
Where should we put this?
Our current permissions system is largely per-site, but allowances are per-contract, so while it may make a lot of sense to show the allowance in-line with a site's permissions, it isn't a perfect representation.
We may also want to show outstanding allowances in the token's view.
The text was updated successfully, but these errors were encountered: