Wikipedia proposal

[Jason Holt]

I just posted this to wikitech-l:

There has been a lot of discussion lately on the or-talk list about
how to let tor and other anonymizing proxy users edit wikipedia without
allowing vandals free rein. Several straightforward approaches have been
proposed, such as holding edits in escrow pending approval by a trusted
user, and requiring anonymizing network users to login before posting.
The latter idea in particular could easily be abused, since abusers can
create a new account for each edit.

Roger Dingledine, tor's author, suggested creating a pseudonym service
using a cryptographic construction called blind signatures:

http://www.rsasecurity.com/rsalabs/node.asp?id=2339

Basically, Alice can generate a token, mathematically blind it
(obscuring its value), have it signed, then unblind the signature.
Anyone can verify that the signature on the token is valid, but nobody,
including the signer, can link the blinded value Alice had signed with
her unblinded token.

I implemented such a scheme which works as follows:

* Alice creates and blinds a token, then submits it to a token server
for signing.  Optionally, the token server may have a list of IPs banned
from wikipedia, and refuse to sign Alice's token if her IP is on the list.

* The token server signs the blinded token, then records what IP address
Alice used so that she can't obtain multiple tokens per IP address.
Later, this will allow us to block Alice's IP address if she misbehaves,
just as Wikipedia admins currently do, except that now it'll work even
when she connects via tor.  Token rationing could also be done based
on other (more or less) scarce resources, including email addresses,
captchas, CPU-intensive tasks or even money, just as I'm sure has been
proposed for the vanilla wikipedia.  The advantage of blind signatures is
that tokens can be recorded and blocked without revealing the potentially
sensitive underlying resource (such as a personal email address or
IP address).

* Alice can now turn on tor and present her token to wp, without revealing
her actual IP address.  This token takes the place of the IP address
record currently stored along with article edits, and can be blacklisted
just the same way that IPs are banned.

* However, I implemented an intermediary step which has several
advantages.  Instead of presenting her token to wp, Alice generates an
essentially empty client certificate and presents it via the tor network
to a certificate authority (CA) for signing, along with the signed token.
The CA records that the token has been "spent" (preventing her from
receiving multiple certs per token), then signs her cert just as Verisign
would sign a server SSL certificate. Since she connects via tor, the CA
doesn't learn her real IP address.

* Alice installs the client certificate in her browser, then connects
to a special wp server running an SSL server that demands valid client
certificates from our CA.  That configuration takes only 4 lines in my
apache-ssl server's httpd.conf.  Apache automatically sets environment
variables which identify the client certificate, and which can be used
in place of the REMOTE_ADDR variable currently used to record users'
incoming IP addresses when marking page edits.  Blocking a client cert
would then be just as easy as blocking an IP address.

All of Alice's edits will be marked with that identifier unless she
obtains a new IP address (or other scarce resource) and repeats the
process to obtain another certificate.  Later, features can optionally
be added which will allow her to have separate identifiers for each edit
(protecting her in case, say, her repressive government confiscates her
computer in order to find out if she wrote a particular article they
disagree with).

I have already released code to implement this system, with the exception
of the wp-specific code. I sent the proposal to both the or-talk lists
and the cryptography list at metzdowd.com on Monday. Next I'd like your
comments, before I dive into the mediawiki code (or find someone willing
to help with this part).  Once the feature is complete, we can set up a
live test wiki for people to bang on, before we consider implementation
on the live wp servers.

                                               -J