[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: Hooking nym to wikipedia



Note I'm not on the cryptography@xxxxxxxxxxxx
Feel free to forward if you like.

On Tue, Oct 04, 2005 at 11:35:43AM -0700, cyphrpunk wrote:

> 
> As far as the Unlinkable Serial Transactions proposal, the gist of it
> is to issue a new blinded token whenever one is used. That's a clever
> idea but it is not adequate for this situtation, because abuse
> information is not available until after the fact. By the time a
> complaint arises the miscreant will have long ago received his new
> blinded token and the service will have no way to stop him from
> continuing to use it.
> 

This is not true. Let me explain a bit further. The paradigm example
in designing UST was for accessing material in a paid subscription,
e.g., to an encyclopedia service. But, it applies more broadly as we
also described in the UST papers. Whatever the application, the token
is typically not returned until the transaction is completed, and what
that means is up to the application. So, if you want to check posts
for abusive content before permitting them, this can be part of the
transaction.  The new token need only be issued after the transaction
is complete.

For Wikipedia posts from Tor this is almost certainly not worth the
effort over my earlier suggestion to just hold any posts from Tor
until they are reviewed. Jimmy suggested that there was plenty of
manpower available for that. And, as I mentioned, incentive to abuse
should essentially disappear once it is known to be pointless. This
approach is not perfect, but there are no pseudonymous profiles as in
others. It has perfect forward anonymity without needing UST because
we aren't worried about limiting available subscriptions (i.e.,
accounts to post from) because we have other means to manage the
incentives we care about.

We are actually in a good position wrt Wikipedia. They are already
blocking Tor. So if they started unblocking Tor with this reviewing
step in place, there is not likely to be much abuse showing
up---because it won't result in any posts.

Why might UST be useful here? Well I already suggested that people
angry enough to try to deface Wikipedia entries might get angry and
try to attack the service when they cannot, redirecting that anger to
the service infrastructure itself rather than the content that is
posted. As Mazieres and Kaashoek noted in their design of the MIT
nymserver, (1) blame the messenger (i.e., identity protecting service)
and attack it does happen when the actual source of frustration cannot
be accessed, and (2) when it does, it is important to make sure it is
more effort to attack a service then defend it.

UST can help with this by requiring that the poster show up with a
valid token. One could imagine that if abuse from Tor drops way off,
the effort to filter submissions through Tor could be not worth it
and turned off as well. When an abuse happens, Tor posts could be
escrowed again. With UST however, the abuser(s) can be more quickly
filtered off (by not reissuing tokens to them). They can of course
get another token chain; this will be as difficult as you want to
make it (IP address based, email address based, captchas, SSNs,
retinal scans, whatever you want), but that will be separate and
will not create pseudonymous profiles of honest users.

Also, it might be useful if Wikimedia (or others) wants to ever use a
limiting device that, unlike Tor, is not delineated by the IP address
from which the post emerges, or if they want to use other IP
addresses.

BUT, I think that this is R&D thinking rather than
solving-the-problem-at-hand thinking.  I reiterate that a basic escrow
of submissions from Tor should be simple and solve immediate problems
well.

The issue has been raised about getting this to the people who
actually develop and maintain the code (and the sites) for Wikipedia.
So far they have been referred to as though those of us on this plane
of existence have no normal means of communicating with them.  I
assume that is not true. I don't know how the code development and
maintainance and network maintainance is all managed, but I bet Jimmy
can at least give us contacts if not have larger input.  (And
apologies to Jimmy if the characterizations of his relation to the
coding and maintainance do not reflect realities. Make that "that the
characterizations of his relation..." because I know from experience
that there are all kinds of things that are assumed from outside, but
munge reality.)

If the code is available, the easiest solution might be to have the
enterprising people who want this to happen code up a simple escrowing
interface and present it to them. (OK and work with them so it
actually happens.) Easy for me to say, as I don't have the time or
skills to do it. Or there might be more sensible approaches.  But the
first step is probably talking to the people who can change this
rather than about them. Any help there Jimmy?

aloha,
Paul