Owners keys are confusing and not safe to use

[sche]

Part 1: Define the problem

Epics

• [x] https://github.com/safe-global/safe-ios/issues/2150 (L)
• [x] https://github.com/safe-global/safe-ios/issues/2173 (L)
• [ ] https://github.com/safe-global/safe-ios/issues/2234 (M)

What problem are you trying to solve?

• Owner keys confuse people as it is discovered sometimes in the user tests
• The user flow of the owner keys is not seemingly integrated into the current onboarding flow
• To import a key, a user needs to type - an action that is often considered dangerous, so people avoid it

One of the feedbacks from our core user:

It is a big hassle to add the mobile app as a signer to an existing Safe. I do not want to import my existing private keys.

What is your hypothesis?

Suppose we improve the usability and allow importing owner keys more safely. In that case, it will increase trust in the mobile app’s security and open more functionality for the users, thus creating more value.

What value does this bring to our customers and/or our mission? What is the goal?

• It brings peace of mind and ease of use.
• Security is one of the essential things our audience cares about and the primary reason Gnosis Safe is used, so we need to ensure that we provide that safety in the mobile app.
• Additional user education, as owner keys are not the most straightforward concept to grasp, will make the app more user-friendly and accessible.

How do we measure it?

Quantitative: Increased amount of keys imported; specifically via private key/seed phrase Qualitative: Less confusion expressed; positive feedback over time

Data on keys for March

Links:

Insights from users

Research doc on EOAs as 1st class citizens

Kick-off Miro board

Mocks in Figma

Part 2: Shaping the problem

Problem Owners

@TanyaEfremova @sche

Non Goal(s)

// Controlling the scope of solving the problem.

Solutions

The list of related pain and proposed solutions ideas is sorted by priority and the potential positive impact.

Remove confusion around read-only safes

There are several major confusions related to adding existing Safes and the owner keys. Resolving these can majorly reduce the confusion around the keys, and potentially help users better understand why they are needed and their relationship with the owners.

Pain points

• When adding existing Safe, it is not clear what read-only is and how to get access to Safe;
• After generating a new key users don't understand why Safe is still read-only;
• When a key is imported, that is not an owner, users sometimes think it is added as one automatically.

Implementation ideas

• After loading a Safe show owners list and suggest connecting one or generating a new key;
• Suggest adding non-owner keys as owners;
• Emphasise read-only mode when adding a Safe (e.g., a banner in the list of safes, etc.). Explain what it means in the interface.

Improve key generation flow

The solutions are targeted toward the user group that doesn't feel secure importing the keys on Mobiles mostly.

Pain points

• Users generate new keys due to confusion or security concerns (not willing to import a key). New keys don’t give control over Safes.
• After generating a new key users don't understand why Safe is still read-only
• Users forget to backup generated keys

Implementation ideas

• Suggest adding a newly generated key as an owner / replacing another owner of an existing Safe
• Remind to backup newly generated keys
  • Consider encryption with a password
• Backup with 1Password / Keychain

Improve key import flow

Pain points around importing existing keys are mostly related to safety concerns. In general, users don't mind importing ones but would prefer to do it in a safer way, rather than typing.

Pain points

• It is painful to import existing keys by typing, copypasting. Typing doesn’t feel safe.

Implementation ideas

• Allow hiding / revealing typed content
• Allow importing Keystore file encrypted by a password for higher security
• Allow scanning private keys/seed phrases
• Import from 1Password / Keychain

Better integration of Owner keys in the Safe settings

Pain points

• Owner keys in App Settings and Owners in Safe Settings close to each other confuse some users.

Implementation ideas

• Merge Safe Settings with Safe Info
• Offer to import owner key if Safe is read-only in Safe Setting

Additional research needed

Research on better naming for Owner keys across the Apps

Pain points

• Not every added EOA key to the App is an owner key, but we communicate them everywhere as owner keys
• 'Owner key' name confuses users: "What does ‘an owner key’ mean? Is it a wallet? Is it the same as a browser extension?"

Research on EOAs as 1st class citizens in the App

Pain points

• Our users use EOA accounts for signing and executing Safe transactions and many other use cases. Because our app doesn't have full support for the most popular use cases for EOAs, a significant share of our users connect keys via 3rd party wallets, like MetaMask on Mobile. Still, UX with connected keys is worse than with the imported/generated key.

Research doc

Overview

Rough Scoping & Timeline

Improve key generation flow

M: 1-2 weeks

Remove confusion around read-only safes

S: 1 week

Improve key import flow

L: 2-3 weeks

Remove Safe Settings from the Settings tab

S: 1 week

Researches

• EOAs as 1st class citizens in the App
  • High-fidelity design prototype & User tests (L: 2-4 weeks)
• Better naming for Owner keys across the Apps
  • Can be tested as part of the prototype above
  • Separate research (M: 1-2 weeks)

Risk(s), Key Trade Offs & Decisions

Ideas with straightforward implementation don't have considerable technical risks. The risks of research tasks will be clear once the research is finished.

Implementation of iCloud backup: This is not exactly a decentralized solution, and security-concerned users might not consider it a good idea, to store their seed phrases in a cloud. See threads on Reddit

Suggest adding keys as owners: It might lead to bigger confusion and hassle. DAOs have likely had a well-structured setup with a strict amount of owners and owners, who were pre-approved. Thus, this solution might be targeted toward those who don't mind easily changing their Safe's structure. Also, this might add an extra layer of complication for the Web app, as a new owner (especially if it replaced a previous one) needs to be imported as an extension to e.g. Metamask. if a user prefers it. On the other hand, it is a step towards better integration of Mobile and Web.

Concept Mocks

Mocks in Figma

Alternative solutions & ideas

No

Open Questions

• Should we consider iCloud as a backup option for generated keys?

[tschubotz]

Handling seed phrases and private keys is always scary. Do we have any numbers on what types of owner wallets people are using? i.e. how many use Metamask vs. how many use hardware wallets? With that we would be able to better judge if it's worth improving key import/key generation or if we should rather improve the hardware wallet signing capabilities on mobile.

[rmeissner]

General comment: there are quite a lot of solution statements that all together take more than 8 weeks. how do these depend on each other. Should we separate some of these out?

[TanyaEfremova]

Do we have any numbers on what types of owner wallets people are using?

Yes, we have data regarding the owner key types (imported, generated, WalletConnect, Ledger Nano X): Google Analytics report You can play around with this data for the past quarter. Imported and WC keys are leading (around ~1.8K keys each).

I will add it to the ticket.

[sche]

@tschubotz details data on keys is added to the issue description: Data on keys for March

[sche]

@rmeissner I think we can easily separate some solution ideas to another problem if we decide that we would like to work not on all of them as part of this problem in this cycle.