Re: [Taler] Technical questions for backup/sync (was: UI considerations for backup & sync)

[Christian Grothoff]

On 5/22/20 2:22 PM, Torsten Grote wrote:
> On 2020-05-21 15:09, Christian Grothoff wrote:
>> Nice. I'm missing an arrow from the "Backup Settings" to "Backup
>> Secret": it is possible that I have a backup, and just want to review
>> the secret.
> 
> I had left this out intentionally, because normally you don't reveal
> your secrets again after the user has stored them off-device.
> Especially, if there's only one master secret that everything is tied to.>
> For example, how do you prevent someone who casually gets one-time
> access to my phone from copying the secret and then regularly
> downloading and decrypting my backup thus knowing exactly what I do with
> my wallet?

Yes, I understand this is an issue, and we _may_ want to add some 'lock'
screen to block access, or have a check box on that screen to "never
show this again" to disable the ability to quickly show the access code.

However, I also see this 'show the secret again' as an easy/convenient
way to (deliberately) add another device to the sync group. Here, asking
the user to type it in (or scan a copy of the printed QR code) seems not
very user-friendly. And at the time when I setup the backup, I may not
have a printer (or 2nd device to sync) readily available, so an option
to show the code again later seems important.

Furthermore, showing the code again may also be a good entry point for
setting up Anastasis: exporting the secret via Anastasis may take more
time to do, but other than speed the threat is the same -- if I can
share your sync secret via Anastasis with myself, I end up with access
to your data.

So yes, I do see your concern, but I think having an option to disable
it (i.e. if a user is pretty sure that they have a sound backup), or to
set a lock (pin, pattern, default screen-lock, etc.) to prevent "fast"
access, is likely better than not supporting it at all.

>> So if a backup exists, there should be a forward transition
>> from the "Backup Settings" to the "Backup Secret" dialog.
> 
> If you want to support more than one backup service, this gets more
> tricky, because each service has its own secret, right?

I think each service should have its own secret, but we can and should
be able to simply derive all of them from some immuatable master secret.

However, there is a possibly HUGE issue here, in that I may start with
two independent devices, two wallets, and thus two independent master
secrets. I may even setup Anastasis for _both_. Now what happens if I
then start to sync those devices? Now I have two master secrets. I think
in this case we need to pick one of them (i.e. the numerically smaller
one), update the derived sync secrets, update all backups on the sync
servers, update all Anastasis policy documents, and somehow (hard step!)
inform/teach the user which of the two master secrets they need to
preserve. Messy.

> So there needs to be some extra screen that shows the currently active
> services and makes the secrets available there thus making them a lot
> harder to discover.

I think for the display of the master secret (QR code, Anastasis, etc.),
that should not change if the backup services change.

> This could maybe be integrated into the choose backup service screen
> that already has a list of services. So it could show the active
> services at the top along with an option to show their secret.

I'd only show the (invariant) master secret, not the individual sync
server's secrets.

>> I'm not sure if this is covered by your diagram, but I think we can have
>> more than one sync provider.
> 
> No, so far I had planned with only one backup service active at a time.
> If you really want to support an arbitrary number of active services,
> this makes things slightly more complicated.

With backups, I generally feel better if there is not just one ;-).

>> In fact, we probably must allow this to make the wallet state a CRDT.
> 
> Do you mind elaborating on this? Would be good to understand where the
> multiple backup services requirement comes from.

Not a technically strict argument, but if we think of the wallet state
as a CRDT, then we know how to build CRDTs with sets where there is an
"add to set" option.

If we have as an operation to "set sync server" (instead of "add sync
server"), I don't think a CRDT is possible on a (destructive) "set"
operation because depending on the order of two "set" steps the final
result would have to be different.

>> If we just talk about backup/sync, with the small change above, I agree
>> with the diagram. If we add Anastasis into the mix, we'll need more. But
>> maybe let's take it one step at a time ;-).
> 
> Yes one step at a time please. Can Anastasis handle multiple backup
> services?

Anastasis stores a "core secret" for you, which, except for some
semi-arbitrary protocol limitations is just a byte buffer for Anastasis.
So if your "core secret" isn't just 256 bits but maybe 1024 bits of key
material and a few kilobytes of URLs for the backup services, that
should be no problem. I would expect that we'll impose some limit like
64k (just to avoid someone abusing it for storage and increasing our
costs), but technically there is no fundamental issue (beyond cost) even
if we had to do megabytes. (It is, however, for various reasons not
suitable for directly storing the full wallet content -- especially as
Anastasis has to keep previous revisions around --, so that should
really go to the sync server which only keeps the latest revision.)

>>> Note that I focused on the backup use-case for now as it has the higher
>>> priority and is complicated enough on its own. We can add sync with
>>> device management later.
>> I think sync mostly changes what we show in Backup settings. Given the
>> 'backup secret', we should be able to add another device to the sync
>> group simply by 'restoring from backup' with that sync secret.
> 
> If you want easy and user-centric device management with the ability to
> exclude compromised devices, I'm afraid things will get a bit more
> complicated, but that's another step.

Hah! Of course we _want_ everything ;-). But yes, I understand miracles
take time.

>>> How is restoring from backup supposed to work? Does the user just scan
>>> the QR code with the taler-sync:// URI or is there a dedicated place in
>>> the UI to hand that URI manually?
>> I would say both. I would show the QR code as the "Backup secret" (maybe
>> only if the user clicks on "show QR code"), and possibly give the option
>> to "print QR code" (if supported by the platform). But we should _also_
>> show the URI to be written down (yes, painful), and thus also should
>> have a way to enter URIs. But we should support users entering URIs by
>> hand _anyway_, even for taler://pay/-URIs.
> 
> I can already add an option somewhere in the wallet to enter URIs by
> hand. I am just worried that users might not realize that they just scan
> their backup code like they scan payment codes. It might be too easy ;)
> So it is possible that users look for a dedicated restore from backup
> option.

Well, I would expect this to be in the FAQ and other places. Also, I
hope we can "teach" users that "scan QR code" works for "everything":
add exchange, add auditor, withdraw, pay, tip, refund -- and restore
from backup.

>> I just had the Anastasis devs
>> effectively have that problem: they have a taler://pay/ URI, and would
>> need to turn it into a QR code to pay with the F-droid wallet. So having
>> an "enter taler://-URI" feature for _all_ types of taler://-URIs would
>> make sense.
> 
> For the time being, they can also just open a document with <a
> href="taler://pay/">link</a> in their browser and click that. Maybe
> that's easier than making a QR code ;)

Well, I told them about taler-wallet-cli. But it's good to see that the
wallet now has a way for manual entry, even if hidden.

>> Oh, and I think it should be taler://sync/, not taler-sync://.
> 
> Fixed: https://git.taler.net/docs.git/commit/?id=875a6a5bd

:-)

>>> What happens when the payment period expired? Does the service still
>>> allow to restore and requests a new payment afterwards? Just blocks new
>>> uploads in the meantime?
>> It deletes the backup. You pay for the storage for a time period. So
>> like X months before the payment expires, the wallet really MUST alert
>> the user to it and prompt for the user to extend the service duration by
>> paying again. We may want to even support an "auto-pay" feature for this
>> one.
> 
> Auto-pay makes sense. I am still worried however that my phone gets
> stolen before me or my wallet could renew payment and my new phone only
> arrives after the service already has deleted my backup. Would be good
> to avoid that scenario.

I think the answer is to auto-renew (or remind) the user not 5 minutes
before the backup expires, but like 3+ months in advance. IIRC the
subscription(s) are always (per protocol) for a full year, so a 3+
months notice should in most cases be sufficient for recovery.

>>> I imagine after a positive confirmation from the service, it will tell
>>> us that the latest backup is from date X and asks for confirmation of
>>> restore. Do we have the option to restore older backups as well?
>> The service only stores the latest version.
> 
> Is this a real backup then? Sounds more like (slow) sync than real
> backup. If I accidentally deleted some important transactions, I want to
> look up later, I can't simply restore from backup to get them back?

Deleted is deleted (modulo the trash bin discussion we had). For privacy
reasons, I think this really has to be the case. We can't have someone's
phone seized at the border, and some random security guard find
compromising purchases in ancient backups despite them having been
deleted.  We'll make it difficult for you delete coins/money, but for
the rest I'd go strictly for making sure there are no privacy pitfalls.

>>> What happens if there's already another backup service in use?
>> I'd say we sync to all of them.
> 
> Ok so restoring from backup also sets up that backup service.

Yes.

-Christian

signature.asc
Description: OpenPGP digital signature