Comment by nullc
3 days ago
Just to give an example to prime your intuition: define your "usage token" as H(private_key|service_domain_name|date|4-bit_counter). Make your scheme provably reveal the usage token when you authenticate. Now you can use the service 16 times a day on a particular domain and no more simply by blocking token reuse. And yet the service has no ability to link different tokens to each other or to a specific person because they don't have anyone elses private keys.
You can make variations on this for a wide spectrum of rate limiting behaviors.
But also I agree with xinayder's comment-- the anticompetative, anti-privacy, invasive surveillance is unacceptable. There is a lot of risks with ZKP's that we just make the poison a little less bitter with the end result being more harm to humanity.
I think ZKP systems are intellectually interesting and their lack of use helps make it more clear that the surveillance is really the point of these schemes, not security because most of the security (or more of it) could be achieved without most of the surveillance.
But allowing the apple google duoopoly to control who can read online is wrong even if they did it in a way that better preserved privacy.
And because I can't believe no one else in the thread has linked to it: https://www.gnu.org/philosophy/right-to-read.html
This is useless. They want to be able to permanently ban an account that misbehaves - not limit it to misbehaving 16 times a day.
I have sympathy for the desire but that isn't something you actually get through google's surveillance-ware.
You can change the information you put into the hash in my example to get them one go per site per day or one per year or even one per site ever. But without giving cross site linkablity that does you no good or giving google visibility into everyone all the time.
But that still doesn't get you to your desired unevadable bans, but with suitable parameters it can get as close as google's spyware approach while being much more private.
I think time a time oriented rate limit makes the most sense considering the limits in practice (attacker just gets access to another discarded phone, or tricks someone into authenticating for them via theirs)-- basically means the best you can do against dedicate attackers is rate limit them. So why subject honest users who may have good privacy reasons to use multiple accounts over time to worse effective limits than attackers?
But you don't have to agree with that to accept that schemes much more private than google's are possible.
> define your "usage token" as H(private_key|service_domain_name|date|4-bit_counter)
But how are you preventing multiple services from using the same value for service_domain_name because they're cooperating to correlate your use?
Because-- in this hypothetical-- your user agent restricts the usage to the name displayed on the screen and also because your agent won't send the same value twice either (it'll increment the counter or tell you that its run out of tokens).
Requiring the name to be displayed isn't going to do much for ordinary people. They mostly wouldn't look at it and even if they did, "continue as-is or no service for you" means they continue as-is.
Not sending the same value twice would prevent them from being correlated, but now what are you supposed to do when you run out? Running you out could even be the goal: You burn a token to get a cookie and now you can't clear your cookies or you'll be denied a new one since you're out of tokens.
1 reply →