Signing into the new Internet
The concept of “signing in” has been part of the general user experience of using the Internet since the advent of “Web 2.0” (when websites moved from being “web pages” of static content, to “web apps” that users could interact with). “Signing in” is a key part of the security of web data. In formal terms, it fills the role of authenticating the user (the application knowing who the user is. This is different than authorization which is the concept of determining what content the user has access to, after they’re authenticated).
For most Web 2.0 applications, a user’s authentication status can only be in two states: “signed out” (user can only see public data) or “signed in” (user can see content private to them and tailored for them). The user experience of most Web 2.0 applications is users must sign in first, and then spend most of their time authenticated (with their browser/devices keeping special metadata/cookies to mark them as trusted/authenticated for a long time).
Because users spend most of their time in Web 2.0 applications signed-in, they’re most used to seeing data associated with their user account presented in a second-person perspective (“This is your timeline”, “You have 10 photos”, “Your friend Alice is online”) rather than third-person terminology (“This is User #123’s timeline”, “User #123 has 10 photos”, “User #456 is online, and they’re friends with User #123”). This works well for situations where users are only ever “signed out” or “signed in”, however there’s a third state a user could be in:
This third state is when the user has claimed “I am User #123”, but hasn’t yet proven they are. They might have given partial credentials that provide some proof they’re User #123, but not sufficient proof for the application to trust it for important actions. In Web 2.0 applications, this sometimes happens for user interactions that are key to the user’s security like changing a password. If you have an active session for a Web 2.0 application (you’ve presented the application with a token/cookie that they trust you’ve already signed-in) and you go to set a new password, many times that session token won’t be enough and you’ll need to enter your (current) password in the same action as setting the new password, to verify at a stronger level of confidence that the person interacting with the application really is the user in question.
The Next Version
The concept of only being “partially signed-in” is a relatively rare state of being for a user in Web 2.0 applications, but with the advent of “Web3” technologies, there’s a different paradigm to explore. Web3 applications are generally backed by blockchain-based data, which is both public and anonymous initially. All actions a user wants to do on the blockchain need to be authorized by the user (usually using a “wallet” application, separate from the web application), so are more like the “you must enter your password again in order to take this action” actions in Web 2.0 applications.
The interaction between wallet software and web applications uses the terminology “connected” to indicate the state where a user has indicated who they claim to be (“I am User #123”), but has not yet proved it. For many Web3 applications, there’s no additional need for the user to prove they are who they say they are, since any action they take will force them to authorize the action (“Sign” a message or transaction; same verb as “signing in” for Web 2.0 applications).
But an issue arises in terminology for Web3 applications: many of these applications consider “connecting” a wallet account sufficient to switch the terminology to second-person on the web application (“Thanks for connecting your wallet; here is the balance of your account”). Most wallet software only allows connecting using accounts it knows how to properly authorize, but tools like Impersonator exist that make it trivially easy to “connect” as any wallet. This allows bad actors to create videos of themselves “signed into” someone else’s account, which can give them an edge to use social engineering to trick the true owner into believing the bad actors do have access to the user’s credentials.
Fixing the issue
While simply educating users about the possibility of spoofing a “connected wallet” could alleviate the concerns somewhat, to get at the crux of the issue requires some changes on the part of Web3 application developers. I think we need some new UX grammar to make clear when the user is “connected, but not yet proven to own this address”. Some Web3 applications have the concept of a watchlist/favorites/bookmarks listing, which allows users to remember which addresses they “care about” (whether they are the controller of that address or not), which I think is a step in the right direction.
For the MoonCatRescue project, we’re addressing this concern by making sure to not refer to a specific address as “you” or the assets controlled by an address as “yours” unless actual proof has been given that the current user is the owner of that address. Beginning in June 2023, we will use the Sign-In With Ethereum (SIWE; ERC4361) standard for applications going forward to make this proof, which has started to be implemented into wallet software to make it easy for users to see when a message they’re being asked to sign is indeed just an authentication request, and not something malicious.
