Restricting this functionality to their domain means that nothing has to be injected into every page. Popup means any page can really easily initiate the whitelist process without having to write browser vendor specific extension interactions.
-
Show this thread
-
Short term solution would then be to add whitelisting as an opt-in feature (so you don't break existing integrations and make people regret writing their app to depend on Metamask). Security conscious users can opt-in right away and app developers can plan for deprecation.
1 reply 3 retweets 20 likesShow this thread -
In the meantime, I'd recommend users disable Metamask by default in their browser and then enable it when they want to use it. Unlike unlocking a wallet, I wasn't able to detect (from an already open and unfocused tab) when a disabled extension was enabled.pic.twitter.com/Tn3GCVeMuH
4 replies 12 retweets 44 likesShow this thread -
Some UI improvements would also help the transaction spoofing example I gave. The browser should switch to the tab that created the transaction. The confirmation window should probably have a brightly colored banner that says "http://example.com created this transaction."pic.twitter.com/eYJ60CpZVN
2 replies 3 retweets 31 likesShow this thread -
Metamask and other browser wallets are in a tough position though with these transaction popups. If a legitimate dApp could put a custom message in the confirmation window then an attacker could mimic it.
1 reply 1 retweet 18 likesShow this thread -
I'd love to see is the ability to use an ENS address as the recipient field in a transaction. For
@BloomToken, users are currently interacting with one of two contracts. If our end users saw our ENS address for every transaction then they'd be less likely to fall for a spoof.2 replies 3 retweets 22 likesShow this thread -
I also want to clarify that I'm not saying that people should never use these in-browser wallets. Security is especially tough and nuanced when you are a platform for handling money and user identity. Even harder when you are on the development side of early adoption.
1 reply 2 retweets 24 likesShow this thread -
In-browser wallets should be unlocked *per domain*. An advertiser shouldn't be able to log my ETH address in an unfocused tab just because I want to check on my crypto kitties.
2 replies 4 retweets 33 likesShow this thread -
I'd also love to see at least an opt-in setting that locks my wallet again after sending a transaction. If a dApp wants to send multiple transactions without unlocking between each, they can use `web3.createBatch`. Metamask handles this well already
1 reply 2 retweets 22 likesShow this thread -
An attack that sent ERC20 tokens would be effective. Unlike moving ETH (where Metamask would say how much ETH you are sending), a token transaction would just display the gas price AFAIK. More likely to trick people if they can't tell what is being sent.
1 reply 2 retweets 30 likesShow this thread
John Backus Retweeted John Backus
If you enjoyed this thread on in-browser wallet security, I started a separate thread about community security when running a token sale:https://twitter.com/backus/status/955241954320662528 …
John Backus added,
-
-
I turned this thread into a full blog post and also included a few updates! Checkouthttps://blog.hellobloom.io/using-an-in-browser-ethereum-wallet-heres-some-things-you-should-know-e01304b977e3 …
3 replies 5 retweets 14 likesShow this threadThanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
