Feedback on wallet backup and recovery - 31 August 2021

This document collates all the feedback gathered on the wallet backup and recovery
designs up to 31 August. It covers the following design videos:

1. backup_wallet_key_v2.webm
2. wallet_backups_iteration1.webm
3. backup_recovery_iteration1.webm

Signed-off-by: Belen <belenbarrospena@gmail.com>

1 files changed, 220 insertions, 0 deletions

diff --git a/anastasis_integration_wallet/feedback_31082021.txt b/anastasis_integration_wallet/feedback_31082021.txt
new file mode 100644
index 0000000..eb434f5
--- /dev/null
+++ b/anastasis_integration_wallet/feedback_31082021.txt
@@ -0,0 +1,220 @@
+# Wallet backup feedback
+
+This document collates the feedback gathered for:
+
+1. backup_wallet_key_v2.webm
+2. wallet_backups_iteration1.webm
+3. backup_recovery_iteration1.webm
+
+The feedback was gathered by email up to 30 Aug 2021, and during a design review call on 30 Aug 2021. 
+
+The feedback is broken down by process (wallet backup, Anastasis backup and recovery), and then by design screen.
+
+## General: snackbar use
+
+* Torsten: The second thing is this dark status field which resembles a Toast or a
+Snackbar, but is really neither. It would be nice if we could use a standard
+material design element here. 
+	- Belen: Those are supposed to be snackbars: https://material.io/components/snackbars. I am just using the Google stencils for Material design here. Maybe they look a bit different to the implemented component, but they are supposed to be snackbars. 
+
+* Torsten: For showing a status on the main balance screen, we already do have a pattern implemented. Again, best to re-use this here. 
+	- Belen: what's the pattern? 
+
+## Wallet backup
+
+### Terminology
+
+* Sebastian: My point is to have this well defined ways to reference this two different kind of backups. In both steps the user configure a cloud backup which has not the same properties and in both cases there are service providers which are not the same. (sync and anastasis)
+	- Belen:  Language: there is confusion about what we are backing up (the wallet or the master key), and terms like "provider" have more than one meaning (wallet backup providers and "Anastasis" providers for cloud copies of the master key). Sebastian seems to suggest we come up with some kind of metaphor. This can be a good strategy, the hard bit is finding the right one :) In any case, it seems clear that we need to work on the language and our naming of things.
+
+### 1_settings
+
+* Christian: settings will (eventually) need an option to
+manage the set of 'auditors' as well; alas, conceivable that we do
+exchanges+auditors under the same menu item (as it is both about
+configuring the trust anchors in the system). 
+
+### 2_configure wallet backup 
+
+* Christian:  "create" backup -- is that a good word for a continuous backup?
+maybe "start" would be better?
+
+* Christian: Should we not already tell the user that the backup will be encrypted?
+Would the not otherwise worry?
+
+* Christian: We also have some information we probably should show at this time: the
+annual storage fee and the storage limit in megabytes. 
+
+* Christian: Finally, the user (likely) has to _pay_ the annual storage fee for the backup 
+at this time, so the fee should be shown and the user must be aware that they
+are paying for it.
+
+* Christian: suggested to change "location" to "provider" (e.g. "Chang provider" instead of "Change location")
+
+* **Sebastian: there should be an option to be saved in cloud or locally.** 
+	- **NOTE:** This was discussed during the design review on 30 August. We agreed to provide 2 options for wallet backups: 1) backup with a provider, and 2) save locally to a file.  All backups will be encrypted, so we need to tell users they will need the recovery credentials to restore a wallet from a local file.
+	- Previous comments:
+		- Christian: I agree that it might be good to have an explicit "save to file"/"load
+from file" for the wallet-DB, just like what I already proposed we
+should have for the master key (show as QR code/URL, scan as QR
+code/enter URL).
+		- Christian: Well, the primary option will certainly to store the actual (encrypted)
+wallet data at some provider online, as a local copy on the same device
+is hardly improving anything for the user ;-).
+		- Belen: from what I can gather, we should have the option to store both the wallet backup and the master key either locally or with cloud providers. So, during the wallet backup process, I should be asked whether I want to save the backup locally or to choose a cloud provider 
+		- Christian: Not sure. I think we'll likely only ask about choosing a cloud provider.
+Saving the wallet database to a local file might be something we offer in a separate option in developer mode *only*. The reason is simple: once you activate the (main) backup, the wallet will keep the (cloud) backup synchronized with your local state of the wallet. When saving to file, doing that automatically would not be
+possible/meaningful/sane.
+		- Sebastian: We can design this in many ways but the point is that you may still want to do a backup of the wallet and key even if there is no provider available (no connection or maybe you don't trust them). We may choose a path to simplify this process making an export-wallet-and-key option outside the periodic-backup-into-the-cloud process or we may add a default provider that sync your locked-wallet into your SD card every time. The master key value doesn't change so it may be printed as a long passphrase like 1password does.
+
+### 3_change_backup_location
+
+* Christian: We can validate that a backup location is 'valid' (runs a 'sync' provider). I propose that 'save' is initially insensitive, and that once a syntactically valid URL (including ending with a "/") is entered, the 'save' becomes sensitive. However, when the user clicks on 'save', we quickly check (at $URL/config) if the provider is valid. If not, we should then keep the dialog open and show an error message (not a sync provider, unsupported protocol version, whatever).
+
+### 5_first_backup_created
+
+* Torsten: I personally think that we should not let the user complete the backup setup
+without making sure they saw the credentials they'll need for restore. This
+dialog with the "Review credentials" button can be dismissed and "review"
+maybe doesn't communicate clearly enough that these will be needed and must be
+saved by the user to restore the wallet later.
+
+* Belen: 3. Integration between wallet backup and master key backup: it seems that these 2 processes should be better integrated, to the point of feeling almost like a single one. The problem I am having is that right now I don't fully understand how the wallet backup works and behaves. In the released version of the Android app, the backups are enabled by default, and I cannot set up other backup providers. So it's hard for me to integrate 2 processes further without fully understanding one of them :/
+	- Sebastian: I'm not sure about this one, I think it is better to have the concept of "making a copy of your locked wallet" and "making a copy of the key of your wallet" being separated. 
+Also from the user perspective it is fair to ask: why do I need two steps? So maybe mentioning/showing that the key is going to be split into small pieces in order to be saved in a safe way could be nice. 
+
+### 6_recovery_credentials
+
+* Christian: "cloud warden service" is good, but might be good to name-drop Anastasis explicitly, maybe with a link to https://anastasis.lu/?
+
+* **Torsten: I am not sure a QR code is the best way to do this.** I guess the challenge here is that this does not only include a key but also an URL making this a lot of data to save, maybe too much to write down on paper. 
+	- **Christian: I guess from an Anastasis *business* point of view, *printing* the QR code *OR* manually writing down the long URL  *OR* using Anastasis is not bad as far as options go. Printer is unlikely, writing down inconvenient, Anastasis thus a good option...**
+	- **NOTE:** During the design review on 30 August we discussed which options we should provide to view and save the recovery credentials. We settled on providing 3 options: 1) View credentials; 2) View credentials as QR code; 3) Create a safety copy of the credentials. 'View credentials' will display a URI containing both the backup location and the backup key. The URI will be something like *taler://recovery/sync.taler.net/DAS053AD5ASD5AF5FAFADAS5363 
+
+* Torsten: It might even make sense to let the user reproduce the saved data to be sure
+that they have saved it.
+
+### 7_qr_code
+
+* Christian: reminding the user that if they export this, they really need to keep the information _private_ might be a good idea (TM).
+
+* Christian: 'save qr code' -- how? where? it's a phone, saving it on the
+phone itself is pretty pointless, right? Does Android have a printing
+API? **Can users sometimes print from their Android phones? Then we should
+have a "print" option. Additionally, maybe it would make sense to copy
+the QR code image to the *clipboard* to say attach to/paste into some
+mail/messenger/etc. message.  But 'save' (to file?) is IMO the least
+useful choice here.**
+	- Christian: Note that we can _also_ show the whole thing as *text*, so maybe two
+copy options: copy URL or copy image? 
+	- Torsten: Saving a QR code on the phone or pasting it to the clipboard has the obvious
+security drawback of other apps being able to access it. There's a printing
+API on Android, but I doubt many people know how to use it. Writing numbers down on paper would be the easiest thing to do and does not require special knowledge.
+	- Christian: I agree that a QR code _shown_ on the phone is not so useful, but
+printing it would be.
+	- **NOTE:** During the design review on 30 August we discussed which actions we should provide to users for each way of handling the recovery credentials. We agreed the following:
+		- For 'View credentials as a QR code' we will show 2 actions: 1) Print the QR code and 2) Copy to clipboard
+		- For 'View credentials' we will show only one action: copy to clipboard. In this case, we will warn users they are copying their recovery credentials as clear text. For this option, users are mostly expected to write down the URI.
+
+### 9_wallet_backup_screen_after_setup
+
+* Torsten: A related issue is **exposing the credentials permanently in the UI**. Other similar apps don't do this and only have an option to reset the credentials in case the user doesn't know them any more. 
+	- Christian: I do not think we should rotate it unless explicitly asked by the user (that's also dangerous, in case the user has a QR code printed somewhere and someone _else_ gets hold of the phone...). But, we may have 'key rotation' as an option (to help users that lost control of their key, i.e. if someone else got hold of the QR code).
+	- Torsten: If it is really considered important to show the credentials a second time, I would at least only do that after the user confirmed with their fingerprint or lock screen secret. But then, the credentials can't be stored in the phones' secure element where they can not easily get extracted any more.
+	- Christian: Showing a URL in text, and maybe requiring additional authentication before exposing the secret from the ordinary running wallet also make sense. 
+	- **NOTE:** We discussed this during the design review on 30 August. We agreed we will expose the credentials in the UI, but we will require users to unlock the phone before displaying the details. The text of the title and subtitle in the lock screen are customisable, so we can use that content to communicate to users that they need to verify their identity before seeing the recovery credentials.
+
+* Christian: may be good to add another option for clarity here: "synchronize backup automatically" on/off. Off is slightly better for privacy (Jeff will tell you...). Even if it is 'on', I would keep the 'back up wallet now' button. But having the option to easily synchronize automatically (and we can discuss what the best default will be later...) is good here: so far we had discussed that the wallet would _always_ synchronize automatically, but then as a user I would worry if I had to keep going back and pushing that button. So having a simple enable/disable option here will serve *two* purposes: it informs me that the wallet _can_ automatically keep the backup in sync, and secondly it gives me the choice of using that feature or not.
+
+* Christian: we again need to show the cost structure below the backup location: backup service paid for until XXX, annual renewal cost YYY. Maybe with an 'auto-renew' toggle button as well?
+
+## Wallet backup - Anastasis
+
+### 1_location
+
+* Sebastian: so personal information is decided by country but I don't understand why is this needed in the first place. (just by seeing the screens) Is the intention not to ask for a fiscal code when in another country you have a social security number? In that case I think it is better to have a i18n setting and not to ask for a country here. Or maybe having an option that says "isn't this your country? choose another for better questions". This step gives me the feeling that this information is needed for the cloud copy.  My suggestion will be let the user know that this step is currently for building an identifier that can be a lie and maybe guessable but it should be a unforgettable lie.
+	- Belen: Justifying the request for personal information: Sebastian makes a good point about not knowing why we are asking for your country and your personal information. We should explain why this is needed.
+	- Sebastian: Yes, do you think that telling the user that needs to create the unforgettable User Identifier is ok? https://docs.anastasis.lu/introduction.html#user-identifiers
+
+## Wallet recovery
+
+### 1_settings
+
+* Christian: Recovery from QR code can also be started from the main screen
+(just scan the QR code!), but I guess it's good to make this possibility
+explicit here.
+
+### 2_recover_lost_wallet
+
+* Christian: we must also allow the user to enter the URL by hand (however painful that may be), in case they really exported/wrote down the text on a piece of paper. We may even want to permit importing from the clipboard, even if Torsten is of course right about the security issues with that. (I'm not sure what is the right trade-off here between giving the user sufficiently usable ways to do the backup and preventing users from exposing the secret to malware on their device...)
+
+### 4_backup_found_with_snackbar 
+
+* Christian: We need to inform the user that 'recover wallet' will NOT loose
+their local wallet data/funds, but *MERGE* the two.
+
+### 5_recovering wallet and 18_recovering_wallet
+
+* Torsten: One is that floating dialog that only shows a circular progress indicator.
+This is a pattern from Android 1/2 and not used that much anymore. Nowadays,
+the progress indicator is typically integrated into the UI. Our Android wallet
+app uses that pattern already and shows a progress indicator below the action
+bar and where the clicked button was. Maybe we should re-use the existing
+pattern here rather than introduce a new one?
+	- Belen: I guess this also applies to 15_retrieving_credentials_and_backup as well as wallet backup > 4_creating_first_backup
+
+### 6_wallet_recovered
+
+* Christian: There are a few error cases here, like when the wallet is now
+'owned' by two devices and the user must choose which one should
+continue to 'own' the data (this one = continue, other device = abort
+restore). Florian, maybe you want to elaborate on other possible error
+scenarios here? Or is this the only one?
+	- Torsten: As for error cases, I guess that the warden service is (temporarily) not
+available or can't be reached is one of them.
+
+### 9_choose_policy
+
+* Christian: There is usually more information we can give the users about the
+challenges than just the cost. And that may be crucial: the user may
+have set two security questions, but only remembers one of the answers.
+Or they may have provided a phone number, but changed numbers since
+then. Anastasis-gtk shows those details for a reason
+
+* Christian: in case the user is waiting for a physical letter to arrive in the mail, we
+need to think about how to suspend/resume the entire process nicely.
+
+* Christian: in case the user the user has insufficient funds to pay for recovery, **we
+need to think about how to suspend/resume the entire process nicely.**
+
+* Torsten: As for error cases, I guess that the warden service is (temporarily) not
+available or can't be reached is one of them.
+
+### 10_view_identity_verification_methods
+
+* Christian: those 'hints' about the challenge really must be shown. Also, the user may choose a challenge, move on to another one, or possibly to an entirely different policy (where then some challenges may have already been solved!), and to top things off, some challenges may become
+satisfied 'in the background' (i.e. SEPA transfer completes)
+
+### 11_SMS_challenge
+
+* Belen enquired about users being charged for resending an SMS code. This depends on a set of rules and cases documented at https://docs.anastasis.lu/rest.html#get--truth-$UUID
+
+### 16_last_challenge_solved_and_backup_found
+
+* Christian: We need to inform the user that 'recover wallet' will NOT loose
+their local wallet data/funds, but *MERGE* the two.
+
+* Torsten: **A basic question about paying verification fees: If I want to recover/restore
+my wallet, the most likely scenario is that I start with an empty wallet. So
+how do I pay for recovery then? Do I first go through a multi-day top-up
+process and only then can restore?**
+	- **NOTE:** We discussed this during the design review on 30 August. Users will need to withdraw funds before recovering a wallet. This is one more reason why we need to be able to pause and resume the recovery process.
+
+* Christian: **There are no more 'payment details' to show at this stage, the
+payments have to be made earlier, _before_ the SMS is sent, and right
+after the security question answer is provided.**
+	- **NOTE:** During the design review on 30 August, Belen raised the issue that users may struggle to understand and accept this payment arrangement. From the user's perspective, recovering the wallet is the service, not receiving a fragment of the recovery credentials. If I pay for the delivery of an SMS, for instance, and for whatever reason I cannot recover my wallet, I got nothing to show for the money I've paid, and I will probably be rather annoyed about it. 
+
+### 17_payment
+
+* Christian:  Is thus completely useless, the payment happens per challenge earlier. This way, an adversary cannot trigger unpaid work for the Anastasis provider, and also it becomes really expensive to brute-force a challenge. So the earlier buttons likely should say 'pay' somewhere...