[Top][All Lists]

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

Re: [Taler] Synchronization and backup

From: Jeff Burdges
Subject: Re: [Taler] Synchronization and backup
Date: Fri, 16 Feb 2018 06:10:56 +0100

On Fri, 2018-02-16 at 04:58 +0100, Florian Dold wrote:
> > There is no way for wallets to know their own balance if they share
> > active coins, so syncing wallets necessarily harms usability.  Anonymity
> > costs would prove catastrophic too.
> This is only true if no sync happens before a spend.

Incorrect because purchase decisions are made before payment.  In your
scheme, users will shop based on a balance displayed on their offline
device, but the balance will suddenly drop when they attempt to pay.  

You cannot simply explain jumps in the balance, so users will blame the
store for their money disappearing during checkout, or blame Taler for
jumps at other times.  It's disastrous for usability. 

Also, there is no way for a device to predict if it will be online or
offline.  In principle, you might only display balance only immediately
after sync, but that's awful for travelers, people with limited data,

Also, if families share reserves then this balance still jumps
unpredictably.  Imagine people stranded without a taxi because another
family member bought something.  Imagine family members wasting money
because they observed a higher balance.  etc. 

> 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

Any actual benefits syncing provides could afaik all be provided in far
more straightforward ways.  It's clear for example that collaborative
paying provides a fairly intuitive user experience.

Also, there is no consistent interface to syncing across devices,
assuming you can even sync two tiny card devices with only an approve
button, while collaborative paying works there.

> 2. make the more "paranoid", power-user functionality available, and
> probably make it the default for the Tor browser

As soon as you separate the "paranoid" users then you doom almost
everyone to insecurity.  It's fine if some users have threat models
beyond our reach of course, but all customers should receive a basic but
strong degree of anonymity vs the exchange, merchant, etc.

> > Also, any networked backup system we design requires moving initial key
> > material, so only power users benefit anyways.  
> A passphrase is not a concept that limits usage to power users.  If our
> backup/sync system is limited to power users, it's not a good one.

Actually passphrases are extremely difficult for users, but yes once you
depart from vanilla login scenarios they become power users features.  

Also 128 bits of entropy means a 10 word diceware passphrase, although
temporarily with seeding and stretching helps, but memory hard
stretching conflicts with running on low end devices, so meh. 


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

reply via email to

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