Re: [Taler] [address@hidden: 'Oh, that's an idea...': U.S. parents respond to China screen time ban]

[Jeff Burdges]

> On 8 Sep 2021, at 03:05, Jacob Bachmeyer <jcb62281@gmail.com> wrote:
> How does your proposed system handle a "borrowed" or outright stolen user 
> key?  The server cannot identify the user, so how can Mallory walking off 
> with a copy of Alice's key be detected?

Slowly.  :)

If Alice updates her entry in the ring then the new ring gives her all new 
accounts everywhere.  We must expire old rings but we do not want all users 
building new heavier zk proofs everytime the ring updates.

We’d maybe implement a special joining ring with a signature so that Alice 
could initially join and later rejoin instantly.  We’d maybe have a staging 
process by which multiple regular ring iterations could be accepted 
simultaneously too.   It follows some overlap exists between Alice’s new 
accounts and the thief accessing her old accounts.

If Alice has backed up her key, then she could deprecate individual important 
accounts instantly via some migration protocol, but if she lost her old key 
then only the thief accesses her old accounts but only until the old ring gets 
deprecated.  

It’s always tricky to set expiration times:  If mobile devices can only produce 
the heavier proofs when plugged in, then old rings could be expired like every 
24 hours I guess.  Yet, if you disappear offline for a few days then you need 
internet access and this computation time before using the system.  This 
computation time is likely similar to a zcash tx.

We’ve an issue that thieves like perhaps governments who access Alice’s key 
could identify her across all websites.  Any single use token protocol reduces 
this problem, ala CloudFlare’s PrivacyPass, but then websites cannot block 
missbehaviour and the system requires careful rate limiting.  

Jeff