taler
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Taler] UI considerations for backup & sync


From: Christian Grothoff
Subject: Re: [Taler] UI considerations for backup & sync
Date: Tue, 21 Apr 2020 20:25:41 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0

Hi Torsten,

Thanks for the write-up, minor clarifications inline below.

On 4/21/20 8:00 PM, Torsten Grote wrote:
> Hi all,
> 
> Taler wallets should support Backup and Synchronization of their money
> and data. I am outlining a UI narrative below and would appreciate
> feedback. Disclaimer: I wasn't involved in the development of these
> services and only know what is written in the docs:
> 
>     https://docs.taler.net/core/api-sync.html
> 
> The idea of backup is that you don't lose the money (and payment data)
> saved in your wallet when you lose the wallet.
> The idea of synchronization is that you can use multiple wallets (e.g.
> mobile phone and desktop computer) with each wallet sharing the same
> money and transaction data.
> 
> The documentation sometimes talks about backup and sometimes about sync,
> but only has technical specs for backup, so I am not sure how both
> relate to each other (normally they are not the same thing), but it
> seems that one service provides both features at the same time.

We basically do 'sync' by restoring from backup. So indeed it is both
the same mechanism.

> These sync and backup providers are somewhat trustless and can
> optionally charge for their service in one (or more?) currency. Ideally,
> a wallet already comes with a list of these providers.

Only one currency (for now).

> When a wallet is opened for the first time, the user should be asked if
> they already have another wallet they want to sync with. If yes, they
> are shown the "sync with another device" screen. If not, the wallet just
> starts.
> 
> When making their first withdrawal, the user should be poked to set up a
> sync/backup service. If the user agrees, they are brought to the "choose
> provider" screen. The same screen is available in the sync+backup
> management section even before the first withdrawal.
> 
> When a provider is selected, the user is asked to read and accept their
> ToS. Then if needed, the user needs to pay for the service. Once
> everything is set up, the user is shown a private key in QR code or text
> format (maybe consider easier methods such as BIP39?) they need to store
> safely to be able to restore from backup or add another device.
> 
> After the user has confirmed that the secret is safely recorded, backups
> will be made automatically in the background to the selected provider.
> There is a backup/sync now button though (not sure if these are two
> different buttons, e.g. when no second device is set up).

Not sure we want the 'sync-NOW' button to be at all prominent. The
process should mostly be automatic (once configured). Now, via the
'settings' screen, I'd expect that one can:

1) add a backup/sync provider (initially)
2) delete a backup/sync provider (stop syncing)
3) _drop_ other devices from the sync group
   (if there are any)
4) ask to see the QR-code / show the secret
   needed to add another device to the sync
   group and/or restore from backup
5) 'sync now' (which is admittedly basically the
   button you talk about above, just well hidden)
6) Join a sync group (see below).

> To sync their wallet with another device, the user is shown a secret (we
> should probably *not* expose the private key here)

I doubt we can avoid that. Besides, whatever we do expose will basically
allow anyone who gets hold of it access to the full wallet (including
all the private keys in it). That's after all the point.

> and a Url in QR code
> and text format (for devices having no camera). This information needs
> to be entered in the other device (where?).

Well, QR code via the usual home button. The 'text' will be a
taler://-URI, so _theoretically_ the user could click on it from a
hyperlink (hopefully ONLY ever used if the link is sent via encrypted
e-mail). And in the 'settings' above we should have a "enter URL here"
option.

Now, that may not be sync-specific, we could use the same place to enter
all taler://-URLs manually that we otherwise get via NFC/QR code,
including payments, tips and refunds.

> It might make sense to ask
> the user to give a name to each device, so they later remember which
> device is which. Also, a screen to show connected devices and their sync
> status might be useful.

Indeed. And we'd want to show those names when allowing the user to
manage the sync group. And we should pick sane defaults based on what we
can find about the device per introspection (phone model + OS, browser +
hostname, etc.)

> Further feature that were desired in the documentation is a way to
> export the backup config (key + url) and to disable sync and backup
> entirely. I am not sure it is a good idea to expose the key material in
> a second time as it becomes available to physical attackers this way and
> can't be stored in a secure element (available on most modern mobile
> devices).

I doubt the secure element solution will work anyway, because you're not
yet having Anastasis in your scopes (which is fine, that's after all the
_next_ step after Sync/Backup).

> To summarize what I read out of the docs:
> 
> Screens:
>   * onboarding first start: sync another device
>   * onboarding first withdrawal: set up sync/backup
>   * list of services per accepted currency (or free)
>   * ToS of provider
>   * Show Sync/Backup Secret (key+url)
>   * Show Sync/Backup Secret to add another sync device

The two screens above are in my mind identical. What you need to add
another sync device is exactly the same as what you'll need to restore
from backup.

>   * Status page (last backup, last sync with which connected devices)

Note that we _could_ "assign" parts of a balance to a particular device
in a device group, to make that device use that share of the balance
'first'. While that can technically help make transactions a bit faster
and more reliable, I _suspect_ we'd want to not expose that detail to
users and just do equal shares at first, and then maybe auto-rebalance
preallocations based on proportional
spending detected. Anyway, that's a very, very fancy feature I'd rather
hide than have to explain ;-)

> Actions:
>   * chose provider
>   * accept ToS
>   * pay for provider
>   * add (and remove?) sync device

Definitively also remove. Upon removal, we can decide which share of
each balance is to remain with the removed device vs. the rest of the group.
However, there we need to make clear that device removal does not work
against _malicious_ actors for the existing shared balance (i.e. they
can still access and spend the balance not assigned to them IF they
'hack' the wallet).

>   * add/remove providers
>   * disable sync and backup

I'd think that happens if you remove all providers or all devices. Not
sure we need a separate option (which could be used to temporarily
suspend/resume sync/backup, but that's IMO a feature nobody needs)

>   * export backup config (key + url)

The key is in the URL. The question is what 'export' means here. Showing
the QR code is already in the dialog above. Copying to clipboard seems
risky, so we should warn the user to only pass the URL via end-to-end
encrypted channels to their other devices that way.

> Christian and Florian, please let me know if I misunderstood or missed
> something that should be added to those considerations.

I think you got pretty much all of the sync/backup part of the design
\o/ :-)

-Christian

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]