[tortalk+Steven.Murdoch@cl.cam.ac.uk: Re: Hello directly from Jimbo at Wikipedia]
Sorry for the flood, but this is winding down already. What I didn't like about this discussion is that all concerned parties seem to have been shouting into space past each other, just trying to make a noise instead of understanding and solving the problem. ----- Forwarded message from "Steven J. Murdoch" <tortalk+Steven.Murdoch@cl.cam.ac.uk> -----
No, this is important. If this isn't Cypherpunks material these days then nothing is. As for the Wikipedia folks, I can't imagine having a more intelligent batch of people disagree. There's is a very practical matter: Reducing the hassles, particularly when said hassles in general deteriorate the content/bullshit ratio they see. On the other hand, they seem to clearly "get" the value of Tor, and have practically extended an invitation for a solution that will truly make things better while not significantly increasing their hassles. That the Wikipedia reaction to TorSpam is perhaps regrettable is obvious, but given their goals (not particularly Cypherpunkly) it really does make sense: No one's paid at Wikipedia and no one's going to do all the work of cleaning up the slung feces. In other words, their clipping off one of the side-lobes but increasing the remaining signal-to-noise. Just brute force logic. Sorry. But the door is open for solutions and they do seem to understand the issues. Not bad, and the long-term solution may be very interesting... -TD
From: Eugen Leitl <eugen@leitl.org> To: cypherpunks@jfet.org Subject: [tortalk+Steven.Murdoch@cl.cam.ac.uk: Re: Hello directly from Jimbo at Wikipedia] Date: Thu, 29 Sep 2005 14:02:32 +0200
Sorry for the flood, but this is winding down already. What I didn't like about this discussion is that all concerned parties seem to have been shouting into space past each other, just trying to make a noise instead of understanding and solving the problem.
----- Forwarded message from "Steven J. Murdoch" <tortalk+Steven.Murdoch@cl.cam.ac.uk> -----
From: "Steven J. Murdoch" <tortalk+Steven.Murdoch@cl.cam.ac.uk> Date: Thu, 29 Sep 2005 00:27:51 +0100 To: or-talk@freehaven.net Cc: Jimmy Wales <jwales@wikia.com> Subject: Re: Hello directly from Jimbo at Wikipedia User-Agent: Mutt/1.4.1i Reply-To: or-talk@freehaven.net
On Tue, Sep 27, 2005 at 05:48:59PM -0400, Jimmy Wales wrote:
All I'm saying is that Tor could segregate users easily enough into two clouds: "We sorta trust these ones, more or less, a little bit, but no guarantees" -- "We don't trust these ones, we don't know them".
This would be very difficult to do using the existing Tor design as it doesn't know anything about users or sessions. It lives at the TCP layer and all it does is shift packets from one IP address to another, giving some privacy to both ends. Adding higher layer functionality to Tor increases the chance that it will do neither job well, so here is a proposal which I think does what you want, but avoids this problem.
The goal is to increase the cost for a Tor user to commit abuse on Wikipedia. It doesn't need to be full-proof, but just enough to make them go elsewhere. Wikipedia could require Tor users to log in before making edits, and ban accounts if they do something bad. However the cost of creating new accounts is not very high. The goal of this proposal is to impose a cost on creating accounts which can be used though Tor. Non-Tor access works as normal and the cost can be small, just enough to reduce the incentive of abuse.
Suppose Wikipedia allowed Tor users to only read articles and create accounts, but not able to change anything. The Tor user then goes to a different website, call it the "puzzle server". Here the Tor user does some work, perhaps does a hashcash computation[1] or solves a CAPTCHA[2], then enters the solution along with their new Wikipedia username. The puzzle server (which may be run by Wikipedia or Tor volunteers), records the fact that someone has solved a puzzle along with the username entered. The puzzle server doesn't need the Wikipedia password as there is no reason for someone to do work for another person's account.
Now when that Tor user logs into their Wikipedia account to edit something, the Wikipedia server asks the puzzle server whether this account has ever solved a puzzle. If it has, the user can make the edit, if not then the user is told to go to the puzzle server first. This check can be very simple - just an HTTP request to the puzzle server specifying the Wikipedia username, which returns "yes" vs "no", or "200" vs "403". For performance reasons this can be cached locally. There is no cryptography here, and I don't think it is needed, but it can be added without much difficulty.
If the Tor user starts committing abuse, his account is cancelled. The puzzle server doesn't need to be told about this, as Wikipedia will not let that user make any edits. The reason this approach avoids the usual problems with proof-of-work schemes[3] is that good Tor users only have to solve the puzzle once, just after they create the account. Bad Tor users will need to solve another puzzle every time they are caught and had their account cancelled.
So my question to Jimbo is: what type of puzzle do you think would be enough to reduce abuse through Tor to a manageable level? The difficulty of the puzzle can be tuned over time but what would be necessary for Wikipedia to try this out?
Hope this helps, Steven Murdoch.
[1] http://www.hashcash.org/ [2] http://www.captcha.net/ [3] "Proof-of-Work" Proves Not to Work by Ben Laurie and Richard Clayton: http://www.cl.cam.ac.uk/users/rnc1/proofwork.pdf -- w: http://www.cl.cam.ac.uk/users/sjm217/
----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE
[demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
participants (2)
-
Eugen Leitl
-
Tyler Durden