Re: [Taler] Synchronization and backup

[Jeff Burdges]

On Fri, 2018-02-16 at 18:32 +0100, Christian Grothoff wrote:
> 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)
...
> 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.  

Proof sounds useless here.  At best you could display information from
contracts, but that's not much.

> 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.  

This is false.  It's common for people to be without a clue even when
all the pieces lay right in front of them.

> So this can be explained, making (1) largely an issue of UX design:
> how to explain the "sudden" balance change.

This is also false.  You can do notifications but people will ignore or
miss them. 


My points are:

We should not attempt to sync immediately before purchase like Florian
suggests because that's catastrophic to user privacy and presents
terrible failure modes. 

There are serious privacy concerns with syncing after checkout or based
on non-specific activity, ala unsleep, browser start, etc., but at least
those should not result in violence.  An random infrequent backup sound
within the Tor threat model though.

Afaik, the only user friendly solution is for coins to be locked to
wallets and be unspendable by other wallets.  It's okay to override
this, but only upon user request.  Actually doing this override quickly
likely requires warnings. 


> 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.

Sure.  These devices cannot explain balance changes easily, so they
really must know exactly what coins they own and what coins they gave
away.  It's fine if they hold back ups for other wallets of course, so
long as they know they cannot spend those coins.

> 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. 

This requires the coin database be extended to handle coins treated as
unspendable due to being owned by other wallets.  If you restore a back
up containing only coins owned by the wallets existing reserve key then
the wallet can treat them as its own coins, but the interface becomes
more complex otherwise.

Jeff

signature.asc
Description: This is a digitally signed message part