taler
[Top][All Lists]
Advanced

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

Re: [Taler] Synchronization and backup


From: Christian Grothoff
Subject: Re: [Taler] Synchronization and backup
Date: Fri, 16 Feb 2018 18:32:56 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

On 02/16/2018 06:10 AM, Jeff Burdges wrote:
>> Are you saying we should not include a multi-device synchronization
>> functionality at all?
> Yes, there are way too many nasty failure modes without any clear unique
> benefits realized by normal users.  Afaik sync cannot be made user
> friendly.

That's a very radical, but interesting, position to take. We did already
implement (for 0.5) the recovery scenario where the user _thought_ he
had unspent coins, used them during a transaction and then had to abort
because the coins were already spent.  This could happen after an
(outdated) backup was restored, or due to unsynchronized wallets which
is the failure case you are worried about here.

To put it in my words, there are two main usability issues you raise
with sync:

1) 'surprising' behavior for users (balance changes, failed payments,
etc.) due to not being in sync (and being in sync may not be something
we can guarantee, see some devices being offline until contact with PoS)

2) Usability (KX) issue for initially linking up devices to use the same
key for synchronization.


I think (2) can be "largely" fixed over time, starting with diceware and
progressing to NFC.  I would expect >50% of users can handle that, and
if then sync works "well" for them, that would suffice.

Now (1) is more tricky, but again I think manageable: we do _know_ why
the balance changed unexpectedly, we do _know_ why the payment failed,
and we get crytographic proof *and* know we should synchronize to really
fix it all.  Similarly, unless it is not multiple devices of the same
user, but multiple users sharing a wallet, the *user* will also have a
clue as to what is going on.  So this can be explained, making (1)
largely an issue of UX design: how to explain the "sudden" balance
change.  How to warn users about syncing wallets between different persons.


Finally, yes, I agree with you that due to the risks and usability
issues (privacy, balance change, need for authentication/key exchange),
sync may not be a feature for everybody or all devices.  But there are
users that will be able and willing to navigate this.

More importantly, there may even be use cases where this is necessary!
Imagine you having a Taler-wallet device that cannot directly implement
withdraw, say either because it doesn't have a proper browser
(Taler-enabled NFC-stick), or even the inverse situation: because it's a
desktop and your bank requires withdraw via NFC at an ATM.  Such devices
would _require_ being synced with a "full" wallet.


To conclude, in my view "backup" is essential, so we should implement
this first. Furthermore, let's do this in a way that we can twist backup
servers into sync servers. And finally, let's then try to optimize the
user experience for sync to be as nice as we can make it, while ensuring
appropriate warnings about privacy risks are in place.

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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