Skip to content
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

Aggressive notification about blind signing #665

Open
tomasz90 opened this issue Oct 19, 2024 · 3 comments
Open

Aggressive notification about blind signing #665

tomasz90 opened this issue Oct 19, 2024 · 3 comments

Comments

@tomasz90
Copy link

tomasz90 commented Oct 19, 2024

Description

I see aggressive notification about blind signing. Why aggressive? Because it is displayed EVERY time when I interact with whatever protocol via metamask or rabby wallet. When I have to click continue anyway it almost feel like pain (UI/UX design)

Your environment

Ledger Flex

Steps to reproduce

Just connect to rabby wallet and interact with for instance jumper exchange.

Expected behaviour

  1. Option:
    This behavior can occur, but user should have at least possibility to disable such screen in settings. User should see icon with exclamation mark on second screen as it is now, and maybe label blind signing It will be enough for an aware user to understand that this is blind singing.

  2. Minimal option:
    If this screen really needs to stay, at least highlight continue anyway button instead, making as default option - really it is strangely uncomfortable to click this button now - this is not even looking like a button..

Actual behaviour

User every time needs to confirm this. Whats more - back to safety button is highlighted, and it really cause "pain" when user have to click the other option.
IMG_20241019_224839194

@tomasz90 tomasz90 added the bug Something isn't working label Oct 19, 2024
@vforgeoux-ledger
Copy link
Member

Hey @tomasz90 ,

Thanks for your feedback!

This UX has been implemented as we want users to actually understand the risks associated with blind signing. The transaction or message data displayed on the Ledger device should be the only elements being trusted. When the parsing is not possible, users should be aware that whatever the software wallet displays, the Ledger device can't guarantee that they will sign the same data.

Why aggressive? Because it is displayed EVERY time when I interact with whatever protocol via metamask or rabby wallet.

You point out exactly the problem, and we're working hard to solve it. I invite you to take a look at the ERC-7730 that we're developing. The aim is to drastically increase the clear signing coverage of dApp contracts in the ecosystem, so that blind signing becomes increasingly rare, since these contracts can be added to the registry so that their methods can be interpreted on Ledger devices.

While we are preparing for a first version of this solution to be up and running, we are aware that users who are used to interacting a lot with smart contracts would prefer to have one less screen to validate. Nevertheless, we have already reduced the friction after taking user feedback into account (see #620), and believe that we are striking the right balance.

@vforgeoux-ledger vforgeoux-ledger removed the bug Something isn't working label Oct 31, 2024
@tomasz90
Copy link
Author

tomasz90 commented Oct 31, 2024

I read the beginning of erc-7730, but still dont get it... What if a user signs malicious tx, executes a function having exactly the same 4 bytes signature as standard ex. uniswap router function, but underneath it will be code that only drains tokens?
In my opinion, 'clear signing' would only work when a user see an output of a transaction. For example, in the Rabby Wallet, a simulation is shown on the confirmation screen, there is tokens out, tokens in, as well as their usd value...
Am I missing something?

@apaillier-ledger
Copy link
Contributor

Hello @tomasz90,
Transaction simulation is indeed something different, however with ERC-7730, just like with today's plugins that you can install (1inch / Lido), it will check not only the selector from the calldata but also the chain ID and the destination address from the transaction RLP, so there is no way the app would start trying to clear-sign a fake Uniswap function thinking it really is the one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants