status-im / status

0 stars 1 forks source link

Security/UX tradeoffs #59

Open 0kok0 opened 4 years ago

0kok0 commented 4 years ago

abstract

Is there a point where we „force“ a user to take a specific action, e.g. user has to go through seed phrase backup? The idea is theoretically not sound, especially for an open source app, as the user has full control over what the application is doing, however changing the behaviour of an application usually involves work which only some users will be willing to go through for customization

argument

This is a design paradigm most users are used to. Apps usually nudge their users to take specific actions, as different applications compete for their attention. user group: people with an increased interest/incentive to keep their private information

counter argument

Aim to provide full disclosure about choices, configs and implications while keeping the app usable. user group: crypto enthusiasts, military , governmental entities

proposition

There's a proposal for a nudging scheme where users receive iterative notifications to back up their seed phrase (issue by @adambabik here, slides by @hesterbruikman here)

@andremedeiros @corpetty @hesterbruikman and me had a call today where we discussed how to handle user passwords, privkey imports and if we should use a password mgr. @hesterbruikman proposed an asset based approach to differentiate cases and when to apply what scheme for password handling, seed phrase backup and key recovery.

With this proposal, we can integrate the above cases to form an implicit user journey:

I. "light users", users without assets, minimal threat model

// Can use industry standards, keychain or password manager might not need/want to back up seed phrase. Users are nudged¹ to use social key recovery, social password caching, Keycard or physical seed phrase backup.

II. "average users", moderate amount of assets, casual threat model

// Users are strongly encouraged² to use social recovery, social password caching, password managers are disabled and nudged to use Keycard or physical seed phrase backup.

III. "high profile users", users with a large amount of assets, high threat model

// Are strongly encouraged to use keycard or physical seed phrase backup, password managers are disabled. As @corpetty put it, we mistrust the host OS here.

¹nudged := app notifies ²strongly encouraged := app notifies iteratively and enforces setup after countdown has passed

hesterbruikman commented 4 years ago

Thanks @0kok0! To verify, would the profile below classify as "average user"?

Including chat interactions here as users who only use Status messaging feature could still value there chat identity (random name). And including account sharing with a dapp as users might build up a profile within a dapp based on their account address.

This user would risk losing their identity or dapp profile if we only act on assets in wallet.

Taking dapp interactions into account feels overdone and unlikely. Aiming for a complete picture, but would happily leave this out. Wdyt?

0kok0 commented 4 years ago

Thanks @0kok0! To verify, would the profile below classify as "average user"?

  • Assets in wallet
  • Has sent a message (exposing identity)
  • Has shared any account with a dapp

Yes!

Taking dapp interactions into account feels overdone and unlikely. Aiming for a complete picture, but would happily leave this out. Wdyt?

I‘d classify this as light usage, essentially the user would loose time spent on setup and building a profile/reputation but also light users have the largest set of potential backup/recovery mechanisms available, also very convenient ones.

I think average/high profile users is where we actually have to work hardest, as we consciously limit potential recovery/backup options and have to make sure they work smoothly.

hesterbruikman commented 4 years ago

Challenge on my mind here is how we'd support transition between security levels. E.g. we can't rely on asking people to stop using their password manager. For level III we can 'strongly encourage' and 'enforce' new behavior, but this will not work for established behavior outside the app.

Password manager might be a single use case where upgrading a security level might be an issue. We can treat it separately. Not sure if there are more. Any thoughts?

0kok0 commented 4 years ago

If we disable the password manager popup, we can ask the user to set a new Passwort to be sure it does not use a password manager. But I agree, that a smooth transition from one security level to another is challenging. Some ideas from our chat @hesterbruikman to make the transition easier:

gamify it: basically user have to "earn" the next sec level and receive some badges

incentivise it: users reward each other for social recovery

hardcode it: certain features of the app, like anonymous chat or depositing a certain amount to the wallet are only enabled after the user has reached a certain security level

hesterbruikman commented 4 years ago

Change password, makes sense. Hadn't thought of that! And thanks for consolidating here

corpetty commented 4 years ago

hardcode it: certain features of the app, like anonymous chat or depositing a certain amount to the wallet are only enabled after the user has reached a certain security level

keeping certain levels of deposit won't be able to be done, but I get the idea here.