Re: [Taler] backups with fast sync via notification servers and link passwords

[Jeff Burdges]

On Thu, 2018-03-01 at 13:00 +0100, Christian Grothoff wrote:
> On 03/01/2018 01:21 AM, Jeff Burdges wrote:
> > In this scheme, we do not access backup servers in a predictable way
> > either before or after a spend or refresh operation, so anonymity sets
> > are not necessarily reduced by network traffic, although we must think
> > more about the database's own privacy properties.
> > 
> > Instead, we contact request coins from linked wallets directly through
> > notification servers, and possibly their backup servers, but only during
> > the rare event that spends exceed the device balance.  
> 
> I'm confused. 

I think this plan should only be considered at best half baked.  :)

> You don't like using the backup server because that
> network activity is problematic for privacy. But you're happy to use the
> notification server --- which just like the backup server implies
> network activity that is problematic for privacy.

We want to make the privacy violating events rare and trigger warnings
in the worst cases. 

If all users with sync contact their backup server shortly before and/or
after every purchase, then this will reduce the anonymity set for all
users.  In particular, all "good privacy minding" non-sync users now
live in their own isolated anonymity set distinct from sync users.  And
good users loose convenient backups to linked devices.

If instead, we request coins from linked wallets only right when we
exceed our wallet's balance then we worsen privacy only for the
offending user.  We can occasionally warn offending users to manage
their balances to improve privacy, security, financial planning, and buy
when offline.  In this scheme, there is no penalty for otherwise "good"
users who link an old tablet for backup purposes, without ever actually
using it.

In this request scenario, if all devices can communicate quickly, then
we even avoid double spending and thus avoid giving merchants any
deanonymizing.  If otoh some linked device does not respond, then we
risk double spending, and thus risk deanonymizing users to merchants.
We should always warn users about their poor privacy habits whenever we
risk double spending like this, but doing so after the fact may suffice.

Also, our devices never actually download one another's backups in
advance, but merely possesses access token for them on the backup
server, which makes lost devices less dangerous.

In summary, we weaken privacy for badly behaving users against network
adversaries, and forbid anything but offline devices from even
attempting balance override, while we strengthen privacy for everyone
else, reduce the pond-like requirements on backup servers, and even
strengthen privacy for bad users against merchant adversaries.  

In all this, our major technical hurdle becomes quick communications
between the users' devices, but some failures remain acceptable.

> Worse, the desktops/notebooks would also have to
> subscribe to some notification server, which now makes the user more
> trackable, say, when traveling with a notebook --- and that even if no
> Taler activity is happening at all, as we would need to listen for
> notifications regardless of Taler being in active use!

I agree this sounds problematic.  I suppose the Tor browser wallet could
receive notifications via a .onion, although this makes performance
tricky.  I've no great solution for normal browsers, but..

If the browser is not running, then the wallet is not running anyways,
so maybe requesting coins from browsers simply never works.  In this
case, we place them latest in the linked wallet list and take coins if
needed, so always giving the stronger privacy warning, and always
demanding any passwords.  

> There is another practical concern you are ignoring here, which is that
> if a device subscribes to multiple notification servers, it requires
> more resources (bandwidth, battery) then when using only one
> notification server.

Good point.  We could send only "check your backup" messages via
Apple/Google's notification server, probably from the backup server
itself, or Tor.  We could make the backup server send these messages for
other reasons, and/or needlessly.  We could even increase the "check
your backup" message size to suffice for coin requests.  I've no idea if
backup servers should track wallet uptime to respond more quickly to
coin requests.

> With respect to the rest: I'm OK with explicit transfer of funds between
> devices and with (optional) password protection as you propose. But the
> real-time notification you suggest seems to create problems that are
> _bigger_ than the one you are proposing to solve.

Florian has several concerns: 

In demos, anyone asking about sync thinks in terms of DropBox, but we
lack the time to explain the details.  Actually they criticize our
"walls of text" too, but these privacy and security warnings can
frequently be device notifications warning the user about what they just
did. 

We face wallet forks if either (a) we're not simple enough, or (b) we
lack features.  We expect (b) to be small change, but (a) remains a
threat.  Yes, this fork's "better usability" means "looks simpler but
creates confusion, makes thieves more dangerous, etc." but users will
never know until after they get screwed.*  Actually evaluating all these
scenarios remains tricky, but I agree the wallet should be user friendly
enough to discourage forks.

Jeff

* Amusingly, Apple's App Store might provides some protection against
Florian's concern, since anyone doing this must technically reimplement
the GPL parts, but maybe that's not useful for a GNU project.  ;)

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