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

[Torsten Grote]

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?

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

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

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

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

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

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

> 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 ;)

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

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

Kind Regards,
Torsten