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
Attachment:
pgpuBajKm22d8.pgp
Description: PGP signature