[taler-large-media] branch master updated: Feedback on wallet backup and recovery - 31 August 2021

[gnunet]

This is an automated email from the git hooks/post-receive script.

belen pushed a commit to branch master
in repository large-media.

The following commit(s) were added to refs/heads/master by this push:
     new 6ee65ed  Feedback on wallet backup and recovery - 31 August 2021
6ee65ed is described below

commit 6ee65ed580e670e0acb0f8e70f47030174bcea0f
Author: Belen <belenbarrospena@gmail.com>
AuthorDate: Tue Aug 31 14:22:09 2021 +0100

    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>
---
 anastasis_integration_wallet/feedback_31082021.txt | 220 +++++++++++++++++++++
 1 file changed, 220 insertions(+)

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 prin [...]
+
+### 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 [...]
+       - 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 [...]
+
+* 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 info [...]
+       - 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...

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.