Re: Hello directly from Jimbo at Wikipedia

[Nick Mathewson <nickm@xxxxxxxxxxxxx>]

On Tue, Sep 27, 2005 at 05:47:06PM -0400, Jimmy Wales wrote:
 [...]
> So if you're going to suggest that we require logins or referrals for
> new users or anything along those lines, it's a nonstarter.

What about logins for new users on Tor only?  That is, suppose you
allowed non-logged-in posts, and allowed posts with Tor, but not
non-logged-in posts with Tor.  Would that also be a nonstarter?

 [...]
> I haven't yet seen any response to my proposal, which I blogged about:
> http://blog.jimmywales.com/ -- and I think it was posted to this list as
> well.

Something kind of like your proposal might work, but it has problems.

For reference, the proposal is (verbatim):

    Here is a simple solution to the problem of Tor users being unable to
    edit Wikipedia

    trusted user -> tor cloud -> authentication server -> trusted tor
    cloud -> wikipedia

    untrusted user -> tor cloud -> authentication server -> untrusted tor
    cloud -> no wikipedia

    Simple.

I'm sure you realize that there's a lot of gray area in this design,
so let me try to fill some of it in, and I'll comment as I go.

Clearly, users are authenticating to the authentication service using
some kind of pseudonymous mechanism, right?  That is, if Alice tells
the auth server, "I'm Alice, here's a password!", there's no point in
having a Tor cloud between Alice and the authentication server.  So
I'm assuming that Alice tells the authserver "I'm user999, here's a
password!"  But if "user999" isn't linkable to Alice, how do you stop
an abusive user from creating thousands of accounts and abusing them
one by one?

Second, the authentication server needs to be pretty trusted, but it
also needs to be able to relay all "trusted" users' bandwidth.  That
introduces a bottleneck into the network where none is needed.
(There's a similar bottleneck in the "trusted cloud" concept.)

Third, how do users become trusted or untrusted?  Who handles abuse
complaints?

Fourth, the design seems to envision only a single authentication
server, and ties the authentication server into the Tor network
design.

I think you can solve most of the above problems with the architecture
I discussed earlier on this thread.  It would look something like:

Step 1:
  User <-> Authentication server

  (Establish a blinded credential, perhaps rate-limited by scarce IPs
  or email addrs or something.)

Step 2:

  User -> Tor network -> Authentication server

  (Prove to authentication server that user has a given credential.
  Get a short-lived token for use with wikipedia)

Step 3:

  User -> Tor network -> wikipedia

  (User proves to wikipedia, "hey, I've got a recent credential for
  pseudonym X from authentication server Y."  Wikipedia decides
  whether it's banned nym X.)

The weak point here is the transition between step 2 and step 3.
Unlike your design, this doesn't fit exactly into mediawiki's existing
"these IPs are good; these IPs are blocked" implementation, so more
code would be needed.  Other interfaces could be possible, of course.

It does have the advantages, though, that the authentication server's
bandwidth needs are comparatively modest, that it's hard for bots and
jerks to create boundless numbers of accounts, that wikipedia can make
its own decisions about which users to ban, and that the
authentication service remains independent of the Tor network, so that
people can run different servers with different policies.

How does this sound to you?

yrs,
-- 
Nick Mathewson