Signing on mobile v1: design decisions

Links
Signing on mobile v1 #348 🐱
Kickoff meeting 📆
Hypothetical press release 📆
Specs doc 📆
Gnosis Safe - 5 Inconvenient multisig signature collection on-the-go 📆
Miro Dima, Dirk, Mouaz Signing on mobile 📌
iOS Invision 💖
Android Invision 💖

User tests
#27 Signing on mobile test script 📋
#27 Prototype A 💖
#27 Prototype B 💖
Dovetail project 💡

Past ideas
Authorize mobile device for Safe #310 🐱
Dapp interaction via WalletConnect #294 🐱
Safe Multisig mobile post phase 1 📆
Authorized device & initiate tx via WalletConnect 📆
Miro Tobi’s wireframes WalletConnect 📌

Platform: iOS, Android

App version: tbd

Which problem do we solve?
Inconvenient multisig signature collection on-the-go (see Gnosis Safe - 5 Inconvenient multisig signature collection on-the-go 📆 and Signing on mobile v1 #348 🐱).

What are the metrics and KPIs we will be measuring for this feature?
Funnel: how many users achieve successful owner import (owner_enter_seed -> owner_select_account -> success).

Is there user research or quantitative data informing decisions made here?
Data from discovery interviews Q1 2020 💡
Insights from discovery interviews Q1 2020 💡
Insights from #18 Safe Keys mobile prototype 💡
Insights from #19 Android Basics mobile prototype 💡
Roadmap Q3/Q4 2020 📆
Insights from #23 Read-Only mobile prototype 💡
Insights from #27 Signing on mobile iOS 💡

User flows

1. Import owner key
2. Sign transaction
3. Remove owner
4. Import owner when no Safe is loaded

1. Import owner key

2. Sign transaction

3. Remove owner

4. Import owner when no Safe is loaded

Main design decisions

1. Do we allow transaction confirmation only or confirmation & execution? Rejections?

Leave out transaction execution and rejections in the first version for simplicity. Execution should happen in the web interface. There are no proper rejections on mobile yet. We’ll introduce execution and rejections on mobile later.

2. One app-specific owner key vs multiple keys

Start with one app-specific owner key for simplicity.

• We don’t have data about how users want to use their owner keys on mobile.

• 90% of Safe owners have access to 1 Safe only (source). Which means that 90% of the Safes don't share owner keys with other Safes.

• Multiple owner accounts for the same Safe on one phone could result in loss of funds if someone takes hold of the phone.

• Counter-argument – reusing the same account for multiple Safes is bad for privacy.

3. Add owner via the app settings vs Safe settings

We agreed not to add owner from Safe settings. The same key is used for all loaded Safes.

• It is simpler for the first version, no premature optimisation
• It is how web interface behaves This is close to how web interface with external wallet behaves
• It’s too early to assume most users have multiple Safes that have different signer keys each
• We are flexible to optimise it later

4. Do we need password/PIN protection?

In the first version – no, because phone is already locked. Go with “Are you sure?” dialog to prevent accidental signing, add biometry/password in later iterations.