Hello directly from Jimbo at Wikipedia

Nick Mathewson nickm at freehaven.net
Wed Sep 28 03:13:31 UTC 2005


On Tue, Sep 27, 2005 at 07:36:04PM -0400, Jimmy Wales wrote:
> Nick Mathewson wrote:
> > 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?
> 
> This is entirely possible, but of course there are holes in it.
> 
> First, having a login id doesn't mean that we trust you, it just means
> that you've signed up.  One of the reasons that we don't _require_ login
> ids, actually, is that it allows jerks to self-select by being too lazy
> to login before they vandalize. :-)
> 
> But, we could do something like: allow non-logged in posts, and allowed
> posts with Tor *for trusted accounts*, but not non-logged-in posts with
> Tor, and not logged-in-but-not-yet-trusted accounts with Tor.
> 
> Still, there's a flaw: this means you have to come around to Wikipedia
> in an non-Tor manner long enough for us to trust you, which pretty much
> blows the whole point of privacy to start with.

Right.  There are plenty of holes in this approach.  Still, it's
better than the current "no Tor IPs at all for editing" approach, and
a pretty good temporary measure for certain problems.

For example, it would solve the problem of somebody who is running a
Tor server on their home IP, who wants to edit Wikipedia themself, and
doesn't care about their own anonymity on Wikipedia.  This is a source
of a large number of the complaints we receive about Wikipedia.

It would also solve the problem of somebody who's using Tor to get
past an overly restrictive firewall where they spend much but not all
of their time.

> > 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?
> 
> You have to establish trust in some fashion.  I think Tor is in a better
> position to figure out who to trust among their userbase than we are.
> (Since all we get is a bunch of vandalism from a bunch of Tor exit servers.)

Actually, we're not in any better position than you are.  We don't
know who our userbase is either; we certainly don't have identities
for them, and we really don't want to track their identities or
trustworthiness, for a number of reasons:

 - If it were easy for us to tell what individual users were doing
   with Tor, it would be easy for *everybody* tell what individual
   users were doing.  I wish we could separate good users from bad
   without seeing what they were doing, but without linking them to
   the actual contents of their communication, it isn't really
   possible.

 - We don't want people to have to trust us with their secrets.  It
   would make us a great target for malicious hackers and legal
   attacks.

 - Our standard of trust is not likely to be anyone else's.

 - We are not a community service; our operators don't know our users,
   and our users don't know each other, except when they choose to
   communicate on forums like this one.  This is necessary for
   privacy: if the community knows who's who on the network, so does
   the Chinese government.

On the other hand, if there were an authentication service that gave
you pseudonyms for Tor users who wanted pseudonyms, you could tell
which pseudonyms contributed well, and which were jerks, and which
were nonentities.

> > 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.)
> 
> One might choose to put more resources into the trusted cloud than the
> nontrusted cloud, so that for trusted users, there's a net performance
> improvement.

We can't allocate servers to different places; operators need to
decide what kind of servers they want to run.  I worry that many would
decide that running a "trusted users only" server was not what they
wanted to do.

> Does it really need to be able to relay all trusted user's bandwidth?  I
> don't see why.  The authentication merely needs to hand out a 'trusted'
> token.

Yes, I agree.

> And remember, perfection is not needed.  A completely non-hackable model
> of trust is not needed.  All that is needed is to sufficiently raise the
> ratio of "trust" in the trusted cloud so that we can put up with the
> remaining abuse.

I'm in complete agreement that perfection isn't needed.  We just need
to come up with a flawed system less flawed than what we have today.

> > Third, how do users become trusted or untrusted?  Who handles abuse
> > complaints?
> 
> I don't know.  I think this is a great question.
> 
> > 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.
> 
> That seems to me to be no major problem.  A digitally signed token from
> Tor which says, in effect, "No guarantees, but this user is Alice has
> been around for a few months, and hasn't caused any trouble, so we
> figure they are more or less ok" would be fine.  And if that user causes
> us grief, then we just say "Sorry, Alice, even though Tor thinks you're
> ok, we're blocking you anyway."
> 
> Or the signed token could say "Here's a random user, a new account, we
> don't know anything about him, his name is Bob" -- and we can choose to
> block it or accept it, based on empirical evidence.

Exactly!  Of course, this token wouldn't be from Tor per se; it would
be from a separate authentication service.

(I'd want this to be separate because, frankly, these systems have
historically been hard, and if we screw it up, I'd rather not have a
screwed-up system bolted to the insides of the Tor codebase.  Plus,
there are other anonymity projects out there, and there will probably
be more in the future.  If we get this right, there's no reason that
you and they should have to go through this dance again to reinvent
the wheel. Finally, there will probably be demand for more than one
policy, which would suggest more than one auth service.)

> > How does this sound to you?
> 
> It sounds great.  If you digitally sign the tokens and publicize simple
> code for checking the signatures, then lots of services would be able to
> take advantage of it.

Sounds good to me.  What are the next steps on working on designs like
this?  I'd like to maximize the chance that a system like this gets
built in such a way that our users and Wikipedia are all happy with it
when it's done.

In the short term, what are the next steps in allowing
Wikipedia-trusted logged-in users to edit Wikipedia over Tor?

We all have limited time and resources here, but I'd like to devote
some of mine into getting this situation improved.

many thanks for your time,
-- 
Nick Mathewson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 652 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20050927/6d1bb7ae/attachment.pgp>


More information about the tor-talk mailing list