That would still be quite a feat. The bot would have to IP hop over several A-classes. Make some random vandalism that looks like random vandalism (rather than the same set of garbage or random characters/blanking). The IP would have to change enough for it to not look like one bot on RC. The good bot would have to give a time pause before reverting to let other beat it to the punch. Also, if all it did was revert bad bot, then as I said, the bad bot's IP would really have to be all over the place, unless the bot made random accounts too. It would still take a while to build up trust this way...and even with the max, it will still take several edits to get bad content white. This would have to be good enough to set the "most trusted" version. And even if this is done on some pages, it will get reverted and the user blocked, and they have to use another "good bot".
It certainly is always better to be less easily spoofed, and if there are good practical things that can stop this without making the software too underinclusive, I'm all for it. I said earlier that users in the formal bot group should not count as adding credibility. In this vein, we could do the opposite and have groups that increase the max trust (credits) a user can have. That way the default max trust can be lowered to deal further with stuff like good/bad bot networks. This would work if integrated with FlaggedRevs, as the 'editor' group could have a higher max trust limit.
-Aaron Schulz
Date: Sat, 22 Dec 2007 00:42:27 +0100 From: john.erling.blad@jeb.no To: wikiquality-l@lists.wikimedia.org Subject: Re: [Wikiquality-l] Wikipedia colored according to trust
Note that I don't say clique detection should be implemented, I say this is a very interesting option to get running if possible. There are basically two possible solution, or rather I'm not aware of any other that is possible to implement. One is to use identified cooperation between two or more persons to be able to edit an otherwise locked article, the other is to identify cooperation by checking how two or more users interact. If two persons starting to interact in a positive way at any one article it is highly unlikely the goes to war on another article. War between users can be readily detected by simple statistical means (aka automatic classification of statements).
Now the second problem. In trust-accumulating systems you don't have to pile up edits in a single article to game the system. You use two bots. One bad-bot introduces some identifiable error in many articles, and then another good-bot fix those errors. The good-bot will quickly gain high reputation. Even so if the bad-bot changes ip-address often so it goes undetected. This has to be solved somehow, and to say it involves to much work to do something like that is plainly a wrong solution to the problem. I think it is solvable, and I think at least one solution is the fact that all such systems will produce highly unusual usage metrics. It is then mostly a matter of detecting the unusual metrics and sound an alarm bell. If it is possible to incorporate "physical means" that makes it impossible to game the system it is even better. For example, a radio communication system can be jammed, but using frequency hopping radios makes them susceptible to jamming. If they are hopping fast enough they stays ahead of the jammer. If they are hopping faster than the radio waves can reach the jammer then it is physically impossible to use smart jammers.
Don't create a system that can be easilly fooled by more or less smart bots. Make it physically impossible to fool the system with a bot.
- decrease credits when time between edits goes down
- never give more credits to revert an edit then given when making the
original edit 3) weight the edits according to the amount of contribution, yet different styles of contributions should give the same net result in credits 4) decrease credits when cooperation are detected and the reason behind the cooperation can't be detected 5) increase credits when there are a positive cooperation
A slight modification of 2 is to release it if there goes sufficient time.
John E Blad
Aaron Schulz skrev:
How do you tell if users interact? Cross user talk page edits? If you go by edits or edits to talk, what is the difference between people in a clique and people that disagree all the time from the program's standpoint.
For identifying non-vandalized versions, cliques don't seem to pose much of a threat. The only way for that to be a problem is for people to edit stack, similar to the issue of users not using preview and making a ton of edits in a row. This could game the system sometimes, but it is also very obvious behavior when the same 2-3 new (otherwise thy would have probably been blocked by now) people pile on 8 edits after each other. Not only will it stand out, but all it would do is influence the "most trusted"/"likely unvandalized" stable version or the trust for the current revision in their favor...until someone just reverts it anyway. It's too much work for too little plus likely getting caught in the process.
The system will not be bullet proof. Admins have gone rouge before. Even for FlaggedRevs, "editor"/"surveyor" status may be abused by a very small number of people. By default it checks for email, a userpage, 150 edits spread out well, account age. Still, some people could get through and then troll. The thing is though, that it is just not worth, as they would have the rights removed and possibly be blocked immediately. And after what? Sighting some vandalism, which would just get reverted and fixed in a few minutes. To do it again would require another IP and another account back at square one again. That's just not worth it for a troll. We get vandals from people testing and joking around as well as people that just whip new accounts out their ass every minutes because it is so easy. FlaggedRevs makes it not worth it. Likewise, trying to game Article Trust does seem to very "worth it" much either.
Think of how long login didn't have captchas for such a large site. That's because nobody cared to sit there guessing around or writing bots then. If things are too hard to game, people won't care. The "rewards" of gaming this system is even way less than hacking an account. It's a bit better with FlaggedRevs because you commit to having done reviews, so reviewing vandalism goes straight against you. But still, tweaking junk edits 15 times or having the same two editors cluster 8 tiny edits after each other accomplishes little, is noticeable, and IMO, not really worth it. Also, we don't have to use AT or FR exclusively, and some combination of both (quality > sighted
autotrust > current) could avoid the multiple edit gaming issue
altogether.
-Aaron Schulz
Date: Fri, 21 Dec 2007 21:49:30 +0100 From: john.erling.blad@jeb.no To: wikiquality-l@lists.wikimedia.org Subject: Re: [Wikiquality-l] Wikipedia colored according to trust
I think that kind of weighting is correct as long as it is symmetrical (ie. do-undo -pairs weights approx the same). Clique-building is interesting although when you are able to analyze which ones interacts. Then you can punish people when their friends do bad edits. Its not as bad as it sounds, the reasoning is that often someone writes the article under guidance of some other. You don't want to punish only one user in such situations but both. John E
Luca de Alfaro skrev:
I am not sure I am replying to the correct point, but, the system weighs an author feedback as a function of the reputation of the
author.
Reputation is "linear" in the sense that new feedback is simply added to the reputation. A user of reputation r gives weight log(1 + r) to hiers feedback. We use this logarithmic scaling to prevent long-time editors from forming a clique that is essentially impervious to feedback from the rest of the community (will this kind of comments get me skinned? :-)
Luca
On Dec 21, 2007 11:41 AM, John Erling Blad <john.erling.blad@jeb.no mailto:john.erling.blad@jeb.no> wrote:
It is wise to make a note about the fact that such systems make it possible to deduce earlier in the mean that someone is a vandal or not, but it can't replace a good reader that responds to an error. This creates the rather annoying situation where a response from a casual reader should be weighted more than non-beginners, but this makes the system suceptible to users wanting to skew its metrics on specific users.
John E
Aaron Schulz skrev:
Right. Also, we need to be clear what we want this to do. It will never be great at determining fact-checked material. What it is good at is spotting the more dubious stuff, like possible vandalism.
This
makes the possibility of having "most trusted" stable version as discussed earlier. Small changes not only can be big in meaning, but they still attest to the trust.
If I read a sentence to change some minor thing, I still read
it. If a
wrongly says "he identifies himself as bisexual" or "born in 1885" rather than 1985 in a page when I edit, I am going to revert if I catch it. Even if just making some grammar/syntax cleanup. So each time people look at stuff if still attest to the page a little bit, from a vandalism perspective.
The algorithms can be made more strict to catch more general dubious info better, but it is not that bad at that already, and the
stricter
it gets, the more it gets under inclusive as to what is considered unlikely to be vandalized.
-Aaron Schulz
Date: Fri, 21 Dec 2007 10:34:47 -0800 From: luca@dealfaro.org mailto:luca@dealfaro.org To: wikiquality-l@lists.wikimedia.org
mailto:wikiquality-l@lists.wikimedia.org
Subject: Re: [Wikiquality-l] Wikipedia colored according to
trust
If you want to pick out the malicious changes, you need to flag also small changes.
"Sen. Hillary Clinton did *not* vote in favor of war in Iraq"
"John Doe, born in *1947*"
The ** indicates changes.
I can very well make a system that is insensitive to small changes, but then the system would also be insensitive to many kinds of malicious tampering, and one of my goals was to make it hard for anyone to change without leaving at laest a minimal
trace.
So it's a matter of goals, really.
Luca
On Dec 21, 2007 10:01 AM, Jonathan Leybovich
<jleybov@gmail.com mailto:jleybov@gmail.com
<mailto: jleybov@gmail.com mailto:jleybov@gmail.com>> wrote:
One thing that stood out for me in the small sample of
articles I
examined was the flagging of innocuous changes by casual
users to
correct spelling, grammar, etc. Thus a "nice-to-have"
would be a
"smoothing" algorithm that ignores inconsequential changes such as spelling corrections, etc. or the reordering of semantically-contained units of text (for example, reordering the line items in a list w/o changing the content of any particular line item, etc.,
or the
reordering of paragraphs and perhaps even sentences.) I
think
this would cover 90% or more of changes that are immaterial
to an
article's credibility.
Wikiquality-l mailing list Wikiquality-l@lists.wikimedia.org
mailto:Wikiquality-l@lists.wikimedia.org
<mailto:Wikiquality-l@lists.wikimedia.org
mailto:Wikiquality-l@lists.wikimedia.org>
Get the power of Windows + Web with the new Windows Live. Get it
now!
http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_122007
Wikiquality-l mailing list Wikiquality-l@lists.wikimedia.org
mailto:Wikiquality-l@lists.wikimedia.org
Wikiquality-l mailing list Wikiquality-l@lists.wikimedia.org mailto:Wikiquality-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikiquality-l http://lists.wikimedia.org/mailman/listinfo/wikiquality-l
Wikiquality-l mailing list Wikiquality-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikiquality-l
i’m is proud to present Cause Effect, a series about real people making a difference. Learn more
http://im.live.com/Messenger/IM/MTV/?source=text_Cause_Effect
Wikiquality-l mailing list Wikiquality-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikiquality-l
_________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_122007