taler
[Top][All Lists]
Advanced

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

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


From: Christian Grothoff
Subject: Re: [Taler] backups with fast sync via notification servers and link passwords
Date: Thu, 1 Mar 2018 13:00:36 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

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. 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.  Now you can argue
that Android/iOS users have no privacy vs. Apple/Google's notification
servers anyway, but that's not exactly true as we now establish a link
between the user's *desktops* and their mobile phones which may not have
existed before.  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!

So in my view, using notification servers may be *more* problematic than
using a backup server.

> If we must take
> coins, then we only warn the users afterwards that they should not take
> coins like this.  We might provide a "fine print" privacy warning on the
> linked wallet list screen, but overall this sounds minimally dangerous
> because it's rare and wallets may chatter over notifications servers
> anyways.  It does suck to use google or apple's notification server, so
> maybe we should use our own.

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. So there is a technical advantage to using the
existing infrastructure here. Also, I do not think we should design with
the assumption that our servers are any more trustworthy than those of
Google or Apple.

You started this by saying that using the backup server (which
presumably we would operate initially) in a predictable way is
problematic. I can agree with that. But replacing it with _another_ type
of server (whether operated by us or by the phone OS manufacturer) and
in effect leaking _more_ data is hardly a good answer!


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.

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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