Design for Login Per Site

[2-am-zzz]

Related to #714

[danfinlay]

Our Mural for this issue is here:
https://app.mural.ly/t/consensys3989/m/consensys3989/1519847531533/ee821a7d9d623377f2d4b455c4fb50276130ef45

[cjeria]

@danfinlay here's the prototype for feedback. Please comment on the issue.

https://consensys.invisionapp.com/share/BTGBH55MU6N#/283902599_Desktop

[cjeria]

here's the flow from our Mural session

[danfinlay]

I think that flow looks great.

For the account list, I wonder if there's a way we could provide a user deeper "peeks" into the accounts before selecting one. Imagine if they want to log in with their account that holds token X.

This seems to very neatly demonstrate the log in process. I'd want to also make sure we re-visit:

What happens when you click the little fox when logged into a site? Is it obvious this is the current site's account? If a user is just trying to look at another account, are they sufficiently warned that this is essentially logging in as a different user? Maybe hide account list under two options, like "Switch accounts" and "View accounts". (Manage Accounts could open the full page app, and no longer be connected with a single app page).

Thoughts?

[cjeria]

@danfinlay

What happens when you click the little fox when logged into a site?

I don't imagine the fox logo will be clickable or do anything in any step of this proposed flow. Can you clarify which step you are referring to?

Is it obvious this is the current site's account?

I intentionally kept the account selection screen generic to allow users to choose whichever account they like. I assume the user knows? I don't know of course as I have not observed how the majority of users name and manage their accounts (per site?) and I realize i am making an assumption here, but at least it's 1:1 with how we currently display accounts in the account switcher (see screenshots). This keeps the UI familiar and consistent. You mentioned also being able to auto-detect which account has been used previously? That sounds cool. We'd need to do some thinking around how to give users the ability to switch accounts if they use multiple accounts per dapp.

If a user is just trying to look at another account, are they sufficiently warned that this is essentially logging in as a different user?

Good Q! My expectation would be that I get logged out of the dapp automatically if I switch accounts/identities. Unless there's a sophisticated way we can enable multi-account login sessions? Has this been explored?

Maybe hide account list under two options, like "Switch accounts" and "View accounts". (Manage Accounts could open the full page app, and no longer be connected with a single app page).

Can you provide more context? What's the use case/ user flow?

[danfinlay]

I don't imagine the fox logo will be clickable or do anything in any step of this proposed flow. Can you clarify which step you are referring to?

I'm not talking about during the flow you proposed. I think the flow you proposed is great!

I guess I'm just moving on to another aspect of this feature that I consider important: How it affects the rest of the MetaMask experience. (By the way, these are also in the mural, under "Open Questions").

I intentionally kept the account selection screen generic

That's fine, we can explore ways of enriching this selection as another story someday if it's important to us.

My expectation would be that I get logged out of the dapp automatically if I switch accounts/identities. Unless there's a sophisticated way we can enable multi-account login sessions? Has this been explored?

We actually can very easily "sign in with multiple accounts at once" on the API side of the question. One example UI for this would be the log-in screen could let you "check" as many accounts as you want to "show" to the site. Not sure how important this is to people, not many people request it, but it is an option.

Can you provide more context? What's the use case/ user flow?

Hypothetical Account Switching Flow

1. User logs into site
2. User clicks the MetaMask fox to see the action view.
3. User clicks the top right menu
4. Instead of accounts listed, user sees:

• Log Out
• Switch Account
• Settings
• Info
• Lock MetaMask

5. User selects "Switch Account"
6. User is shown log-in account list again
7. User selects account.
8. User is logged into that new account.

Hypothetical Account Signing Out Flow

1. User logs into site
2. User clicks the MetaMask fox to see the action view.
3. User clicks the top right menu
4. Instead of accounts listed, user sees:

• Log Out
• Switch Account
• Settings
• Info
• Lock MetaMask

5. User selects "Log Out"
6. User now sees some "other", currently undefined view. Maybe a "log in" screen. Maybe just the account selection list.

Hypothetical MetaMask Locking Flow

1. User logs into site
2. User clicks the MetaMask fox to see the action view.
3. User clicks the top right menu
4. Instead of accounts listed, user sees:

• Log Out
• Switch Account
• Settings
• Info
• Lock MetaMask

5. User selects "Lock MetaMask"
6. User is shown a message: "This will log you out of every site until you re-enter your password. Do you want to continue?"
7. User clicks "Yes".
8. User is shown "Lock" screen with the password entry field.

[danfinlay]

In discussion Christian clarified that my last comment explores further additions to the general goal of managing log-ins on different sites, and he presents this current design as an initial proposed stage, to address the privacy concern as quickly as possible, which will be more minimal, by globally only allowing MetaMask to be signed in to a single dapp at a time.

An addition that might be nice for that current minimal proposal, slightly less minimal, but probably important:

Problem

As a user, who has used Dapps before, using this new version of MetaMask, visits an old Dapp.

If MetaMask is no longer injecting web3 by default, and the site is not doing our new "request sign in" method, the user would have no way of using this old Dapp, given the current design.

Proposal

When visiting a site that does not request log-in, and the user clicks the fox icon, there should be some interface representation of this "not logged in" state.

This state should allow selecting an account and revealing it to the current page, which will reload the page with the web3 API exposed.

[danfinlay]

Research Question

How common is it for a user to need to be signed in to multiple Dapps at once?

The current proposed MVP achieves privacy with the least time & effort, but at the cost of being able to sign into multiple sites at once. For what fraction of users is that tradeoff worthwhile?

[cjeria]

What if we make this an opt-in feature? Once it's ready, we can send a push notification to our users about it? Call it the "Multi ID" feature.

[derekchiang]

Hi guys, loving the discussions here. I'm trying to understand what the "MVP" that's currently being proposed is. Is it that:

• There's only one active account globally.
• When you open a new dapp, you are prompted to select an active account again. (with the UI flow that @cjeria proposed)
• Selecting a new active account effectively signs you out of the previous active account, which means that you can't use the previous dapp unless you sign in again.

Does that sound about right?

[danfinlay]

That is indeed the most MVP feature proposed here @derekchiang, but our plan is to implement that, and do some testing to see if that's an acceptable UX, or whether we need to add the ability to log into multiple sites at once before we push that to production.

[derekchiang]

@danfinlay thanks for the clarification. Intuitively I feel that the UX will be unacceptable without the ability to use multiple dapps at once, but curious to see what the actual testing result is.

Is this MVP currently being worked on in some branch/fork? Would love to follow the development and potentially contribute.

[danfinlay]

@derekchiang

Is this MVP currently being worked on in some branch/fork?

No, unfortunately this sprint (next 2 weeks) is largely still dedicated to smoothing out our New UI. We want to get it up to parity asap, so we aren't maintaining two interfaces.

We'll be starting development on this again around April 9th/10th.

If you wanted to take a pass, that's 2 weeks of time to try, uncontested by the core team. I'd be happy to offer guidance on our current architecture.

[cjeria]

Here's a high level diagram visually capturing some options we've been discussing.

[danfinlay]

For option 1, "one account at a time", a question:

When you're signed into site A, then switch to tab at site B, then open MetaMask's action view, what will you see? Will you see the normal account view for the other site, or will you see some kind of "not logged in" indication?

I think this design may be another requirement for even a minimal implementation.

[cjeria]

@danfinlay I think we should aim for option 2, multi-id functionality, which I believe to be the better ux, thoughts?

One remaining questions for this feature: should the login handshake between a dapp and metamask trigger a popup window (initiated by a "login" button from within the dapp the user clicks) or simply auto-detect when metamask is available to login to dapp from within the extension (login action sheet)? Maybe we can make both options possible?!

Here's a UX flowchart

Login action sheet from within MetaMask

[skrishnan99]

Is the unlock pop up currently a released feature of metamask. If yes, then as a dapp developer, If you want to use this pop up window as part of your UX instead of having the users click the plugin and login in themselves, how would you do it? Thanks for the help.

[danfinlay]

@skrishnan99 We haven't created this feature yet, but we are planning to implement the API as proposed here:
https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1102.md

[bdresser]

Design issue is here: https://github.com/MetaMask/Design/issues/

[rekmarks]

Per discussions with @danfinlay, here are requirements for Option 2 referenced above:

• When connecting to a dapp per EIP-1102, the user chooses which accounts to connect to the dapp.
  • For each dapp, the user can connect 0, 1, or multiple accounts.
• If the user has connected one or more accounts to a dapp, they must choose a single account with which they are “logged in” to the dapp.
  • In this construction, the user's currentAccount is defined per-dapp.
    • At present, currentAccount is defined globally for all dapps.
  • MetaMask still only exposes a single account to any one dapp at a time, although a different account may be exposed to each dapp.
  • If a user has connected to a dapp, the user must select one account to expose to the dapp.
    • i.e. if the user does not want to "log in" to a dapp at all, they must not connect to it.

This functionality can be implemented using the new capabilities middleware. Comments on design/UX appreciated @cjeria, @omnat.

[bdresser]

For each dapp, the user can expose 0, 1, or multiple accounts.

MetaMask still only exposes a single account to any one dapp at a time.

@rekmarks why allow the user to choose multiple accounts if the extension will only ever share one at a time? Seems like this might complicate the UX unnecessarily.

[rekmarks]

@bdresser

This functionality would enable the following:

• Given a MetaMask user with accounts 1, 2, and 3
• The user accesses dapps A and B, connecting them to the following accounts:
  • A: 1, 2
  • B: 3
• Now, the user can, for example, "log in" to dapp A with account 1, and dapp B with account 3 at the same time
  • Only one account is exposed for each dapp, although not the same account

I am editing my original post for clarification. Does this make sense?

[bdresser]

@rekmarks yep, I'm with you.

I'm asking why it's important to allow the user to connect Account 2 to Dapp A if the user can only use one account at a time.

• it makes the simple question ("what account do you want to use") into a more complicated question ("which accounts do you want to connect, and which one do you want to use right now?")
• if we have to support switching accounts for a given dapp (in this case, our user on Dapp A going from Account 1 to Account 2), why not just have the user "connect" another account, rather than expose an already-connected account?

(cc @danfinlay)

[bitpshr]

@bdresser I think login-per-dapp becomes more important when power users want to use different accounts for different dapps all open at the same time. Still, I'm not sure how realistic this is; it's almost akin to Google offering login-per-site instead of signing in your entire browser.

[rekmarks]

@bdresser In my understanding, the point of this functionality is to allow the usage of multiple accounts at a time. I.e. in the above example, any transactions/activity initiated in dapp A would use account 1, and activity initiated in dapp B would use account 3.

@bitpshr has the usecase right ("use different accounts for different dapps all open at the same time"). As for the realism, this is one thing that should be tractable with the ocap middleware.

Edit: There are definitely design and UX complications to consider here, as @bdresser said.

[danfinlay]

@bitpshr wrote:

I'm not sure how realistic this is; it's almost akin to Google offering login-per-site instead of signing in your entire browser.

I had no idea you felt that way about this feature! Glad to defend it, I think it's an important thing to consider, especially because all of a user's activity with one account is public, and so the only privacy you have is the way you isolate accounts.

Also, to your example, Google does let you log into different sites/services with different accounts, even once you're logged into your browser with one profile. I'm doing it right now, where I have YouTube on my personal account and Google Drive on my work account. It works great, and lets me isolate services by the "persona" I'm using them with. By switching my current account, my YouTube suggested videos change, and the channels I manage with it change, too.

Since MetaMask can potentially replace site logins in general, if we don't allow this feature, it would be like suggesting that all users log in with the same account everywhere, similar to all the tracking of Facebook Connect except transactions are transparent to the entire web, not only the sites you visit or just Facebook. It's a big step backwards for privacy.

Our current behavior is potentially deceptive: We ask a user "Do you want to show account 1 to site X?" And they may consent, and then log into another site and switch accounts, without considering that they implicitly logged into that other site with whatever account happens to be globally selected at the time! If that's the deal, why did we even show an account icon on the connect screen? It's useful only in the immediate term, and then deceptive beyond that. Sorry, your employer now knows your gambling habits!

There's also a big convenience win for letting users be explicit about the accounts they use with a site: I might only use GitCoin with my team-funding account, and so by allowing account-per-domain, I save myself at least two clicks (switching the account) every time I change to that dapp from one I use with another account. Yes, this helps "power users" more, but if we're building towards a platform where web3 is common, we should imagine power users (ie users of many dapps) as the norm, and build for that.

There may be better ways of abstracting this out, like if we use app-specific keys for login by default, allowing users to not disclose any identifying information by default, (except when funding the account, which re-introduces the issue).

Anyways, I think this is just a great example of Principle of Least Authority: To be secure, let users grant authority, be explicit about it, and only grant what they approve. For now our login system has a leaky abstraction around it that doesn't represent the user's intention, and that's a cause of both friction and insecurity.

[brad-decker]

@danfinlay / @cjeria prolly closeable?