Can this be modified so that it is calling its own personal_sign_swie method, probaly not that method name though, so we can both enforce the data structure and so that, from the extension level, the request could be modified to represent the contract wallet if one is in place? (I am helping building an ERC-4337 platform and this would be very helpful personal and generally useful too)
I would like to say that for many less technical users the current required information is actually more intimidating and seems riskier than what users may be more familiar with which usually stress that they are simply signing a simple plain text which cannot be used for nefarious purposes. There have been several phishing scams that got users to sign buy or sell orders and other types of data that resulted in theft of assets so this is something end users can be rightly wary of.
For example here are some common signatures to verify: Imgur: The magic of the Internet
For that reason I think sticking with 191 over 712 could be a better choice, even though I do think 712 is technically the right choice.
This is partially why I am suggesting the personal_sign_swie method because the 4337 wallet I am building flags all signature requests for non transactions like this as potentially dangerous. (and actual transactions are provided a preplay showing what events, balance changes, and source code for contracts interacted with).
Can someone please link to any (all) research and discussions regarding user safetyā¦e.g. phishing considerations, domain binding, etc. etc. etc. from this EIP or others. I know there have been a ton of these but over the years but they arent where they need to be which is in the spec itself or linked to from the spec itself.
Right now the only real guidance is āBoth the wallet and relying party have to implement this specification for improved security to the end user. Specifically, the wallet MUST confirm that the message is for the correct domain or provide the user means to do so manually (such as instructions to visually confirming the correct domain in a TLS-protected website prior to connecting via QR code or deeplink), otherwise the user is subject to phishing attacks.ā and franklyā¦thats just not going to get the end user experience where it needs to be.
4 Likes
@wyc are you guys still working on this EIP? What is the status of this?
The industry needs this
The industry needs this functionality, and without a standard approved wallets cant start implementing protections on their end.
Wallets and Browsers Parallel
I see an interesting parallel to the Internet in how browsers are trusted with protecting cookies and only allow certain sites from certain domains to access them. The role of wallets in this EIP is similar - the wallet needs to ensure that the domain and message is correct.
I am not worried about message complexity
I have seen some comments on the fact that the message structure is intimidating due to eip712.
At the end of the day wallets will hide this complexity and show easy UI to the users.
Users should never see the actual messages being passed.
Users will trust wallets like they trust browsers with cookie protection
Just like users today trust the browsers to keep their cookie safe from unauthorized domains - the same will happen to wallets, users will most likely not double check and read the actual low-level message themselves.
Users will trust wallets like they trust browsers with TLS
Just like you donāt read the TLS certificate messages and signatures yourself - you trust the green lock icon in the browser to tell you that communication with the website is secure.
Im sending these messages here on this forum without verifying anything about how the encryption actually is established.
Should we give wallets this trust?
The whole Internet is built on this ātrust the browserā model (and therefore all online banking handling trillions in assets). It is clearly successful. Therefore it makes sense that web3 follows the same model. Let me know if I am missing something.
Conclusion
Therefore, I do not share the concerns about the message complexity/intimidation.
In fact, we need to move away from showing raw-text and do real UI in the wallets.
Importance of this EIP - LFG
As long as there is no standard we cant get to work as an industry and build - thatās why I would love to see more activity in this EIP.
Looking forward to more news about this eip! (and of course happy to help in any way I can)
2 Likes
Hey Ivan, absolutely we are still working on this! Iām glad that you share our excitement about how foundational this work is for the ecosystem, and Iām happy to share that there are hundreds of projects using this specification already. Would you like to join our next community call and chat there? You can listen to the one that happened today here:
https://twitter.com/signinwitheth/status/1613596784538030081
While I sympathize with your view (and remain optimistic) that eventually the wallets will abstract message signing and create trusted signing UX modals with potentially complex message formats under the hood, this hope simply didnāt match up with our developer interviews across hundreds of dapps and many wallets, including MetaMask. In short, while you may not be worried about message complexity, implementers areā¦so if you have a proposal that is a shoo-in for introducing a generalizable trusted consent screen for complex message formats in EIP712 then letās hear it!!! So far, we havenāt been able to get the community to align around such an approach, and there are 3 versions of EIP712 so you have to be specific about which one you are referring to. Are recursive data structures something that all wallets will be able to implement and display a delightful+secure UX around (v3)? How widespread and correct are EIP712 implementations today? Are we committed to EIP712 or is there something potentially even better, such as how some integrity objects like biscuits and macaroons can be implemented via signed protobuf object or even COSE. We need concrete proposals on how this would happen for this direction to be a viable path, but weāre totally open to it in future iterations of SIWE. So please join the community call or discord and we can continue the discussion there.
1 Like
Hey @wyc thanks for coming back! I will listen to the community call and join future ones. Are they weekly/monthly?
Also - if you are interested I would love to interview you on our youtube https://www.youtube.com/channel/UCgWS9Q3P5AxCWyQLT2kQhBw
Reasoning of Wallets
Interesting points about the implementers as it is key they are on board.
Do we know their reasoning for it?
Do they envision a future in which the users will read and verify the full messages?
It would be great to interview end-users and do end-user testing.
Wallets will choose whatever will make them outcompete other wallets. (interesting episode on wallet competition The Crypto Wallet War is coming | E08 - YouTube)
So if we have users preferring a solution wallets will consider it seriously, and thatās also how we ensure that we build things the users like and leads to mass adoption instead of building tech for other techies 
One concern I can understand is that of being responsible for this secure UI. I can imagine wallets wanting to put all responsibility on the user to read and verify everything.
But thatās not how browsers are doing it with all Internet security, and where would the web be if users had to verify all SSL encryption etc.
So maybe it makes sense to have a format in which some wallets show the raw-text and some wallets can do a nice UI and we let the market decide who wins.
Specifics of EIP721
Regarding the message types - I need to do more homework as I am only familiar with them on a very high level. And I am probably not the correct person to give opinions on the exact technical pros and cons of each format.
Steps ahead
I am not sure where we are at exactly in the process but I would propose something like this:
- Create an official working group consisting of wallets, projects, infra providers
- Come up with milestones, for example - agree on message format, agree on desired UI, etcetc
- Set deadlines for each milestone
- Do regular checkins with the working group
Do we have some sort of official working group yet?
Hi everyone!
I stumbled upon an ambiguity in this EIP, can you please help resolve it?
1 Like
Pointing out one concern with this: making a blanket statement that signing āa simple plain text CANNOT be used for nefarious purposesā isnāt totally true. What the end user signs is a hash of the message, and therefore if thereās any option to change parts of the message, an attacker could use that to adjust the message hash the user signs to something the attacker wants.
For example, taking a scenario of a particular NFT marketplace uses EIP712 messages for creating sale offers, and a separate website uses EIP191 āsimple plain textā messages to log in: Common structures already in the wild for those sort of use cases have either ānonceā values or datetime values in the structure of those messages that can be manipulated. For this example, letās say the marketplaceās EIP712 message has a āvalid untilā date that only needs to be in the future, and the websiteās login prompt has a ānonceā value that any random value is valid for. If Alice has a specific NFT that Eve wishes to attempt to spearphish Alice for, Eve could construct a āsell offerā in the marketplaceās EIP712 format, hard-coding Aliceās holding address and the NFTās identifiers. Eve then makes a fake website emulating the website that uses EIP191 text messages to log in. Because Eve can change variables on both of the text messages, she then has to search for a hash collision between them. Because of the birthday problem, this is much easier than just trying to find a collision for a single hash value.
Once Eve finds a āvalid untilā datetime value and ānonceā value that cause both the EIP191 text message and the EIP712 message to hash to the same value, she can send Alice a link to Eveās fake site, and when Alice clicks to ālog inā, the EIP191 message that pops up is a āsimple plain textā message, but if Alice signs it, Eve can attach that signature to an EIP712 message and steal Aliceās NFT.
Even if a text message appears āstaticā (the login text message to sign is just āSign this message to log into example.comā), and Alice knows that, Eve could still use tricks like inserting zero-width-spaces to make the text message look the same rendered to Alice, but actually hash to something different.
Thereās more that wallet software can do to help users determine if the message is not what it should be, but I think the answer is not to train users to expect āa simple plain text CANNOT be used for nefarious purposesā.
In this draft EIP, the motivation is stated for ānon-blockchain servicesā. (The motivation could be more clear about what is its purpose, separately from what already exists and does not exist.)
So considering the motivation, several parts of the specification seem inappropriate:
- chain-id ā websites are off-chain and therefore chain-id is not relevant
- āā¦ For Contract Accounts,ā section ā contracts already have a mechanism for logging in, and this contract authentication is entirely out of scope of the motivation
This proposal will be improved if the chain-id section is removed. Please note that customers have a limited attention span, and the MetaMask mask wallet has a strictly limited number of pixels (that canāt be resized) for reviewing message signatures. Therefore, every inclusion of an unnecessary thing, like chainID, reduces the security of the system.
This note is not my comprehensive review of EIP-4361 DRAFT.
1 Like
While replay attacks targeting the sign-in process isnāt very common especially not when it comes to chain ID, I still think itās worth it. This piece of information doesnāt necessarily need to be seen by the user, wallets can improve this UX by perhaps checking the chain ID against the currently connected chain ID? Just some random thought by a non-UX person, but again I still think itās necessary. Your points are valid but they seem to be design problems, not technical ones.