feedback_31082021.txt (18194B)
1 # Wallet backup feedback 2 3 This document collates the feedback gathered for: 4 5 1. backup_wallet_key_v2.webm 6 2. wallet_backups_iteration1.webm 7 3. backup_recovery_iteration1.webm 8 9 The feedback was gathered by email up to 30 Aug 2021, and during a design review call on 30 Aug 2021. 10 11 The feedback is broken down by process (wallet backup, Anastasis backup and recovery), and then by design screen. 12 13 ## General: snackbar use 14 15 * Torsten: The second thing is this dark status field which resembles a Toast or a 16 Snackbar, but is really neither. It would be nice if we could use a standard 17 material design element here. 18 - 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. 19 20 * Torsten: For showing a status on the main balance screen, we already do have a pattern implemented. Again, best to re-use this here. 21 - Belen: what's the pattern? 22 23 ## Wallet backup 24 25 ### Terminology 26 27 * 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) 28 - 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. 29 30 ### 1_settings 31 32 * Christian: settings will (eventually) need an option to 33 manage the set of 'auditors' as well; alas, conceivable that we do 34 exchanges+auditors under the same menu item (as it is both about 35 configuring the trust anchors in the system). 36 37 ### 2_configure wallet backup 38 39 * Christian: "create" backup -- is that a good word for a continuous backup? 40 maybe "start" would be better? 41 42 * Christian: Should we not already tell the user that the backup will be encrypted? 43 Would the not otherwise worry? 44 45 * Christian: We also have some information we probably should show at this time: the 46 annual storage fee and the storage limit in megabytes. 47 48 * Christian: Finally, the user (likely) has to _pay_ the annual storage fee for the backup 49 at this time, so the fee should be shown and the user must be aware that they 50 are paying for it. 51 52 * Christian: suggested to change "location" to "provider" (e.g. "Chang provider" instead of "Change location") 53 54 * **Sebastian: there should be an option to be saved in cloud or locally.** 55 - **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. 56 - Previous comments: 57 - Christian: I agree that it might be good to have an explicit "save to file"/"load 58 from file" for the wallet-DB, just like what I already proposed we 59 should have for the master key (show as QR code/URL, scan as QR 60 code/enter URL). 61 - Christian: Well, the primary option will certainly to store the actual (encrypted) 62 wallet data at some provider online, as a local copy on the same device 63 is hardly improving anything for the user ;-). 64 - 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 65 - Christian: Not sure. I think we'll likely only ask about choosing a cloud provider. 66 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 67 possible/meaningful/sane. 68 - 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. 69 70 ### 3_change_backup_location 71 72 * 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). 73 74 ### 5_first_backup_created 75 76 * Torsten: I personally think that we should not let the user complete the backup setup 77 without making sure they saw the credentials they'll need for restore. This 78 dialog with the "Review credentials" button can be dismissed and "review" 79 maybe doesn't communicate clearly enough that these will be needed and must be 80 saved by the user to restore the wallet later. 81 82 * 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 :/ 83 - 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. 84 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. 85 86 ### 6_recovery_credentials 87 88 * Christian: "cloud warden service" is good, but might be good to name-drop Anastasis explicitly, maybe with a link to https://anastasis.lu/? 89 90 * **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. 91 - **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...** 92 - **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 93 94 * Torsten: It might even make sense to let the user reproduce the saved data to be sure 95 that they have saved it. 96 97 ### 7_qr_code 98 99 * Christian: reminding the user that if they export this, they really need to keep the information _private_ might be a good idea (TM). 100 101 * Christian: 'save qr code' -- how? where? it's a phone, saving it on the 102 phone itself is pretty pointless, right? Does Android have a printing 103 API? **Can users sometimes print from their Android phones? Then we should 104 have a "print" option. Additionally, maybe it would make sense to copy 105 the QR code image to the *clipboard* to say attach to/paste into some 106 mail/messenger/etc. message. But 'save' (to file?) is IMO the least 107 useful choice here.** 108 - Christian: Note that we can _also_ show the whole thing as *text*, so maybe two 109 copy options: copy URL or copy image? 110 - Torsten: Saving a QR code on the phone or pasting it to the clipboard has the obvious 111 security drawback of other apps being able to access it. There's a printing 112 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. 113 - Christian: I agree that a QR code _shown_ on the phone is not so useful, but 114 printing it would be. 115 - **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: 116 - For 'View credentials as a QR code' we will show 2 actions: 1) Print the QR code and 2) Copy to clipboard 117 - 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. 118 119 ### 9_wallet_backup_screen_after_setup 120 121 * 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. 122 - 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). 123 - 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. 124 - Christian: Showing a URL in text, and maybe requiring additional authentication before exposing the secret from the ordinary running wallet also make sense. 125 - **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. 126 127 * 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. 128 129 * 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? 130 131 ## Wallet backup - Anastasis 132 133 ### 1_location 134 135 * 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. 136 - 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. 137 - 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 138 139 ## Wallet recovery 140 141 ### 1_settings 142 143 * Christian: Recovery from QR code can also be started from the main screen 144 (just scan the QR code!), but I guess it's good to make this possibility 145 explicit here. 146 147 ### 2_recover_lost_wallet 148 149 * 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...) 150 151 ### 4_backup_found_with_snackbar 152 153 * Christian: We need to inform the user that 'recover wallet' will NOT loose 154 their local wallet data/funds, but *MERGE* the two. 155 156 ### 5_recovering wallet and 18_recovering_wallet 157 158 * Torsten: One is that floating dialog that only shows a circular progress indicator. 159 This is a pattern from Android 1/2 and not used that much anymore. Nowadays, 160 the progress indicator is typically integrated into the UI. Our Android wallet 161 app uses that pattern already and shows a progress indicator below the action 162 bar and where the clicked button was. Maybe we should re-use the existing 163 pattern here rather than introduce a new one? 164 - Belen: I guess this also applies to 15_retrieving_credentials_and_backup as well as wallet backup > 4_creating_first_backup 165 166 ### 6_wallet_recovered 167 168 * Christian: There are a few error cases here, like when the wallet is now 169 'owned' by two devices and the user must choose which one should 170 continue to 'own' the data (this one = continue, other device = abort 171 restore). Florian, maybe you want to elaborate on other possible error 172 scenarios here? Or is this the only one? 173 - Torsten: As for error cases, I guess that the warden service is (temporarily) not 174 available or can't be reached is one of them. 175 176 ### 9_choose_policy 177 178 * Christian: There is usually more information we can give the users about the 179 challenges than just the cost. And that may be crucial: the user may 180 have set two security questions, but only remembers one of the answers. 181 Or they may have provided a phone number, but changed numbers since 182 then. Anastasis-gtk shows those details for a reason 183 184 * Christian: in case the user is waiting for a physical letter to arrive in the mail, we 185 need to think about how to suspend/resume the entire process nicely. 186 187 * Christian: in case the user the user has insufficient funds to pay for recovery, **we 188 need to think about how to suspend/resume the entire process nicely.** 189 190 * Torsten: As for error cases, I guess that the warden service is (temporarily) not 191 available or can't be reached is one of them. 192 193 ### 10_view_identity_verification_methods 194 195 * 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 196 satisfied 'in the background' (i.e. SEPA transfer completes) 197 198 ### 11_SMS_challenge 199 200 * 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 201 202 ### 16_last_challenge_solved_and_backup_found 203 204 * Christian: We need to inform the user that 'recover wallet' will NOT loose 205 their local wallet data/funds, but *MERGE* the two. 206 207 * Torsten: **A basic question about paying verification fees: If I want to recover/restore 208 my wallet, the most likely scenario is that I start with an empty wallet. So 209 how do I pay for recovery then? Do I first go through a multi-day top-up 210 process and only then can restore?** 211 - **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. 212 213 * Christian: **There are no more 'payment details' to show at this stage, the 214 payments have to be made earlier, _before_ the SMS is sent, and right 215 after the security question answer is provided.** 216 - **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. 217 218 ### 17_payment 219 220 * 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...