Wikipedia talk:Edit filter/Archive 1

Archive 1

Archive 2

Archive 3

→

Archive 5

Header

Wow. Amazing. I think this would be great. Only caveat is that any desysopping would have to be immediately confirmed by ArbCom unless completely obvious. Stifle (talk) 09:48, 23 June 2008 (UTC)

Openness

We do not I think have precedent for hiding reports from our users. Everything contributed to Wikipedia is public, and all edits are logged, and anyone, even not a registered user, can see the logs or even subscribe to a feed of them. Some material is protected from public view--but that is material manually deleted by administrators or oversighted by the office after human consideration and human checks. That's as it should be. We do have precedent for concealing the exact algorithm used by existing bots, and that has been considered necessary to prevent abuse, per WP:BEANS. Personally, i'm less than happy with any non-open programs running on a Wikipedia server. If we so arrange things so people will have to make good contributions to defeat out screening, so much the better. And, even so, we will in any case be no worse than the present, with no screening at all. Some of the benefits of accessible screening criteria can be accomplished by making them somewhat random; anyway, any reasonably sophisticated vandal can find out the screening parameters by experimentation. Experience shows that difficult to detect vandalism comes because things are in places not being watched--that can be dealt with nicely by programs like this. It doesnt come about because of the effort in hiding it. Once we have general principles established, then will be the time to discuss the details of the criteria used. The guiding principle should be to go slowly and gently, because whatever we pick up will be an improvement. DGG (talk) 18:44, 23 June 2008 (UTC)

It's not about open programs. The source of the extension will, of course, be released under the GNU Public License. The filters themselves, however, will not be released.

There is certainly a precedent for non-public logs — checkusers and oversight. — Werdna talk 07:32, 24 June 2008 (UTC)

I understand the logic, but I can't support something like that without being able to see it. -- Ned Scott 07:34, 24 June 2008 (UTC)

I agree with the above. Checkusers and oversight are completely different things from this; those have to be protected because if they were completely open-access, then there would be a risk of serious, real-world harm to editors and subjects of articles. You're talking about hiding how an edit gets its first "vandalism or not" check; that isn't something that we can hide. If this really can't work without allowing the community to see how, then I don't think we need this here. Celarnor ^{Talk to me} 07:42, 24 June 2008 (UTC)

This is not about identifying all vandalism. It's not like ClueBot, where there will be a zillion reversions a day, and probably 10-15 false positives a day. This will trigger on very, very blatant vandalism — grawp-type pagemove vandalism, and so on. It is unlikely to have any significant number of false positives. You're stating that you disagree with its operation — and I believe you do. What I'd like is something concrete to work with — in order to find a compromise, I need to know where you're coming from. — Werdna talk 09:57, 24 June 2008 (UTC)

Trends and patterns

Working under the assumption that a small group of users are the only people able to add settings to or remove settings from this extension, how would trends and patterns be reported to this group without allowing vandals to see that we notice these patterns? And, how would the community (and especially admins) know that specific problems are being worked on?

Let's say for example that a vandal is using a tactic to make 25 legitimate edits to the article namespace before he or she vandalizes by abusing the page move function. Admins are generally the ones to see this trend first. But if they report seeing this trend in a public forum, the vandal will know that they have been spotted. So, do we establish some sort of mailing list and add another layer of secrecy? And, if this group, these abuse filterers, act quickly and block this particular type of vandalism, how will administrators be aware of this fact? Simply the absence of vandalism? --MZMcBride (talk) 20:01, 23 June 2008 (UTC)

An abuse log is included in the package, and will show all edits that would have been blocked by the filter, and why. I expect that, as much as it pains me to suggest it, a closed mailing list or similar would need to be established. — Werdna talk 07:33, 24 June 2008 (UTC)

Maintaining secrecy when modifying the algorithm?

I am not yet sure what I think of this proposal, but I perceive a contradiction. For the sake of secrecy, the precise details of the filter's operation must remain private. However, if someone wishes to propose a modification to the filter, that discussion will occur publicly on-wiki and will be archived where the vandals can find it if they know where to look. So at the end of the day, aside from the initial contents of the filter, all modifications will be common knowledge. Am I missing something, or is this how the filter is intended to work? Yechiel (Shalom) 22:05, 23 June 2008 (UTC)

The section above titled "Trends and patterns" is closely related to this one. I imagine some sort of closed mailing list (similar to what checkusers and oversighters currently use) would have to be implemented... --MZMcBride (talk) 22:15, 23 June 2008 (UTC)

Blocks, how?

If this system blocks a user, will it be via the standard blocking interface, or something not arbitrarily reversible? — xaosflux ^Talk 02:16, 24 June 2008 (UTC)

It will be a regular block. — Werdna talk 07:26, 24 June 2008 (UTC)

Secrecy is probably less necessary than we think.

Subject heading says it all. As fearful as we are of vandal circumvention, that isn't a really good reason for this tool to be hidden from the editing public. Presumably the source for the tool itself will be publicly available as a GFDL product, so why not include logging? We are just as likely (more so, in my opinion) to have a determined editor data-mining the logfiles in order to improve the filter as we are to have a vandal do the same thing in order to circumvent the filter.

The formulas for all of the editing bots are public. Presumably if vandals wanted to circumvent those tools they are given the opportunity. Circumvention occurs, but it is an acceptable price to pay for using tools that have the trust of the wikipedia user base. Likewise the formulation of those bots was predicated on the expectation that they would be public. The formulas made public (and easy to find) provide an easy method to avoid detection, but most vandalism is caught by those bots. Some which slips through is truly malicious--vandals who are willing to wait and make minor changes to poorly patrolled articles in order to weaken the project. But most of it is still adding things like "Penis!" or "so and so is gay" to Thomas Jefferson and so forth. In order for that kind of vandal to avoid (say) the cluebot filter, she would have to establish an account, use proper punctuation, not eliminate a significant amount of text, not swear and avoid caps. In order to learn that she would need to find cluebot's doc page and interpret the filter (or read ED's guide on how to vandalize wikipedia). That's a lot of effort and it is likely that in the time it takes her to avoid the filter she woudl find things about the project she likes.

I originally came to WP from ED with the intent to start an account, incubate for a while then begin small efforts at vandalism. I came here, started an account and discovered WP wasn't filled with jerks. For a good percentage of seemingly determined vandals, that might be a common fate.

More to the point, it is more in line with the OSS goals in general and the project goals in particular to have this filter be made public (were it implemented). I have 0 faith in the author's promise that the software would generate no false positives and I'm inclined to think that openness would eliminate community suspicion that false positives exist (even where none may exist). I also find the author's rejection of fears of a cabal to be unfounded. The author stipulates a perfectly reasonable fear and then dismisses it without evidence.

Unless some concrete example is presented of demonstrable circumvention overriding the community's need for transparency, I can't see why we would need to leave this tool in the dark. Protonk (talk) 05:31, 24 June 2008 (UTC)

I don't like the idea of having the methodology involved not open to the analysis of autoconfirmed users. Really, I don't like the idea of it not being able to looked at by any prospective editor, but I suppose that's not quite as necessary. If your algorithm is weak enough that you need security through obscurity to protect it, then you should probably revisit the mechanisms and come back when you have something that's good enough that it won't matter whether a vandal can see the source or not. Celarnor ^{Talk to me} 06:34, 24 June 2008 (UTC)

This is not a matter of 'security', and so speaking about 'security through obscurity' is flawed — the system does not provide 'security', it merely applies heuristics. We may be targetting a user's edit-count, edit summaries, or any other aspect of their behaviour. To tell them exactly why they were blocked is to invite them to change that aspect of their behaviour, while maintaining the harmful aspects of it, so we have good reason to keep them from seeing the filters.

That said, if the community insists that administrators be given viewing rights for the filters, I'm happy to go along with it, although I maintain that leaks from administrators would be quite routine if this occurred (as occurs with #wikipedia-en-admins logs). — Werdna talk 07:30, 24 June 2008 (UTC)

I don't think giving just the administrative team read access is going far enough, not by a long shot. If not autoconfirmed users, it should at the very least be given to rollbackers, who already deal with vandalism. Celarnor ^{Talk to me} 07:54, 24 June 2008 (UTC)

If we're giving read access to autoconfirmed users, or to rollbackers, we may as well give it to everybody. Whether it's worth restricting read access to filters is another question, which I've made my thoughts known on above. However, what we're fighting is people who can get autoconfirmed, and use it to vandalise. I would not think that a few hundred edits and a bit of vandalism-reverting would be much of a price to pay for a determined vandal to find out the algorithms we use to detect them. It would only take one leak to get the whole lot out there. — Werdna talk 09:43, 24 June 2008 (UTC)

I'd rather they be publicly readable, yeah. Not writable, obviously, but I do think it should be as transparent as possible. The only direction this has is to improve; the speed at which it improves depends on a few things; one is the complexity of attacks, another is the number of them, and another is the speed with which a method can be developed to prevent those attacks. There's a reason that companies sponsor DEF CON. Inviting more and more complex forms of 'obvious' vandalism by giving them the tool that's meant to stop it is going to bring the shortcomings of that tool into the light, making it easier to solve. It's also a lot easier for a few thousand people to notice holes in an analysis method than it is for the closed circle that you suggest. Any kind of loss experienced as a result of "Oh hey, look at this filter, we can change the e in penis to a 3 and it won't recognize it" is, in my opinion, grossly outweighed by the speed and quality benefits of openness and transparency; a solution to a problem is much easier to come by the more people you have looking at it. Celarnor ^{Talk to me} 10:27, 24 June 2008 (UTC)

The impetus is on you to provide a method of heuristic analysis that can survive knowledge of the analytical method itself. If you can't do that, then it probably isn't really worth having anyway; but that aside, I don't want MediaWiki-gestapoExt-1.0-en here without being able to see what it expects of me in an edit. Celarnor ^{Talk to me} 07:54, 24 June 2008 (UTC)

I disagree. We're not talking about providing security — while it is, as you describe it, a heuristic method, the checks done behind the scenes are not 'fuzzy' in the sense that it uses neural network programming or other machine-learning. The rules are determined by humans, and they are quite deterministic. For instance, we'd be thinking of blocking users younger than one week, who, having less than ten edits, are the second or subsequent person to move a userpage to a title with more than fifty characters from the same IP address, created on the same day, in one hour. This sort of rule is exceptionally stringent, and, in the very, very unusual case that it misfired, the extension gives the user adequate information to clear their name. Here, the community does not need to know what to avoid — it is, to say the least, exceptionally unlikely that any legitimate user would trigger the filter. However, if a vandal knew about this filter, and its exact specifications, they could ensure that the attacking titles that they move userpages to were under 50 characters, or wait 61 minutes between moves, or do it some other way to circumvent the filter. In this particular situation, it is quite clear that the community's interest in suppressing the exact details of the filter is greater than its interest in open-ness and transparency.

With that said, I am not averse to some limited form of public knowledge — for example, allowing certain filters for which this is a risk to be 'hidden' from public view, and allowing summaries, but not precise details, of certain filters to be available through the interface. — Werdna talk 10:03, 24 June 2008 (UTC)

I'm not sure why this isn't getting across correctly, but, look at the titleblacklist for instance. A determined user will (and often do) easily look at it, and, waltz right around it. Same with the username blacklist (unless, either of those, become uselessly loose to the point of extreme false positive levels). The only way to effectively prevent this sort of abuse, is, a non-public set of heuristics. Otherwise, the same sort of determined user, will just keep reading it, and, walking right around it. That, or, raise restrictions to utterly draconian levels. I think, if the block log reflected what rule (say we give each rule an 'identifier string' like 'newmover7' or something), and, we can still view the user's contribs, they can still request, and have reviewed, an unblock in the normal manner, in the case of a false-positive. SQL^{Query me!} 10:34, 24 June 2008 (UTC)

Oh. I was under the impression that it was a more in-depth logical heuristic than that; yeah, in that case, then no; making everything open would force the margins (60 minutes plus or minus ten if all the other criteria are met, etc) unacceptably wide and would produce too many false positives. Celarnor ^{Talk to me} 10:29, 24 June 2008 (UTC)

Although, I do think that the community needs vague-ish summaries of what types of things the extension looks for; maybe "Rapidly moving userspace pages to large names" for the previous example. Celarnor ^{Talk to me} 10:33, 24 June 2008 (UTC)

• Given the claims above, I don't see a rationale for outright secrecy. We need to weight the interests of the community against the loss in efficacy for the filter. We also need to be serious about the success of that secrecy and the goals of the filter. To wit:

• If we are using the filter to block vandals that can get administrator access, then what stops a vandal from gaining admin access then posting the contents of the filter on a separate server? true, we may change the filter subsequently, but then we run into the problem of a new version being posted.
• What is the intent of the filter? We can't possible expect it to block all malicious edits. That's absurd. Do we expect it to block the sort of edits now automatically detected by bots? in other words, do we expect to lower the workload for vandal patrollers and return WP to a state where most vandal patrolling is done via Recent changes? Or do we expect the filter to block more sophisticated attempts at vandalism?

• We have an interest in transparency. We also have an interest in building a functioning filter. Those two need to be balanced realistically. We also have to realize that even IF the filter isn't leaked, the heuristics will be reverse-engineered by a determined opponent. Then we have a filter whose mechanism is exposed but only a small community of users to patrol and bug-check it. Protonk (talk) 16:49, 24 June 2008 (UTC)

I would be adamantly opposed to hiding the heuristics from anyone. If it's not viewable by anons, then I'm against it, and will give it no further consideration. Will this make the system relatively ineffective against clever and dedicated vandals? Of course. But pretty much any system is ineffective against clever and dedicated vandals. Correct me if I'm wrong, since I don't follow enwiki much, but I'm pretty sure there's been at least one case of someone actually working an account up to sysop for nefarious purposes. Even if not, it's not rocket science to guess at what heuristics are being put in place based on which of your actions are blocked. It just gives various trolling groups the brief extra entertainment of reverse-engineering the configuration by probing the behavior.

Basically, there needs to be community overview of any measure put in place. The community does not mean some tiny cabal. It does not mean all sysops. It does not mean all autoconfirmed. It means everyone, registered or anonymous, who views or edits or otherwise is involved in the project, and who's interested in participating in policy. Without public scrutiny, we run the risk of overly broad rules being kept in place without anyone being able to object except for a tiny group. That group could easily, pardon me for my cynicism, be paranoid about vandals and lose sight of the fact that open editing is what makes Wikipedia what it is.

If some extra vandalism gets through, big deal. It can be reverted. Any gain from secrecy is negligible, dramatically outweighed by the losses.

Now, suppose that the configuration is public. I'm still not sure I see the point. Anti-vandal bots are well suited for this work. They're more flexible than anything you can write in an extension. Their code can be changed more easily, because it can be tweaked live by someone a) dedicated to the specific project and b) without root database access. Their configuration can also probably be changed more easily. There's a good chance that any change to this configuration will require endless community discussion and bickering and polls and consensus and who knows what. Look at how enwiki deals with questions like changing autoconfirmed criteria, which is more or less a much narrower version of the same thing. A bot operator, on the other hand, can make a change immediately if it appears to be a good idea. If the community then objects, of course, they can be forced to change it back or have their bot blocked.

So overall, I oppose this proposal unconditionally if any steps are taken to hide the configuration, and seriously question whether it's a good or useful idea in any event. —Simetrical (talk • contribs) 18:50, 24 June 2008 (UTC)

• So you're saying if it performs the same job as an anti-vandal bot with a low or no false positive rate and ALL of the heuristics are public you wouldn't support the project? Let's presume it just blocks edits that include "PENNIISSSSSSSS!!!!!!!" by IP's on articles. The only impact there is removing the workload from editors who are currently patrolling with bots. Protonk (talk) 19:33, 24 June 2008 (UTC)

  I might be fine with that, yes. Assuming all configuration and logs were public, I would not necessarily oppose. I might or might not, depending on details, but probably not very strongly in any event. —Simetrical (talk • contribs) 22:00, 25 June 2008 (UTC)

Simetrical, I don't think you quite understand what this extension is all about. It's not about targetting bog-standard vandalism. It's not about targetting any significant proportion of vandalism, but about targetting very specific behaviours, like certain page-move vandals, and so on. You can read more about this by reading my comment prior to yours, and on the accompanying page to this talk page. It's about finding a real solution to vandalism, doing more intelligent things than increase the requirements for moving pages, and reactive checkusers. And so, by targetting specific behaviours, like moving userspace pages as your tenth edit, to some long title like User:Werdna is a big meanie, and an asshole, and he made my mummy cry, we can eliminate the 'shotgun' method of simply requiring twenty edits and seven days rather than four edits and ten days to move pages. It gives us the opportunity to lighten the hard restrictions we put on all users, instead placing tougher restrictions on those who are actually causing the problem. In comparison to this goal, certainly a worthy one, I cannot see the merit in your argument, which, to me, seems largely ideological, with very little basis in the practicalities and mechanics of dealing with these sorts of problems. — Werdna talk 10:40, 25 June 2008 (UTC)

You say that it's to be used for targeting very specific behaviors, but you aren't going to be able to enforce that once it's enabled. It's going to be used for whatever people want to use it for, and depending on who controls the buttons, it may or may not be restricted to your original idea. You should know perfectly well how commonly software features are used for totally different things from their intended purpose. And if the configuration isn't public, we won't even know what it's being used for.

As for how well it addresses your goal ― even leaving aside, for a moment, how it will inevitably be used to further other goals ― you've failed to make it clear to me how it's any more useful than an admin-bot. Your rationale for the proposal does not even include the word "bot" except when listing user groups. Anyone, including you, could run a bot to do exactly the same, with the only difference being that all actions would be logged in the normal fashion, instead of in some secret log viewable only to sysops or whatever. You'd also have to get it admin status, but that should be no harder than getting this proposal approved, if there's any reason in people's decision-making here. (And if there's not, software workarounds for that aren't the way to deal with it.)

Of course, you feel that the secrecy is necessary for it to work properly. I think that's absurd. The vandals you're talking about are dedicated and malicious, and are not going to be caught out any faster if you try to hide things from them. Any heuristic can be evaded, and security through obscurity is only going to make that marginally more difficult. Any vandal in the group you're talking about has access to a large number of IP addresses, say from a dynamic provider, and would not find it very difficult to do some experimenting with his buddies to probe the ruleset. Rules like "ban people who move user pages to things containing the word 'penis'" are trivial to avoid with a little common sense. You've provided no good reason to believe this part of the proposal is necessary, and given the costs there's no way I'm going to accept it.

I should point out, also, that a bot's heuristics could be kept secret. (I might object to this as well, depending on the exact circumstances, but that's beside the point.) Of course, the bot's decisions to block and revert and so forth would be publicly logged, not privately, but I assume your extension does not attempt to block users without logging it in the usual fashion. The log of such blocks isn't any less useful than the contribs of an anti-vandal bot for determining what heuristics are being used. So an extension is not even necessary for such secrecy, if such a thing were desirable.

Your implication that this proposal is an alternative to stricter autoconfirmation is a false dichotomy. FlaggedRevs, for one, will greatly reduce the need for things like outright semi-protection, in a much more contributor-friendly fashion. Moreover, as I emphasize above, a bot could serve the same purpose, and if you want this enabled you should make it clear what its advantages are over an admin bot.

And finally, for the basis of my argument: it is most definitely, as you say, based on the ideologies of wikis, open access, and transparency ― and not merely on some temporary convenience that may or may not accrue to vandal-fighters. That I freely acknowledge. No drastic measures are needed to fight vandals; they are not destroying Wikipedia. And if they are, then the frightening ones, the ones we need to be most concerned about, are the casual ones, who falsely change a figure here or delete a footnote there, and slip under the radar. Those are the ones who chip away at Wikipedia's credibility and utility, and those are the ones our efforts should be most focused on.

So not only are you discarding the ideology of openness that made Wikipedia what it is, you're doing so only to fight the most harmless sort of vandal, the ostentatious one who's spotted immediately and causes a thousand times as much drama as actual damage. The way to fight such vandals is to get people to calm down about them, revert them quickly and efficiently, and get on with life. No special heuristics are needed to detect them when their entire goal is to blare out their presence to the entire community of vandal-fighters. And since their entire goal is to cause drama, all that's needed is a mechanism to block and manually revert them as quickly and efficiently as possible, such that their activities are so non-disruptive that nobody cares about them. No amount of software heuristics are going to outsmart a dedicated human for very long without an unacceptable rate of false positives. Your entire direction is doomed from its inception, a battle of wits between computer programs and human brains. If there is no merit in your proposal as a whole, that holds doubly for the purpose you intend it to be used for. —Simetrical (talk • contribs) 22:00, 25 June 2008 (UTC)

So as I understand it, this process is going to completely automate the role of the administrator. I say go for it! But the process should be open and transparent:

1. If some sanction is imposed on you, then you should be able to see that it was imposed by an automated process, and likewise, if your edits are reverted, you should be able to see that it was an automated process that reverted them, and in any case, appeal to any administrator; and
2. all administrators should have read-access to the rules. Why do you suppose that it is so hard to become an administrator? It's because it is a position of trust. Anybody who has earned that trust should be able to see what the rules say. I take a moderate position on security through obscurity, but I am not a big fan of it.

The first point above I am sure is already part of the plan; the second is my point of view only. Please feel free to comment. Bwrs (talk) 20:11, 26 June 2008 (UTC)

Your first suggestion is most certainly a part of the plan. I'm going to put sample interface messages on the accompanying page for this talk page. Note that I am open to open viewing of the abuse log without details, as well. — Werdna talk 00:45, 27 June 2008 (UTC)

Verbiage should probably use the word "unconstructive" (even at risk of duplication), rather than harmful. I also suggest that no user be blocked unless they trip some rate-limiting filter (the exact rate limit being known to administrators only, and adjustable by administrators). (Page blanking, for example, is sometimes done with a legitimate reason, but multiple page blankings in a very short time are questionable.) Thanks. Bwrs (talk) 04:13, 27 June 2008 (UTC)

That is, of course, why I added the throttling feature. — Werdna talk 09:52, 27 June 2008 (UTC)

I just hope that the admins. make use of this feature, or that it be enabled by default. Bwrs (talk) 18:26, 27 June 2008 (UTC)

We have two things to discuss

We have two things to discuss here, one is the technical ability, and the other is how we implement it (who has rights, what kinds of behavior gets tracked, etc). Right now this is being rolled into one discussion, which probably isn't very efficient. (For a lack of better words. I just got home from work so forgive me if I'm rambling) -- Ned Scott 06:03, 24 June 2008 (UTC)

New information

I've added new details, including the types of notifications users receive if their edit triggers a filter, and screenshots of the abuse log. — Werdna talk 01:28, 27 June 2008 (UTC)

Extension complete; Test wiki available

I've completed the extension, and it is activated at my test wiki, with all features except viewing private data and modifying filters available to all users (i.e. viewing the filters and logs can be done by anybody).

Any interested user in good standing is invited to request extra permissions on that wiki for the purposes of testing the new extension. — Werdna talk 08:03, 27 June 2008 (UTC)

Status of proposal: Secrecy

Given the concerns of editors who, rightly, have concerns about the need for secrecy with this extension, I've decided to relax my proposed secrecy provisions, after considering the cost/benefit.

Therefore, with recent modifications to the software, I propose to require all filters to have an accurate short description of them, which will be publically visible, and included in block summaries, in the abuse log (which will be open for viewing to all users), and the relevant logs.

In addition, I've added a feature which allows specific filters to be hidden from public view. I intend to allow administrators to view all filters, except those which have been hidden (which would be visible only to those with permission to edit them). I am open to implementing a feature which allows unhidden filters to be disabled by administrators (but not edited in any other way), if this would make the feature more palatable to the community.

I hope that this will allay some of the concerns which have been put forward. — Werdna talk 13:17, 29 June 2008 (UTC)

This is something that needs to be discussed in more detail, but I can't see any reason why the right to edit the filters should not be a sysop permission. Admins already have access to a number of blacklists; there is nothing that the extension does (to my knowledge) that a bot-literate admin cannot already do, with the sole exception of invoking rights changes. I think that this extension has enormous potential, but it needs to be able to be adapted quickly to evolution in attack algorithms: tightly restricting access to it is not the best way to get full use of it, IMO. More (and separate) discussion needed. Happy‑melon 16:19, 29 June 2008 (UTC)

I was going to comment that many admins are not even close to bot-literate, but given that we already allow admins to edit blacklists (which could potentially prevent all new user accounts and stop all editing) and edit the site JS, I really don't think people breaking something by accident will be a big problem. I tend to agree that the more people have access to it the better, look for example at WP:RFCU, where we have a relatively small group of people doing things that can be fairly time-critical, requests can take hours or days before someone gets to them. Allowing all admins to edit them will also reduce the liklihood of caballery and abuse potential and will will make implementation far more likely. Many people are dissatisfied with ArbCom and RFA-like processes, so giving out the right to edit the blacklist using those systems may not go over well. Mr.Z-man 18:03, 29 June 2008 (UTC)

All excellent points. If this ends up like oversight or checkuser, it's going to be almost useless (and the strongest wiki-cabal we've ever seen). Happy‑melon 10:54, 30 June 2008 (UTC)

My concern is that it is not beyond some of our more dedicated trolls to "work accounts up" to admins, and then use them for their own purposes. Compare with, for instance, Runcorn, who developed an admin account, and used it to change blocks on tor. Compare with, for instance, the constant leaks to Wikitruth of deleted articles, and so on. — Werdna talk 00:50, 30 June 2008 (UTC)

Leaks, secrecy, obscurity... I think this closed-book philosophy, while not without merits, has been pretty much agreed above to be counter to the wiki philosophy and hence unusable on en.wiki. We all know that with a compromised admin account you can make a real mess, so that's nothing new: everything here is logged, everything can be reversed, every disruption is, therefore, temporary. Happy‑melon 10:54, 30 June 2008 (UTC)

request

hi!
this seems to be a long expected and very helful extension. i didn't read all discussions (too much), so excuse me, if i ask something, which was answered already.
is it possible to block an edit similar to the spam-block-fliter? "abusefilter-blockreason" appears to be something like that.
e.g. in the german wikipedia we have a user, which performs a lot (!) of unuseful edits like changing "das gleiche" ("the equal one") to "dasselbe" ("the same one"). however, would it be possible to prevent this user, who often uses open proxies, from making such nonsens?
áis it possible, to restrict the blocking to specific ip-ranges? -- seth (talk) 13:43, 6 July 2008 (UTC)

This is not the intended purpose of the extension, and the extension's code includes mechanisms which actively prevent the use of the extension to apply restrictions to particular users or pages. In particular, it is not possible to target specific IP ranges (as this presents a hazard of releasing private data). — Werdna • talk 10:15, 7 July 2008 (UTC)

Moving forward

The discussion on this topic has definitely stalled, so the question now is: how do we proceed? Personally I think that the autoconfirmed poll has demonstrated that "A/B/C/Di/Dii/Diia4I" type polls have very poor success rates. We need to agree on a set of configuration settings, rewrite the project page to say exactly how the interface will then appear (move what's currently there to MediaWiki - it's too good to waste), and have a nice clean poll that the devs can look at before installing and configuring the extension here. Which means, of course, we actually need some closure of the permissions debates above. Comments? Happy‑melon 18:49, 7 July 2008 (UTC)

Well, I am developing another extension called WikiPoll which allows the determination of the best outcome from a choice, based on the same voting method used to resolve the Board Vote. Unfortunately, that might not be live for several squillion years. — Werdna • talk 03:10, 8 July 2008 (UTC)

For the record, by the way, I'm happy to proceed with a lower level of privacy than I originally intended, and, if it becomes a problem, we'll see about having another poll on that. I have to write a bit more of a paper trail now (gasp, revisions of it). — Werdna • talk 06:43, 8 July 2008 (UTC)

I know that my opinion isn't really the say so upon which this project rests ( :) ), but I do think this is a very good idea, divorced from the obscurity idea. Even if implemented as an elaborate "editprotected" type system (where dedicated vandals can avoid it with effort but 99% of IP vandals are stymied), we can see a huge ROI. I think that we get into serious diminishing returns as we attempt to eliminate the more persistent vandalism. Let's consider the huggle/twinkle userhours we save that can be diverted to other uses in just stemming IP vandalism. Protonk (talk) 04:17, 9 July 2008 (UTC)

I'm not sure how we'll go with blocking the 99% of IP vandalism, in the false positive department. — Werdna • talk 04:27, 9 July 2008 (UTC)

Promising, but a long way to go

On the one hand, this addresses a serious problem that has no existing solutions, and the overall approach seems sound. It needs a lot of work before I'd feel comfortable with it, though. The safeguards need to be fleshed out way more than they currently are (as it is, it boils down to "trust me"). The reliance on secrecy seems like a vulnerability, especially when you consider the need to defend its actions, and fundamentally against the wikipedia approach: like open source software, Wikipedia relies on having "amny eyes on the code". Finally, the de-sysopping power seems like a solution in search of a problem. Any admin who tries to pull a Willy On Wheels is going to get demoted by flesh and blood anyway, so it's just another potential error due to false positives (and there will be false positives; it's based on a heuristic) for very little gain. — Gwalla | Talk 02:04, 9 July 2008 (UTC)

Defense must match attacks

I encourage the development and implementation of automated defensive software to counter automated attacks on the integrity of the information in Wikipedia. One fast-typing goon or one automated attack can create so much mischief that it takes a dozen admins a long time to correct it. If there is a willingness on the part of Werdna to tweak the filters to reduce any false positives, I do not see a downside. Why would any new user find it necessary to do a great many page moves in a short time? Edison (talk) 04:56, 9 July 2008 (UTC)

I don't believe so

I know that you're waiting for conversation before the voting starts, but I'll put in my piece now--I don't like the idea of a black box with the power to desysop me watching my actions based on an algorithm that I don't have access to. This seems to me to be the antithesis of WP:AGF. --jonny-mt 10:51, 23 June 2008 (UTC)

Allowing the extension to desysop editors seems like a bad idea to me, too. -- The Anome (talk) 12:35, 23 June 2008 (UTC)

From what I have understood that would be for very limited events (unprotecting the main page comes to mind), as long as there are no false positives, I personally have no issues with this. -- lucasbfr ^talk 15:31, 23 June 2008 (UTC)

The kind of abuse this is set up to counter probably would indicate someone with some on-wiki experience was perpetrating the abuse. Thinking if I was a vandal, I'd see some issues with the consequences:

• The user's action may be disallowed.

So I make a new account

• The user's account may have its autoconfirmed status suspended for a random period between 3 and 7 days.

So again, make a new account, or just flip to ip editing

• The user's account may be blocked from editing, along with all IP addresses used in the last 7 days.

If it's my account, again just sock or ip edit. Blocking all IP addresses means that you have an automated program that *may* block a massive range of IP addresses including those from a number of legit users. University ip ranges spring to mind. This is fairly controversial when the decision is made by a human; an automated system seems much more so.

• The user's account may be removed from all privileged groups (such as sysop, bot, rollbacker).

Seeing as the only privilege I have is rollbacker (which is replaceable with Twinkle), I don't have personal insight in to this one, but I would imagine that if I was a confirmed admin, I may occasionally edit in a way that might throw up some triggers.

But while I'd be against a program with automatic responses, an abuse-record aggregator might be a good idea (though there may be something I'm not aware of that admins already have that does this). I bet it would help admins that see one case of vandalism know if it's being done by someone who may be going beyond the typical vandal. You'd have to restrict ip checks to folks with checkuser rights though - you might even want to remove the ip portion completely. CredoFromStart ^talk 14:14, 23 June 2008 (UTC)

From what I have gathered from what Werdna said when he started working on it, Point 1 is fair, point 2 would need a second autoconfirmed account which is annoying enough imho. When admins block an account, we usually autoblock the underlying IP for 24 hours already, this would simply extend this block to the other IPs the user used before. I trust that point 4 will be set up in a manner that it will only be triggered for actions that leave no doubt on the intent to harm the project. -- lucasbfr ^talk 15:35, 23 June 2008 (UTC)

Auto desysop - solution without a problem?

Auto desysopping - is this a solution to a problem that doesn't exist? What's the longest (in minutes? seconds?) it's taken for a bad faith sysop to be stopped? How many times has it happened? (These aren't rhetorical questions - I don't know the answers. Depending what they are, I might think this is actually a real problem) --Dweller (talk) 15:40, 23 June 2008 (UTC)

I think User:Robdurbar was desysopped by the first available steward 17 minutes after he started going rogue. The password hacker in May 2007 was dealt with more quickly because people already knew from the Robdurbar experience to flag a steward on the stewards' IRC channel. I think the 17-minute response time is acceptable, and I don't think it's ever going to take longer than that unless all the stewards go on vacation at the same time (something that actually happened when Wonderfool, a previous account of Robdurbar, went rogue on Wiktionary). A bot can't desysop someone much faster than humans can, and should not be asked to do such a sensitive job. Yechiel (Shalom) 21:52, 23 June 2008 (UTC)

Small points of clarification: it's a not a bot, it's a proposed extension to the software. And, an instant de-sysop triggered upon deleting or unprotecting the Main Page is obviously far faster than any steward ever could be. : - ) Though I believe the last time there was an incident, it took less than two minutes to block and de-sysop the account. --MZMcBride (talk) 22:19, 23 June 2008 (UTC)

Agree with the GP, this seems like an unnecessary component at this time. — xaosflux ^Talk 02:16, 24 June 2008 (UTC)

Well, yes, I'm not suggesting that rogue admins are a huge problem that needs this extension to be fixed. But, if it comes for free when we solve a problem that DOES exist, and IS causing serious damage (Grawp), then we're all the better for it. — Werdna talk 07:42, 24 June 2008 (UTC)

The answers here make me pretty convinced that I'd not be in favour of this element being added. --Dweller (talk) 10:28, 24 June 2008 (UTC)

Anti-vandalism tools usually automatically whitelist admins. This isn't just because admins aren't likely to vandalise, but also because it means there are people that can make apparent vandal edits when required. That's why admins are excluded from the rule that stops people creating accounts with similar usernames to other accounts, for example. There are always going to be times when there actually is a good reason for doing something which looks like vandalism, and admins are the obvious group to allow to do that. Therefore, not only should this software not desysop admins, it shouldn't restrict their actions at all. --Tango (talk) 13:55, 9 July 2008 (UTC)

I don't think we need to autodesysop. It would make more sense to just disable the abilities that would lead to autodesysoping. Though I agree with Tango that we just should be able to do these things and let the community react after the fact like we always have. _{1 != 2} 14:02, 9 July 2008 (UTC)

Automatic responses

No no no, we have more than enough problems with automatic responses for the existing bots, almost all of which I'd like to see scaled back considerably to require manual confirmation. We have over a hundred thousand reasonably active editors, and all they need is help in watching things. A report is quite another matter--certainly we can have reports of actions that merit investigation. I would never call them anythign so derogatory as "abuse reports" -- we AGF in our users. The mostthey will be is worth investigating, at various levels of priority. DGG (talk) 18:44, 23 June 2008 (UTC)

My initial reaction is much the same as DGG. Currently I don't really have a great deal of trust in the bot community. It's been unresponsive to many reasonable requests and done a bad job cleaning its own house. The community has, unfortunately, shown itself unfit for this level of responsibility: it has operated numerous unapproved adminbots--sometimes even to carry out completely pointless tasks--sometimes even over community objection--and sometimes failed to really communicate about it. That'd be a massive disaster with a blackbox that was blocking and desysopping. In theory I'm not wholly opposed to the idea, but in pragmatic reality I don't see a group of users who are fit to administer this (which is not to say there aren't individual editors here and there that I'd trust, but administering this would seem to require a functioning group, and I just don't know of enough users for that group) and thus I'd prefer to see reports that a human had to look at--sort of like how users and bots currently send reports to AIV that a human looks at before blocking. --JayHenry (talk) 04:25, 24 June 2008 (UTC)

Firstly, I must note that the code of the extension itself will be public in the MediaWiki subversion repository, that the filters will be editable by anyone with the appropriate privileges, and that it would be very simple to disable any user's use of the filtering system, any particular filter, or, indeed, the entire extension. This is quite different from, say, an anti-vandalism adminbot. The code is private, and, in any case, too ugly for anybody to know how to use it properly. The code can only be stopped in real terms if somebody blocks and desysops the bot, and the bot is controlled by a private individual, with no testing.

In this case, there are multiple hard-coded safeguards on the false positive rate of individual filters, and the extension itself will be well-tested. In addition, I suggest that a strong policy would be developed on what the filters can be used to do, and on what conditions they can match on: I've developed a little system which tests a filter on the last several thousand edits before allowing it to be applied globally.

So I stress that, unlike unauthorised adminbots, there are numerous safeguards, checks and balances, which allow it to appropriately target behaviours such as blocks and desysoppings — if you don't intend to delete the main page, or mess around with moving several other users' userpages in quick succession as a new account, you probably don't have anything to worry about. — Werdna talk 07:41, 24 June 2008 (UTC)

Please change this wording: "Warning: This action has been automatically identified as harmful." Insert "apparently" before "harmful". False positives must always be treated with respect. ☺ Coppertwig (talk) 00:22, 10 July 2008 (UTC)

Effectiveness?

While it does sound good, right now we have a handful of blacklists, a few antivandalbots, and some sekrit adminbots. To date we haven't been very effective in preventing determined users from causing disruption. We can clean it up quickly, we can slow them down, and we can make them jump through a myriad of hoops but they eventually realize we're on to them and change their tactics. Will this really be able to make a difference in prevention? Mr.Z-man 20:51, 23 June 2008 (UTC)

Every hoop you add makes a difference. Daniel.Cardenas (talk) 02:26, 9 July 2008 (UTC)

I agree with Mr. Z-man: maybe preventing specific types of vandalism such as page-moves would be useful, but preventing too much vandalism will shift their attention to other types of more difficult to recognise vandalism. --Steven Fruitsmaak (Reply) 07:31, 9 July 2008 (UTC)

Or, put another way, if the kids don't get their thrills by seeing "Mike is the king of the universe" appear for 10 minutes on a random page, they'll find more subtle (and harder to undo) ways of getting their kicks? Xargque (talk) 23:07, 9 July 2008 (UTC)

Absolutely

Absolutely! Anything to help. It would be nice if it could semi-protect every page on Wikipedia too. Bubba73 (talk), 03:41, 9 July 2008 (UTC)

Semi protection off all articles pages would not likely be done as it is one of the meta:Foundation issues to be able to edit pages without registering. And some registered users, such as myself, would not make/have made an account if it were so. NanohaA'sYuri^{Talk, My master} 00:50, 10 July 2008 (UTC)

Surely these vandals are mostly idiots/bored kids, who wouldn't bother to look up filter code?

This tool sounds very promising, but I can't support it unless the filters are public knowledge. If it is to become an extension to mediawiki I would expect its code and filters to be released under the GFDL, and freely available to look at. The filters would then be a work in progress, just like the rest of Wikipedia. I don't consider that this will diminish the tool's effectiveness, as surely most of the vandals targeted are idiots/bored kids, who are not going to take the time and effort to understand the detail of comprehensive filters in order to circumvent them? Rjwilmsi 07:00, 9 July 2008 (UTC)

We're not targetting the 'idiots and bored kids' demographic, we're targetting the 'persistent vandal with a known modus operandi and a history of circumventing prevention methods' demographic. — Werdna • talk 07:28, 9 July 2008 (UTC)

Sanctions (What we can do about edits)

The first 4 listed all make sense, as they will be an effective way of deterring fast editing vandals and limiting the amount of damage they can do. The last 3 should be manual operations, having an auto-post to the AIV noticeboard at that level would mean that it was a tool, not a parallel system, to users reporting vandals. I don ont thin it should be able to desysop people, removing roleback makes sense as this is common and could be used by vandals, but how many sysop vandals so we get? --Nate1481(^t/_c) 07:26, 9 July 2008 (UTC)

The ability to make rights changes is included more for completeness than out of an assumption that it would be useful on en.wiki. We don't have to make use of it if we don't want to. Happy‑melon 16:08, 9 July 2008 (UTC)

Flagged revisions is the answer?

I would prefer to see the Flagged revisions implemented as a vandalism reduction tool (if it is effective). It has been implemented on the German WP but I am unsure of its success. -- Alan Liefting (talk) - 07:48, 9 July 2008 (UTC)

Filters

Whew long page : ) - Nice idea, though I'm a bit hazy on the "filters".

Could you give some (more) examples of filters? (And please clarify what they are in terms of this process, and how they would work.)

Also, I agree with the above concerning auto-desysop. Desysopping seems to be controversial enough without attempting to sell others on allowing some automated process to do it. - jc37 09:17, 9 July 2008 (UTC)

Clarification

Many coming here seem to be under the impression that the purpose of this extension is to prevent common, garden-variety vandalism. This is not the case.

The abuse filter is designed with specific vandalism in mind. For instance, adding something about elephants because of what you saw on Stephen Colbert, or moving pages to 'ON WHEELS!', or whatever.

It is designed to target repeated behaviour, which is unequivocally vandalism. For instance, making huge numbers of page moves right after your tenth edit. For instance, moving pages to titles with 'HAGGER?' in them. All of these things are currently blocked by sekrit adminbots. This extension promises to block these things in the software, allowing us zero latency in responding, and allowing us to apply special restrictions, such as revoking a users' autoconfirmed status for a period of time.

It is not, as some seem to believe, intended to block profanity in articles (that would be extraordinarily dim), nor even to revert page-blankings. That's what we have ClueBot and TawkerBot for, and they do a damn good job of it. This is a different tool, for different situations, which require different responses. I conceive that filters in this extension would be triggered fewer times than once every few hours. — Werdna • talk 13:23, 9 July 2008 (UTC)

Dry run

Is there a way this tool can do a dry run where instead of performing an action it just posts what it would have done to a page? If we could see the results of a couple of weeks then the community could make a more informed decision. _{1 != 2} 14:08, 9 July 2008 (UTC)

Exactly what I was thinking, so I second this suggestion. —Travis^talk 15:18, 9 July 2008 (UTC)

If it were enabled, we could set up what filters we thought would work with all their 'actions-on' just to be log events, so yes. Happy‑melon 16:31, 9 July 2008 (UTC)

Good to know it is technically feasible. I would certainly considering supporting the filters if I could audit the results in a dry run. _{1 != 2} 16:33, 9 July 2008 (UTC)

Endorse a dry run with logging but no edits. Log what the edit summary would be but don't make the edits. This means no warnings to users either. After a couple of days, examine the log and go from there. Lather, rinse, repeat. davidwr/(talk)/(contribs)/(e-mail) 16:45, 9 July 2008 (UTC)

Definitely needs a dry run before going live. Caerwine Caer’s whines 17:12, 9 July 2008 (UTC)

Indeed, thirded. SQL^{Query me!} 20:12, 9 July 2008 (UTC)

fourthed (if that's a word.) I think further discussion is pointless unless we see this extension in action. I don't there would be any objections to a test run to see if it works and/or how well it works. Thingg^⊕⊗ 23:00, 9 July 2008 (UTC)

Yes, do the experiment. Then we can discuss the results. Tim Vickers (talk) 23:11, 9 July 2008 (UTC)

Biggest problems on wikis are not obvious vandalisms

Biggest problems on wikis are not obvious vandalisms. They are (1) content disputes that don't relate to acuracy but to point of view and how some people enjoy reverting other people like it's a sport, and (2) completely innacurate information.

Can anyone find a Grawp vandalism that actually lasts and lingers? I think Grawp is only noticed because people talk about him like he's this terror of the wiki when he's just some vandal that instead of doing random stuff that's harder to catch, he does the same stuff over and over for vanity. Here's some Grawp vandalism examples: [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] See, so obvious and easily fixable. The problem is subtle stuff. For instance obvious trolling is easily reverted, but subtle trolling goes unnoticed and often ends up with the victim getting the blame.

The filters Werdna proposes sound like obvious stuff everyone looks for anyway, which in its simplest form is if the account appears to be single-purpose or not. But this filter does not sound like it will find any subtle inaccuracies or subtle vandalism, just obvious vandalism.

I have been on dozens of wikis and I have found that what encourages subtle inaccuracies and subtle vandalism are people that enjoy reverting other people like it's a sport. So if none of my edits to an article last because people want to get their jollies by reverting anyone they can get away with, then I dewatchlist it so I don't get any more mad. The worst stuff I've seen has been off wikipedia on small wikis where the founder doesn't watch the site and the site is run by a handful of volunteer administrators who just bully every single new user who ventures onto the small wiki, even blanking any attempts at talk communication. Basically, if people tried to revise disputed content instead of simply reverting or blanking it as many people do on many wikis as a sport, then more people would watch small articles and fix innacuracies and subtle vandalism that is only noticed by people familiar with a content and watching it. William Ortiz (talk) 15:20, 9 July 2008 (UTC)

I think I have to concur with you on that one William. I've noticed it too. I've had more problems with people determined to protect their own contributions and closed minds to any possibility of improvement than through vandalism.Hethurs (talk) 15:32, 9 July 2008 (UTC)

The fact that Grawp-style vandalism is easily noticeable and revertible is precisely why we need this extension: because currently we have a lot of people spending a lot of time finding and fixing this stuff when we all have better things to be doing. If we have the AbuseFilter dealing with this simple, silly, yet irritating, vandalism; that gives us all more time to be looking for and fixing the subtle vandalism you mention. This extension is not designed to catch the subtle vandalism, because it's too hard to identify directly. It's designed to catch the obvious vandalism to leave the humans more time to look for the subtle stuff. Happy‑melon 16:35, 9 July 2008 (UTC)

I agree with the Happy melon. davidwr/(talk)/(contribs)/(e-mail) 16:46, 9 July 2008 (UTC)

Indeed. Happy is correct. While subtle vandalism is more difficult to detect, it also has two other properties that make it a whole different matter: 1)Anyone can revert it easily. and 2)It is impossible to auto-block. In contrast, vandalism such as the above is difficult to revert and often an admin must be found to clean up. Also, this type of vandalism can be auto-blocked and I think it should because doing this will free the rest of us to clean up the subtle vandalism without worrying about hundreds of pages being moved in a few seconds. Thingg^⊕⊗ 23:06, 9 July 2008 (UTC)

Alternative approach to Bots

The problem that I have experienced with Bots is that they can sometimes be over-zealous and get in the way of legitimate activity within Wikipedia - which is really annoying and discouraging. I'm not that keen on the idea of introducing another one.

The best way of combating vandalism, which I think should be tried first, is to prevent all edits unless you are logged in to a valid Wiki username. Vandals, whether they are attacking Wikipedia, Grafiti'ing the wall of your house or letting your tyres down, are aided by darkness and the ability to conceal themselves.Hethurs (talk) 15:27, 9 July 2008 (UTC)

That one is just...no. Wikipedia is what it is because of the 99% of users who edit anonymously and edit helpfully. NuclearWarfare (talk) 16:44, 9 July 2008 (UTC)

I wouldn't say that 99% of IP edits are constructive... the point is that while the 70% or whatever of IP edits that ar vandalism don't last, the 30% that are productive help build the encyclopedia for everyone. The point of a wiki is that you can never fall backwards, because you always have the previous version to fall back onto; the more people there are making new versions, the more of those versions will be constructive improvments, 'higher' than the version before that. Being able to cut out some of the edits that are obviously unconstructive is naturally a good thing because it saves time for the rest of us, but apart from that we should be encouraging as many people to edit as possible. Happy‑melon 16:53, 9 July 2008 (UTC)

It may also be true that 99% of users who edit anonymously and helpfully are so supportive of Wikipedia that they would fully understand why it is necessary to log-in. Just because Wiki has allowed anonymous edits previously doesn't mean it has to continue if there's a problem with vandalism.Hethurs (talk) 16:59, 9 July 2008 (UTC)

The thing is, your proposal would A)Annoy many editors who would otherwise have helped the project and B)Not catch the worst vandalism anyway. NuclearWarfare (talk) 20:19, 9 July 2008 (UTC)

Wikipedia relies on people who read an article, notice an error, and fix it. That might be the person's only edit ever. If they have to register an account just to fix it, they will be far less likely to do so. (And with 47,406,557 registered accounts, we're going to start running out of decent usernames soon) Mr.Z-man 21:17, 9 July 2008 (UTC)

I wonder how many of those accounts have made at least 1 edit? I wonder how many of those account owners have made an edit in the last year? In the last month? davidwr/(talk)/(contribs)/(e-mail) 01:22, 10 July 2008 (UTC)

I believe around 50-60% have never made an edit. Mr.Z-man 01:39, 10 July 2008 (UTC)

I agree with forcing everyone to register...then we could block their names easier. Wiki doesn't need anonymous posters anymore. They vandalize too much. Smarkflea (talk) 02:51, 10 July 2008 (UTC)

Like I stated somewhere above (or was it below?), I don't think it would be a wise move to mandate registration, from I can see most of the registered users start out as anons, and then "graduate" on to being a registered user. Also per meta:Foundation_issues and this issue. Vivio Testarossa^{Talk Who} 03:33, 10 July 2008 (UTC)

This is not particularly relevant to the proposal. — Werdna • talk 01:47, 10 July 2008 (UTC)

A good start

I think that this is a good start to counter some of the terrorism that plagues wikipedia. I admit that I am leary of granting this ability to all but I also think that the general ability to counter terrorism should be less restrictive (although it should be included with) the administrative tools. I hope this new change is approved but since items such as this typically don't meet consensus I won't be holding me breath. I think over all its a good idea though and a good start.--Kumioko (talk) 16:34, 9 July 2008 (UTC)

Creep

This seems like a high complexity and restriction creep. I really don't see how it is worth it. And it is not something that new users could expect or easily get used to. I'd prefer something more intuitive, like a review process. If not that, then the current system is preferable. Aaron Schulz 18:39, 9 July 2008 (UTC)

It's not really for that. The idea is to automatically deal with the very blatant, serial pagemovers for instance, freeing up human resources to deal with the less blatant stuff. SQL^{Query me!} 20:13, 9 July 2008 (UTC)

Testing method

It strikes me that the only feasible of way of testing an extension like this is to have it running/monitering but NOT actually banning anyoen or blocking any edits. The extension just logs what action it would have taken. The community can examine the logs, and weigh up the number of malicous edits that would have been prevented versus the number of good edits that would have been prevented. Only then can we see if this what we want Tompw (talk) (review) 20:00, 9 July 2008 (UTC)

See above SQL^{Query me!} 20:14, 9 July 2008 (UTC)

a problem, but not a solution to it

There is a saying to the effect that to a man with a hammer, every problem resembles a nail. This proposal, in all variants to date, attempts to redress a (not very evident to me, but I may have missed something) problem in the social realm of Wikipedia with a programmatic solution. Given the variety of detail such a problem can take, the programmatic approach take the wrong action not infrequently.

The cost of errors will be high. I know that I would be most irritated if some automatic mechanism decided some unusual approach by my sysop self to do something sensible were grounds for chastisement.

I think the path of wisdom in this instance is deferral. ww (talk) 01:00, 10 July 2008 (UTC)

I've been thinking

Do we really need this extension, after all we have our bots, our admins, and dedicated antivandal fighters... all this effort doesn't seem worth it, since the troublemakers are only a small percentage of the users. NanohaA'sYuri^{Talk, My master} 00:54, 10 July 2008 (UTC)

I'm inclined to disagree. I think the idea is that the filters act as a passive vandal-fighter, allowing less manpower to be eaten up on vandals, so (hopefully) more could be spent on other activities. I believe this could be a useful feature. -FrankTobia (talk) 01:17, 10 July 2008 (UTC)

Automatic filters are anti-wiki

Automatic censorship won't work on a wiki. First, this produces all kinds of side-effects, like e.g. in here (funny). Or, in another example, a German company called FAG Kugelfischer (manufacturer of ball bearings) couldn't get any more emails through to their US customers. "fag" AND "ball"...? OK dump it to the spam folder. Or, take WP articles like "nigger" - how is one supposed to edit them? What would you do here, write article-related exceptions? What a fuss. Or allow only some users to edit such "critical" articles, maybe based on editcount? That would be a serious step away from the equality of contributors that made WP big in the first place. Not to talk of transparency, or ease of use. And where does it lead to? "Secret algorithms" (see above), great, go on, I can't get enough of that stuff! Also, if I was in a heated discussion, and called someone names... then what? Have me blocked by an admin, OK. He will most probably have some understanding of human nature, and be able to estimate how the conflict came along, and which measures may be appropriate. But have me blocked or my edit altered by a program? No way!!! I mean, when you're on it, why not have the insolent user electrocuted in the process. Once such a program is up and running, that remains a subordinate question of style. Bzzzt, 790 (talk) 15:37, 2 July 2008 (UTC)

You are missing the point of the extension, which is not to deal with vandalism like this. Take a look at Special:Contributions/Fuzzmetlacker. Or Special:Contributions/AV-THE-3RD. This is an incredibly destructive vandal editing pattern which is almost impossible to deal with by normal methods: Misza13 runs a script that blocks users with this (unquestionably unconstructive) edit pattern, but even with the best code optimisation available (average time to block: 3 seconds!) it's not good enough. This extension has zero latency: when an edit pattern like this is detected, the account will be blocked instantly, with no time to cause disruption. Similarly, any questionable edit to the main page should incite a block-first-ask-questions-later approach. It's things like this that the extension is designed for, not to replace Clue Bot, VoABot, etc. I can make a personal promise that I will immediately remove any filter that triggers on the use of the word "nigger" - that would be foolish beyond belief. I could not agree more that secret settings are totaly incompatible with the wiki philosophy; but this extension is most definitely not. Happy‑melon 15:58, 2 July 2008 (UTC)

Thank you for your clarifications. Still, I'm not convinced that such a filter wouldn't do more harm than good. Alternate methods of preventing the type of attack you outlined are used in the german language WP, like blocking the main page from editing by anyone but administrators, or preventing page moving by newly registered users. But I have to admit that these may seem even more restrictive than an automated filter. -- 790 (talk) 10:06, 3 July 2008 (UTC)

We already do both of those things already. shoy 12:32, 3 July 2008 (UTC)

What about restricting page movement not only by account age, but also by editcount (say 50?) -- 790 (talk) 12:49, 3 July 2008 (UTC)

All of these measures are already in force: the restriction for autoconfirmed status, which allows moving pages, is 4 days and ten edits. The reason we need this extension is because simple, sweeping heuristics like these just don't work. It's far too easy to get around them, and we can't make them more restrictive without an unacceptable level of false-positives. But with this extension comes the ability to make more intelligent decisions. For instance, the most common way of bypassing the editcount restriction is by making trivial edits to a userpage: with this extension, we could set a pagemove filter that was independent of autoconfirmed status, requiring the ten edits to be to separate pages, to have provided substantial content, or not to have been reverted. We can revoke autoconfirmed status (currently impossible) if necessary, we can do all manner of advanced things that we currently can't do to counter vandalism without making life difficult for legitimate editors. That's what's so exciting about this extension, and why we want it up and running ASAP. Happy‑melon 15:42, 3 July 2008 (UTC)

Although that would be an absolutely terrible filter. That would be far too broad, especially if the public isn't aware that they're being expected to edit an arbitrary number of separate articles before being granted move priveleges by gestapobot; people would be pretty (understandably) confused when they get banned for moving something when they followed all the instructions in MOVE to the letter but missed out on the super-secret editing criteria that no one knows about. If kept non-transparent, this should only be used for the most obvious (i.e, moving thousands of pages in a few minutes) and blatantly unconstructive edits that could never reasonably be performed. Anything else needs human observation. Celarnor ^{Talk to me} 16:09, 3 July 2008 (UTC)

You are forgetting that A) this is in place (as best we can manage) already, and B) we do have actions other than blocking for when filters are tripped. If a filter were written along the lines of "TRIGGER IF: action=page-move AND account-age<4 OR (editcount<10 AND pages-edited<5) ACTION: disallow", then this would be just a more sensible version of the autoconfirmed limit we have already. Removing the "pages-edited<5" part would render the filter identical to the current autoconfirmed limit, with the exception that it could be altered or adjusted without having to bug the developers to make configuration changes all the time. Happy‑melon 16:51, 3 July 2008 (UTC)

We have already decided as a community that is what we want. There's no secret panel of editors who keep autoconfirmation requirements a secret. To be changed, we have to discuss it as a community and develop consensus. That's vastly different than administrators, or worse, a smaller subset thereof, change it at will without any notification to the community exactly what they need to do, and not having any repercussions for keeping it a secret from the community. Celarnor ^{Talk to me} 19:33, 9 July 2008 (UTC)

I think eletrocuting insolent users would be appropriate. We need to install Magna Volt systems in all wiki-accessible computer terminals... Azoreg (talk) 15:15, 9 July 2008 (UTC)

With regards to the links presented above, would not an edit rate filter have stopped that?? What human (wo rollback) can edit more than 5-10 pages in a minute in a meaningful way?? Maybe I am missing something obvious here -- but these cases can be blocked by public rules (temporary block [30 minutes] standard & autoconfirmed users if edit_rate_by_user > 10 pg/min) + (initiate captcha if edit_rate_by_network > 10*average_edit_rate_by_network && 3day_average_edit_rate_by_network > 20 pages/hour ). Something more refined along these lines would block the tactics of the linked users,surely? Ie limit dedits/dtime (above some minimum # of edits) as well as edits/user? I *must* be missing something. User A1 (talk) 11:45, 10 July 2008 (UTC)

The only thing you're missing is that everyone who initially supported closed-source filters has now come round to the conclusion that they're untenable :D. I wouldn't implement exactly that filter as it might have an overly high false-positive rate, but something like that would certainly catch a lot of vandal accounts and sockpuppets. The point is we currently don't have any mechanism to implement filters like that, and this extension promises to provide that functionality. Happy‑melon 13:12, 10 July 2008 (UTC)

No, But instead

I agree that we need to change in order to deter some of this vandalism. Far too much time is spent fixing vandalism that could be productively spent elsewhere, but not everything would be picked up by lists of rude words. However I'm concerned that a nontransparent filter would bite newbies if only by frustrating some good faith edits. I think that a simpler solution could include either or both of the following changes.

1. Don't allow unregistered users to make edits with blank Edit Summaries. Instead make the field mandatory and set an auto prompt which could be linked to profanity lists or other tests, so a default of "Please summarise your edit" or less politely Please explain why you want to blank this page/use a profanity
2. Look up the IP Address as part of the confirmation process for unregistered users, and display this to them before they confirm their edit. Again this could be tailored, "As an unregistered user, your edit is being made from (name of school etc)" or less politely Before you blank this page/use a profanity, remember you are doing it from a computer at (name of school etc)

Jonathan Cardy (talk) 12:51, 9 July 2008 (UTC)

I'm too computer challenged to comment on the abuse filter per se, but I would like to second Jonathan Cardy's suggestion. Making edit summaries mandatory and gently suggesting that the Internet is not the anonymous place some vandals seem to believe it is sound like steps in the right direction to me.--John Foxe (talk) 13:50, 9 July 2008 (UTC)

The first of these ideas (or at least something very similar to it) could be implemented in this extension. Happy‑melon 16:17, 9 July 2008 (UTC)

Such a proposal sounds very similar to this one, which has been rejected many times by the community. NanohaA'sYuri^{Talk, My master} 00:28, 10 July 2008 (UTC)

Yes the proposal to make edit summaries mandatory has been turned down before as this could be irritating to users who don't like to leave edit summaries, But hopefully the differences are sufficient to counter the previous objections, in particular I'm now suggesting that only unregistered users would have to leave edit summaries, it would still be optional if you register. And compared to some of the more draconian anti vandalisms measures being discussed I think my proposals are quite mild. Jonathan Cardy (talk) 06:11, 11 July 2008 (UTC)

First, hell, no. I didn't realize I was supposed to actually use the edit summary for quite a while; punishing people for not realizing that is a terrible idea. Besides, as it has been pointed out, that is a perrenial proposal that has been rejected many times over. I don't really see the advantage made by the second point. Celarnor ^{Talk to me} 01:52, 11 July 2008 (UTC)

Making Edit summary's a mandatory field for unregistered users would mean they couldn't make edits without leaving a summary. So at worst it could be described as a compulsory chore not a punishment, some of my early edits didn't have summaries, but as soon as I realised you could opt to make it a mandatory field from your UserID I did so. Jonathan Cardy (talk) 06:11, 11 July 2008 (UTC)

Reciprocity on Sanctions

I suggest that as an incentive to careful setup of this mechanism, any editor who has the privilege of setting up this system who causes one or more other editors to be restricted due to a coding error have the same sanction applied to his/her account(s) regardless of the mechanism having been set up in good faith. This would be cumulative. For example, A sets a filter incorrectly, causing B, C, and D to be blocked for 1 day each. A is blocked for 3 days. --Gerry Ashton (talk) 16:15, 9 July 2008 (UTC)

blocks are not punitive. Believe me, knowing that you've screwed up as an admin and that everyone is laughing at you is much worse than screwing up as an admin and getting blocked for it. A couple of days ago I made a sandbox copy of the main page... and then proceeded to hack around with the main page instead of the sandbox! When it was pointed out, I was so embarrassed I went and hid in a sandbox for the rest of the day, trying to make a block of text circular (:D) because I felt such a fool. I displayed a screen full of redlinks to thousands of wikipedia readers, and yet the worst I got was a wikitrout. That's what makes Wikipedia such a welcoming and friendly place: if you screw up, it doesn't matter as long as you don't do it again. If you start punishing people for making mistakes, you distroy that atmosphere. Because we're all amateurs - no one on-site is a 'professional' AbuseFilter maintainer, because we're not professionals. Receiving tangible punishments for screwing up is what happens if you receive tangible rewards for doing well... and unless you want to pay every admin on-wiki, that's not going to happen any time soon. Happy‑melon 17:00, 9 July 2008 (UTC)

Your action didn't result in harsh penalties toward innocent people. You just did something stupid, you made a mistake that didn't hurt anybody. We're talking about making mistakes that hurt the ability of others to edit on no fault of their own. Celarnor ^{Talk to me} 18:04, 9 July 2008 (UTC)

So what if I'd accidentally redirected the page to Fellatio?? It could happen, and what do you think would be the reaction? I'll tell you: [meta:Special:Log/rights]]: Steward changed rights for Happy-melon@enwiki from 'sysop' to 'none' , until you'd made sure that I wasn't running amok with a compromised admin account. Assuming that was proven, my bit would (I hope) be restored to a huge amount of ritual, good-humoured abuse from the rest of the community. No matter how stupid the action, or how severe its consequences, if it can be proven that they were made in good faith, we rely on that good-humoured abuse to keep the community together. We block, desysop or revert only to protect the project from future harm - that's the most important tenet of WP:BLOCK. Change that, and you destroy the principle of AGF, and hence destroy the friendliness of this amazing community. Happy‑melon 20:44, 9 July 2008 (UTC)

Blocks still are not punitive. I would rather see someone lose their access, if they're consistently screwing up. SQL^{Query me!} 20:11, 9 July 2008 (UTC)

Well, that's an alternative, more draconian option, although I think immediately going down the route of de-sysopping for every mistake they make is a little extreme, especially towards the beginning where there will be the most false positives. I don't want to see a bunch of people who put work into authoring filters lose their privileges over it, but it does need to be established with as much strength as possible that they have to be as limited, narrow and focused as can be done. I'd rather have a looming threat of blocks for those who screw up dealing with the filters than give them free reign over them without any repercussions for failure to prevent false positives or abuse. If public access isn't given to the logs, this is a necessary step to keep this from becoming a Bad Thing. Celarnor ^{Talk to me} 21:39, 9 July 2008 (UTC)

I don't think SQL is suggesting that individual mistakes should lead to desysoping. My example above is a demonstration of when we do desysop: when it is necessary to protect the encyclopedia. If a user has demonstrated a consistent inability to use extended rights safely, responsibly and appropriately, then they forfeit the right to access those tools - this would apply to AbuseFilter settings as much as any other admin permission. But we don't block admins for making bad blocks, because that's not preventative (you know you can still use Special:BlockIP when blocked?). Happy‑melon 13:38, 10 July 2008 (UTC)

I agree. Having something like this in place would help dissuage some of my concerns about the incredible amount of non-transparent power that would be wielded by those in control of this system. While blocks may generally not be punitive, blocks shouldn't made by machines, either. This is a very special case. It should carry a strict and harsh penalty, which would help in keeping the filters as narrow and focused as possible. If the community can't directly ensure that the filters aren't being used abusively, they should be able to have sanctions put on those responsible for using them abusively; I'll conditionally support the filter with the inclusion of this provision. Celarnor ^{Talk to me} 18:04, 9 July 2008 (UTC)

You realise that, as a result of the top third of this discussion page, the "non-transparent" system will in fact be totally transparent? That every action will be as transparent as going to Special:BlockIP directly? We already have a system in place to deal with admins who go to that page and block users incorrectly: we take them to ArbCom and get them desysopped. As SQL says: why should that be any different here? Happy‑melon 20:44, 9 July 2008 (UTC)

So the filters are publicly viewable, then? That should have been clarified earlier. In that case, then no, this wouldn't really be necessary, since the community can review the filters themselves and point out problematic heuristics. Celarnor ^{Talk to me} 21:39, 9 July 2008 (UTC)

Blocks are not punitive. A good, worthy and valuable editor will get over any mistake that inconveniences them. A troublemaker will make trouble. ╟─Treasury§Tag►contribs─╢ 20:01, 9 July 2008 (UTC)

A few weeks ago, an accident with the Titleblacklist caused spaces to be forbidden from new article titles (I think this happened twice actually) for a few minutes. I see no good reason to punish people for mistakes, nobody's perfect. Mr.Z-man 21:24, 9 July 2008 (UTC)

That doesn't create a potential for an automated, completely human-detached tool to mass block people who haven't done anything wrong. An accident like that was bad, but no, punishing them doesn't create any benefit. But if you're irresponsible enough to not review your criteria to the point where multiple, concurrent innocent people are suffering blocks because of it, then you probably shouldn't be a sysop in the first place; however, considering the novelty of this approach, I don't think desysopping is the solution. Temporary blocks should be sufficient to drive home the point that this is extremely important. Celarnor ^{Talk to me} 21:39, 9 July 2008 (UTC)

Does the point really need to be driven home? Don't sysops already know that this is extremely important? And how are people actually harmed by being temporarily blocked from editing Wikipedia, anyway? Can't they take the dog for a walk instead? Read a book? See a movie? Venture out into the real world? ThreeOfCups (talk) 03:32, 10 July 2008 (UTC)

If they already realize the importance of it, then they won't have a problem and won't have anything to worry about; they'll be diligent and will make focused filters that are narrow in scope that won't get sanctions against them. Celarnor ^{Talk to me} 13:04, 10 July 2008 (UTC)

But why would a cooperative community want to sanction volunteer sysops for accidentally causing editors a temporary inconvenience? That seems to violate the spirit of Wikipedia. The community would suffer far more from the absence of the sysops than the sysops themselves would. ThreeOfCups (talk) 01:38, 11 July 2008 (UTC)

I'd rather suffer from the absence of sysops who aren't capable of effectively using the tools granted them by the community and yet continue to try to do so than suffer block after block because of programming carried out carelessly with no repercussions for failure. In one of those situations, I can still edit. Celarnor ^{Talk to me} 01:56, 11 July 2008 (UTC)

Will not be implemented. — Werdna • talk 02:08, 11 July 2008 (UTC)

The price of freedom....

... is eternal vigilance. Someone said. I think this applies generally to the vandalism problem. If Wiki is to continue to allow just anybody at all to make alterations, then a large number of people are going to have to keep watch to revert the silly stuff. Any other method of reducing the vandalism problem is likely to be oppressive.

Automatic processes are very quick, which means that giving automatons the power to revert is the effective equivalent of prior restraint. That is, they can remove edits before any person sees them. Some speech therefore becomes forbidden for all practical purposes. Do we think that automatons have the judgement to apply prior restraint to speech? Do we think they should be allowed to do so even if they can be imbued with excellent judgement? We don't allow the government to apply prior restrain to speech, why would we build robots to do it? Laziness?

TheNameWithNoMan (talk) 17:39, 9 July 2008 (UTC)

Isn't this exactly what ClueBot does? And VoABot II, and AntiVandalismBot, and all the other anti-vandal bots that we accept are vital necessities in keeping this project open to IP editing? But that is a side issue, because this extension is not designed to replace those bots; it is, as you say, too powerful. This extension is designed to be used for vandals like the ones I link to below: intelligent, aggressive, destructive editors who aim to do as much damage as possible to the wiki and the people who edit it. It's not on the main field that we need this extension: the anti-vandal bots do a stunning job, and they do it at just the right level of efficiency. It's on the constant skirmishes against the handful of intelligent and malicious persistent vandals that we need every tool available just to stay ahead of their game. These are the editors who would, in the real world, be tried for crimes against humanity - the users who have demonstrated time and time again that all they want to do is do as much damage as possible. Do we allow ourselves to use prior restraint against them? No, because we don't need to - they've already done enough harm to condemn themselves many times over. Happy‑melon 21:07, 9 July 2008 (UTC)

I think I see what your saying, and I agree. We don't need to let some computer revert what it thinks is vandalism, we just need some sort of organized way of dealing with it ourselves. ---G.T.N. —Preceding comment was added at 18:43, 9 July 2008 (UTC)

Worse, we're not talking about reversions; this would have the capability of blocking users. Celarnor ^{Talk to me} 19:29, 9 July 2008 (UTC)

It depends what the user is trying to say. I think someone needs to put a very big sign at the top of this page that this extension is not designed to replace ClueBot, RCPatrol or the rollback button. Can you think of a single situation where we would want a user who edits like this to keep talking? Or this, this, this, etc etc etc? These users were blocked within five seconds of starting this vandalism spree by an adminbot that has been written specifically to counter vandalism of this sort; and yet look at the damage that was inflicted. That script works; it works quickly, reliably, and the only false positive I know of was when it blocked SQL's alternate account when he was pretending to be such an vandal. And yet it's not good enough - within those few seconds, damage is caused that takes ten minutes or more to clear up. With this extension, we have zero latency: we can do the same job that's being done already, without having to have a user running a script on a paid-for server that has to fetch the block token every twenty seconds to make sure it can respond as fast as inhumanly possible; and we can do it instantly, cleanly, and without any fuss. Humans simply can't do the job that that script is doing, and anyone who thinks it doesn't need to be done seriously misunderstands the situation. This extension can do that script's job so much better, so much faster, and so much more effectively; why wouldn't we want to use it? Happy‑melon 21:07, 9 July 2008 (UTC)

I don't have an issue with ClueBot because I've never seen it block people; as far as I know, it isn't capable of doing that. I just have a lot of difficulty supporting something that has the capability of blocking people without first consulting an administrator with some kind of "Is this a good idea (Y/N)?)" oversight; even more so if the mechanism by which it decides what to do isn't completely visible by the public. Celarnor ^{Talk to me} 21:46, 9 July 2008 (UTC)

Perhaps it would be better if the "system" would autoreport the "vandal", to Wikipedia:Administrator intervention against vandalism instead of autblock? That way a human would be making the (yes/no) choice instead of a machine. NanohaA'sYuri^{Talk, My master} 00:20, 10 July 2008 (UTC)

That would be much more appropriate behavior, IMO. Disallowing actions like Haggar pagemoves, editing the main page and the like are one thing, but blocking is the job of a human who can look at the data and be sure. Celarnor ^{Talk to me} 00:30, 10 July 2008 (UTC)

I agree. Humans need the final say.---G.T.N. —Preceding comment was added at 03:14, 10 July 2008 (UTC)

Guys, we do have that already ;) But the idea is to prevent the behavior so admins can stop spending 10 minutes each time reverting the changes, then calling oversighters to the rescue, then maybe protecting the page, preventing regular editors to perform the function. -- lucasbfr ^talk 06:51, 10 July 2008 (UTC)

The extension has a disallow action; it doesn't need to block people to prevent an edit matching its filters, since it can simply keep that edit from happening. There's absolutely no reason that particular function needs to be implemented; a human should still be the deciding factor. Celarnor ^{Talk to me} 12:56, 10 July 2008 (UTC)

I agree in principle, but the question is whether the extension would reliably keep the user from making destructive edits until an admin had reviewed the situation. If the entire trigger-disalow-warnANI-review-block cycle only takes a minute, that's ten or twenty times longer than Misza13's script gives them (which as I've noted, has had no false positives so far). If only the half the actions they try to make in that time are disallowed by the filter, they'll actually end up making more of a mess than they do now. And if the filter is configured to reliably disallow all their actions in the intervening period, then what's the difference to being blocked? Happy‑melon 13:51, 10 July 2008 (UTC)

I think a few minutes isn't going to make much of a difference. It isn't going to matter whether they were kept from doing it and blocked 5 minutes later by someone who went through their contributions or if they were blocked immediately; if the filter is good enough to justify its presence here, then those few minutes aren't going to make a difference. Celarnor ^{Talk to me} 14:12, 10 July 2008 (UTC)

I think a lot of people misunderstand the speed of response that's required to effectively stop the sort of vandalism that this extension is designed to combat. The users I linked to above were blocked by an adminbot script within five seconds of beginning to edit disruptively, and look at the mess they were allowed to make. No matter how efficiently ANI posts are processed, no matter how little time a human needs to review the situation, it's too long. These vandals are either using carefully-prepared tabbed browsers, or fully-automated vandalbots, which have been specifically designed to cause as much damage as possible in as short a space of time as possible. Exactly how this extension can best stop these people from making destructive edits is open to debate, but suggestions that the stop/don't-stop decision is one that can be left to humans seriously misunderstand the timescales involved. Happy‑melon 13:51, 10 July 2008 (UTC)

So? The filter disallows their disruptive edits while a human decides whether or not to block them. I'm not seeing the problem here; both situations keep vandalism from happening. The only difference is one keeps the extension from making potentially harmful decisions. I don't see the problem. Celarnor ^{Talk to me} 14:12, 10 July 2008 (UTC)

Assigning permissions

As I said above, I think it's time to have a discussion on some of the specific implementation issues of this extension; and access rights is a good place to start. There are five permissions that are attached to the extension. Assigning some of these is easy; others not so. So let's take them one at a time.

abusefilter-private

This right gives access to private data such as IP addresses: per the foundation access to nonpublic data policy, this permission cannot be given to any users whose identity has not been revealed to the board: consequently, it can only be assigned to the 'checkuser' or 'oversight' groups. Of the two, 'checkuser' makes by far the most sense, so I would think that the assignment abusefilter-private → 'checkuser' is entirely uncontroversial. Happy‑melon 16:53, 29 June 2008 (UTC)

I agree, that it should only be "checkuser" as they are they only ones, (besides developers and stewards) that have access to this data otherwise. Vivio Testarossa^{Talk Who} 17:16, 15 July 2008 (UTC)

abusefilter-log

This is the permission which enables users to view the abuse log. As far as I can tell, it looks like users who are blocked or hindered by the extension without this permission would not be able to see the log entries corresponding to their actions; if this is the case, then this permission must be given to everyone who might be affected by the extension... which is everyone. Any objections to abusefilter-log → '*'?? Happy‑melon 16:53, 29 June 2008 (UTC)

I have no objection to this. — Werdna talk 00:50, 30 June 2008 (UTC)

abusefilter-log-details

Users with this permission can see the exact details of the action attempted, with the exception of the private data which is available only to users with abusefilter-private. Since there's nothing in this summary that users can't work out for themselves with only a little effort, I can't see any reason not to assign this permission the same as abusefilter-log, that is, abusefilter-log-details → '*'. Comments? Happy‑melon 16:53, 29 June 2008 (UTC)

The only extra thing it gives out is a filter ID, which might be useful if, for instance, we described all grawp filters as 'Grawp', and other users could figure out which of the grawp filters they matched, giving them a clue to figuring out heuristics. — Werdna talk 00:51, 30 June 2008 (UTC)

I would never describe a filter as "anti-Grawp" - it's pretty much the ultimate WP:FEED error. I would have thought that reverse-engineering the filter settings would be tedious in the extreme even if you knew which one you were tripping each time. If we allow filter settings to be viewed by all, then this permission is irrelevant anyway; but even if not, I would have thought the right to know what you did wrong, and what bit you, shouldn't be too much to ask. Happy‑melon 11:00, 30 June 2008 (UTC)

I agree with keeping it at everybody, and upping requirements if and only if it proves necessary. — Werdna • talk 11:05, 13 July 2008 (UTC)

abusefilter-view

It sounds like this permission, and abusefilter-modify, might be in the process of being converted into an array similar to the edit-protected system: with different levels of access available as different permissions. However, it seems that a consensus has developed above that at least the majority of filters should be available in their entirety for all users to view, which corresponds to abusefilter-view → '*'. Comments? Happy‑melon 16:53, 29 June 2008 (UTC)

I'd disagree with this. Would prefer abusefilter-view → 'sysop', per above. — Werdna talk 00:52, 30 June 2008 (UTC)

It looks like this is the area where there is most contention; possibly where we need a discussion or poll to gauge a consensus. I agree with the many comments raised above that security through obscurity is both a weak protection in itself, and anathema to wiki philosophy. This extension is never going to 'win' the fight against vandalism - as you've said youself, that's not the point - so obscurity will only slow the evolution of vandal attack patterns, not stop them. The benefits of transparency and community development easily outweigh the extra effort needed to keep the filters up to date. And as you've said, if it's kept secret, it will leak... and we'll be less prepared to deal with that when it happens if we're expecting the settings be secret. Happy‑melon 11:05, 30 June 2008 (UTC)

I agree, of course, that '*' is the only really acceptable setting for this. —Simetrical (talk • contribs) 22:08, 30 June 2008 (UTC)

When you are crafting filters to address individual styles of vandalism such as the grawp page move vandalism detector shown in the dry run, then security through obscurity can work. It is really when you apply a security methodology to a large group of people that security through obscurity becomes a major issue. I do however believe it is important that the community keep access to the results of such filters and be able to judge based on dry runs if they are beneficial or not.

As for who actually gets to edit and view the filters, that should be left to the community to decide based on trust and competence. Possibly just all sysops, but alternately a selection process of some sort. The people able to view it should be limited to the people able to edit it imho. _{1 != 2} 19:46, 10 July 2008 (UTC)

So if I understand correctly, what your saying is that users should either have complete access or no access to the filters? I don't agree, in that I think that everybody should have access to view what filters are being applied. What prevents an admin from setting up a filter to WP:OWN a page, and autoban anyone who tries to edit said page except him/herself? Also, if only admins can view/edit this filter a compromised admin account could create a create a rule that would result in possible irreversible damage. Vivio Testarossa^{Talk Who} 17:15, 15 July 2008 (UTC)

A compromised admin account can't already cause damage? Unless we include the desysopping feature (which I doubt we will), the worst this could do is block users, which is as reversible as a normal block. Mr.Z-man 02:16, 16 July 2008 (UTC)

The people who have access to edit filters will not be random people off the street. They will be trusted members of the community, and there will be oversight (e.g. the abuse log, other users). I would not imagine that automatically banning people who edit a particular page is particularly compatible with retaining the rights to edit filters. — Werdna • talk 02:10, 16 July 2008 (UTC)

abusefilter-modify

This allows holders to modify filters which are applied by the Abuse Filter - it's probably the most debatable. Who should have the right to set and alter the filters that are in place on en.wiki? I think here we need to remember what this extension is supposed to be used for: its primary advantage is that, being part of the site software, it has zero-latency: Misza13's anti-Grawp script can slam in a block token just 5 seconds after detecting a heuristic-matching edit pattern, but this extension can do it before the first vandal action has even been completed. It has no real advantages over anti-vandal bots other than speed and tidiness: the majority of its functions can be performed just as well by a well-written script running on an admin account. However, there are some functions, most notably rights changes, which are way beyond what an admin can imitate. I have a suspicion that a filter could easily be implemented to desysop any specific user on their next edit; or (worse still) desysop all admins as-and-when they edit. Even granting this permission only to bureucrats would be giving them a right that they don't currently have - full access to this extension gives users half the power of a steward. Consequently, the ability to set filters which invoke rights changes should, in my opinion, be assigned separately to the other permissions, and only to completely trusted users. I would say give it only to the stewards, but they do not have a local right on en.wiki that the extension can check; my second choice would be those already trusted to the level of 'oversight', which is essentially the ArbCom (and stewards if necessary). Everything else the extension offers can already be done by admins, and I can see no reason not to give them all the tools available. My personal preference, therefore, would be abusefilter-modify → 'sysop' and abusefilter-modify-rights → oversight. I'm especially keen to hear other people's views on this area. Happy‑melon 16:53, 29 June 2008 (UTC)

Actually, stewards is a global group now, but I'm not entirely sure how it would work assigning local rights to a global group. But as almost all oversights are arbitrators or ex-arbitrators, I see no problem with giving this to oversights (or possibly creating an "arbcom" group). Mr.Z-man 18:08, 29 June 2008 (UTC)

Most rights assigned to global groups are local. — Werdna talk 00:56, 30 June 2008 (UTC)

Even better, as it gives greater flexibility. I am still happy with our oversighters having the right, and stewards could get it if it were assigned to 'oversight' just by adding themselves to that group, so it makes sense to put abusefilter-modify-rights → ['oversight','steward'] as far as I'm concerned. Happy‑melon 10:47, 30 June 2008 (UTC)

Well, we can, of course, disable the 'desysop' action on Wikimedia quite simply. I think that may be the way to go for the moment — I included it only for completeness, and took care that it could be easily disabled. That said, I would still like to restrict modification of filters to a smaller group (and viewing of hidden filters is the same right), although I suppose restricting it to 'admins' would be better than nothing. The reason I suggest this is my above comments — we have lots of admins, and lots of precedents for disgruntled admins doing some leaking. — Werdna talk 00:56, 30 June 2008 (UTC)

What are your reasons for wanting to restrict it to a smaller group? Other than security through obscurity, which seems to have been debunked above, what benefit does minimising the number of people who are able to respond to new vandalism patterns have?? This is probably the most powerful anti-vandalism tool ever created for MediaWiki: we would be shooting ourselves in the foot if we made it almost impossible to use. Happy‑melon 10:47, 30 June 2008 (UTC)

I don't agree that hiding heuristics from the public is a problematic form of 'security through obscurity'. The point of AbuseFilter is to target vandalism with specific modi operandi — for instance, Willy on Wheels, Stephen Colbert, and meme vandalism. By their nature, many of these vandals will be quite determined, and, therefore, if we expose the heuristics we use to detect them, they will simply move to other forms of vandalism which aren't targetted by the filters. If, however, we pose a barrier, even as low as needing a sysop to leak the filter's information, or getting a proxy IP blocked, or something, then the user's ability to determine what's in the filters is limited, and so they can't simply circumvent the filter by changing individual aspects of their behaviour. SQL has told me that he has had instances of vandals following his subversion commits to determine ways to circumvent restrictions on use of the account-creation tool. In short, I don't think open viewing is going to cut it. — Werdna talk 11:54, 30 June 2008 (UTC)

Don't worry, I'm fully aware of what security through obscurity means - and you've just given a textbook definition of it. However, I simply don't agree that it's the right approach. If we make the filters publically viewable, then vandals will immediatley find ways to circumvent them - that's a given. If we don't make the filters publically viewable, then it will take longer for the vandals to adapt, but they eventually will. How much longer is not something we know with any certainty. Given that the only way to make it harder for the filter settings to leak is to minimise the number of people who have access to them, we would also be limiting our own reaction time - it will take longer for whoever maintains the filters to adapt them to the new vandalism pattern. So we have a choice: a rapid arms race, or a slow arms race. But the thing is, this isn't a traditional arms race: if we configure the filters such that the only way for vandals to survive is to intersperse their attacks with productive edits, then we've won!! We've turned a pure vandal into one who mainly makes good edits and only occasionally does something unproductive. We have a choice here, just as we had a choice years ago: either we have a small group of trusted people writing articles or setting filters, or we put our faith in the power of the people to write about things they have no professional experience of, or maintain filters which they don't 100% understand; safe in the knowledge that A) by keeping histories and ensuring transparancy, we ensure we can never go backwards, only advance; and B) the final product, although built by people with usually inferior skill-sets and sometimes malicious intentions, will be many times better than the best that that small group of pros could ever manage. What's the difference between maintaining this extension, and maintaining the whole encyclopedia? Happy‑melon 12:28, 30 June 2008 (UTC)

I doubt that requiring vandals to intersperse their edits with good contributions is going to be achieved through the filter. More like, they find out that we're targetting the special characters in their page-moves and move onto another way of slipping their page-moves past the filter. Or they find out we're targetting users with less than 50 edits, so they do 51 edits. I also disagree with your analogy to writing the encyclopedia — we're talking about who has access to view the filters, not who can edit them. Certainly, one could argue that more eyes on the filters would allow a larger community to help, but I contend that you're still sacrificing the ability to keep heuristics ahead of vandals (as I've described above, our favourite vandals are pretty good at finding the right places to look), for what is ultimately an ideal, without a basis in practicality.

I admit, however, that, while I would prefer to hide filters from regular users, activating the 'hidden' setting on sensitive filters might be an acceptable compromise if used judiciously. — Werdna talk 12:45, 30 June 2008 (UTC)

Vis "we're talking about who has access to view the filters, not who can edit them", I'd have thought that that's what the section above is for - this one is, after all, entitled "abusefilter-modify"!! It's true that the two are easily confused, however. I'm not denying that security through obscurity works, or even that it would work well in this situation. The thing is that it's untenable to use on a wiki founded on the principles of transparency, community and equality. The great benefit of the extension as I see it, other than zero-latency, is the ability to use advanced heuristics to catch vandal patterns. It's not going to be as simple as "user makes 50 trivial edit then a page move → block": we can (fortunately) define more complicated patterns which will be more effective at catching vandals as they evolve their tactics. The more people we have able to cook up those advanced heuristics, the more effective the extension will be. That's why I can't see any reason to assign this permission any higher than 'sysop'. Those admins who don't trust themselves with the extension, won't use it: take a look at my block log if you need proof of that. This extension is not the be-all and end-all of vandalism on-wiki, but it is potentially the most powerful tool we have available, and our only chance to "win" as I described above (don't forget that we can also 'win' by making it so hard for vandals to vandalise that they give up in disgust :D). We should be trying to ensure that it is used as widely and effectively as possible, which means the more hands to the mast, the better. Happy‑melon 17:58, 30 June 2008 (UTC)

Happy-melon echoes my sentiments pretty much exactly. It's not acceptable to set this to anything above 'sysop' (and of course, not below that either). Auto-desysopping should be disabled ― or if enabled, only stewards or something should be able to set it. Hidden filters would also have to be disabled entirely for the extension to even begin to be acceptable to me, personally, as I have outlined above. —Simetrical (talk • contribs) 22:14, 30 June 2008 (UTC)

I think that {{{1}}} would be reasonable. If we did that, Werda's scenario (where vandals can see everything) would not happen (and leaks would be limited somewhat), and at the same time, with around 4,000 sysops and rollbackers, it would be very easy to update the filters quickly to deal with imminent and/or in-progress threats, especially since nearly all prolific vandal-fighters are members of one of those two groups. J.delanoy^gabs_adds 03:38, 9 July 2008 (UTC)

Can't be done. Would present a security risk, allowing any user with rollback permissions (which, let's face it, is pretty easy to get), to apply sanctions to users which are, by design, limited to sysops. — Werdna • talk 03:55, 9 July 2008 (UTC)

Oh, yeah. Duh. *smacks head on desk* I guess that's what happens when I edit when I'm tired. Sorry. J.delanoy^gabs_adds 15:40, 9 July 2008 (UTC)

Security through private obscurity - mbots

[For a clarified description of the mbots proposal, skip down to the large box]

My reading of this page is that the most frequently mentioned advantage of the proposed anti-vandalism Mediawiki extension, is speed of response compared to similar private bots. The major improvement over bots seems to be that of amplifying speed-of-response.

Why not create the mediawiki extension as an amplifier toolkit for "bots"?

One of the two most frequently mentioned objections is to publicly-obscure filter algorithms for the extension. Proponents believe filter algorithms should be relatively obscure, and opponents think they should be relatively open to viewing. Proponents cite private obscurity by bots as precedent, and so far, no one seems to have objected to private bot obscurity. Therefore:

Why not allow private bot owners to decide, hold or change the obscure filter algorithms for the extension toolkit as they do now for their own bots?

A technical difference from usual script bots is that this kind of "bot" would supply filter parameters for the extension program running on the Mediawiki server.

Opponents suggest ideas (probably learned from open source cryptography theory) that "security through obscurity is never effective". It's not true that security through obscurity doesn't work at all. If that were so, military and spy agencies wouldn't use it – but – to remain effective it must be rigorously maintained. All security software requires constant attention and upgrading. To do this, defense agencies pay dearly for what public enterprise obtains on the cheap through open source code scrutiny. In actual use, open source security software does not reveal the privately held keys, equivalent to filter algorithms here. In this situation, the cost of occasional security-through-obscurity failure is not high, and competition among bot owners (for social status of anti-vandalism success) will tend to keep their privately obscure algorithms maintained. Milo 18:26, 10 July 2008 (UTC)

Well, as I've said before, it's not necessarily that it doesn't work, it's that it doesn't work well enough for all the effort. I don't believe that, in this case, working to keep the algorithms and logs secret will give much benefit. On a side note, I love the bot idea. — ^FatalError 18:45, 10 July 2008 (UTC)

As far as I'm aware, the use of security-through-obscurity in this extension has been largely abandoned. I don't think I entirely understand the technical modifications you've proposed. Happy‑melon 18:47, 10 July 2008 (UTC)

From what I understood, he's proposing that instead of having an independant extension, have it simply add power to bots. So bots would still use their current algorithms, but they would be able to stop vandalism through the extension, halting it before it happens. So basically let bot owners make their own filters. Correct me if I understood it wrong. — ^FatalError 19:09, 10 July 2008 (UTC)

That's not really possibles, bots are users and can't have the ability to do the things done here (preventing edits before they are done, checkusering users, removing special rights). You need to be hooked on the code to do this. Arguably a steward-bot could do some of this, but I think this might not be taken well by the community! ;) -- lucasbfr ^talk 19:29, 10 July 2008 (UTC)

Indeed - only a bot that had the 'steward', 'sysop', 'bot' and 'checkuser' flags would be able to match this extension in capability. Happy‑melon 20:53, 10 July 2008 (UTC)

Even then, it still couldn't quite match it. The best a bot can do is revert the edit as fast as possible, this can actually prevent the edit from being made in the first place. Mr.Z-man 00:30, 11 July 2008 (UTC)

Thanks for the responses.

First, there seem to be no term of art for what I'm proposing, so I'll create it.
I put "bot" in scare quotes because it's not a script bot. As I understand it, script bots run on some other server or desktop computer, and act like users or sysops of Wikimedia services, but faster.
I'll call my proposal a type of "mbot", meaning any bot-like programmable thing that runs on a Mediawiki server rather than an external server.
Since it's an mbot, it's not necessarily limited in the particular ways that a bot is limited in speed and functions. In theory, an mbot can do anything Mediawiki can do, and do it as fast as Mediawiki can do it. In practice mbots will always have many limits set on what they are allowed to do, as well as probably being speed-throttled for various reasons.
Internally to the Mediawiki servers, I presume that an mbot is a process, programmable with parameters, and each mbot runs in a separate instance, meaning that there are as many programmable processes of a similar type as there are mbots.

FatalError (19:09): "So basically let bot owners make their own filters."
This is almost correct. The difference is that it's an mbot owner, so they are not faced with the limits of standard script bots.
Allowing current anti-vandal bot owners to also program AF mbots utilizes people already skilled in anti-vandal programming. This could allow probably all of them who wish to do so to have their own mbot process, though with mbot limits always being set by the master Abuse filter.
As already bot operators, they may be able to develop a synergy between their bots and mbots. For example, if their mbot stops an attack, it could immediately signal the bot to read the mbot log, and then the bot sends email or writes a talk page specific to a known vandal. (Note it's a secure programming practice to avoid the code clutter and master Abuse filter parameter passing tasks of having mbots do any auxillary function easily done by a bot.)

lucasbfr (19:29): "bots are users and can't have the ability to do the things done here (preventing edits before they are done, checkusering users, removing special rights)." ... "You need to be hooked on the code to do this."
It would be. An mbot is not a user, it's a child process (in my proposal) of the Wikipedia:Abuse filter. Implemented as a toolkit, an mbot would be able to do anything that the Abuse filter allows it to do. And somewhat unlike a script bot that must be entirely blocked to stop it, the Abuse filter can disable or modify specific mbot tools, on the fly if necessary.

Happy-melon (20:53): "only a bot that had the 'steward', 'sysop', 'bot' and 'checkuser' flags would be able to match this extension in capability."
No need for that broad a set of powers. The Abuse filter toolkit would only allow AF mbots to do specifically authorized things named in the Werdna proposal, but do them much faster than a steward bot.

Happy-melon (18:47): "As far as I'm aware, the use of security-through-obscurity in this extension has been largely abandoned."
The reason that it has been abandoned is because it is the secrecy of a central control, analogous to a government secrecy. Such a system is capable of secret future abuse (or more likely, secret future screw-ups), and as you pointed out is subject to (totality-scale) leaks. Users know or suspect these things due to the proposed centralized-hierarchy structure, and want to avoid them.
But by doing so they give up the advantage of secret filter parameters in defeating persistent learning-adapting vandals, who will otherwise – without question – simply look up the public filter parameters and program around them. Both Werda and 1!=2 clearly understand this issue, as do I and many other techies.

---

My proposal solves both problems. By implementing private AF mbots using the public Abuse filter infrastructure, the currently user-accepted private-bot filter parameters can help defeat persistent vandals of public Wikimedia services – without centrally-controlled secrecy.

---

Because there would be an ecology of AF mbots, leaking of any one set of mbot filter parameters would not necessarily compromise the other mbot filter sets.
Because the parameters would remain private to the owner, they would tend to use the best parameters they could immediately think of, rather than hold back ideas knowing the vandals will immediately read them from the public filter parameters file.

Note that the AF mbot toolkit would be limited to, at most, the Abuse filter functions with the cautious limits that Werdna has already proposed. Mbots would not be more powerful than these limits, but they would probably be far more creative. Mbots can also selectively be made less powerful than the maximum Abuse filter capabilities, and even selectively less powerful on an individual mbot basis if necessary.

Happy-melon seems to feel an urgency to get the Abuse filter proposal implemented, even with public filter parameters. Why not? This will provide a baseline for how much more effective the Abuse filter might be if AF mbots are subsequently implemented.

I hope this helps. Milo 06:02, 11 July 2008 (UTC)

The problem is that the more well meaning people able to directly plug their own code into MW you have, the more probable a screw up (in the sense of false positives, server load, or even losing content) is. And you don't have a [[Special:Blockip|panic button]] in case everything goes wrong. Personally, I'm more in the favor of restricting the ability to set filters as much as possible, to people that have a high incentive to triple check before creating a new filter (a screw up will create a storm of drama, and people will start to ask for heads on pikes very fast). On a technical side, the extension (not the settings) will be (is?) released under GPL and I trust the devs to accept the good-advised help people want to provide. -- lucasbfr ^talk 09:16, 11 July 2008 (UTC)

From a programming perspective, your proposal doesn't make a lot of sense. In terms of function calls and passing data around, it's both simpler and more efficient to extend MediaWiki itself to review a given edit and do something with it rather than pass it off to some process, wait for it to respond, then process the edit. When there's a more efficient way of doing it, you're going to need reasons to do it that way, and there really don't seem to be any. The function of this isn't to fight vandalism or improve existing adminbots; it's designed to be a toolkit to dealing with very simple, very easy to detect types of vandalism. Celarnor ^{Talk to me} 18:10, 11 July 2008 (UTC)

Also, with bots, the level of secrecy is controlled by one person - the operator. For usage of MediaWiki features, the secrecy would be regulated by the community. I don't see how the first is better... Mr.Z-man 00:14, 12 July 2008 (UTC)

The first is better because bot and mbot operators will keep their anti-vandal parameters privately controlled by one person, that the community will not keep as a central secret.

Some Abuse filter parameters only work if they are both an evolving set of parameter secret surprises to vandals, and implemented with Mediawiki functionality.

Since the community does allow parameter secrets to be kept by private bot owners, private mbots are a way to combine the privacy advantages of bots and the functional power of Mediawiki. Mbot private parameters must operate within the same strict limits imposed by the master Abuse filter, which has public limits regulated by the community. Milo 02:17, 12 July 2008 (UTC)

Lucasbfr (09:16): "people able to directly plug their own code into MW"
No. Only limited filter parameters as currently specified by Werdna could be plugged in, not code.
The creativity required to program limited filter parameters is analogous to writing haiku or sonnets which have strict rules.

Lucasbfr (09:16): "screw up ... server load"
Routine problem easy solved with throttle settings.

Lucasbfr (09:16): "screw up ... losing content"
That's a bogeyman in the proposed context of parameter-only programming.

Lucasbfr (09:16): "screw up ... false positives"
A built-in mbot test mode does seem like a good idea. I assume that mbot operators could use the same retrospective test method that Werdna used to predict lack of false positives for the master Abuse filter. I'll defer to Werdna on this.

Lucasbfr (09:16): "[[Special:Blockip|panic button]] in case everything goes wrong."
Consider it proposed.

Lucasbfr (09:16): "a screw up will create a storm of drama, ... very fast"
Not all screwups create drama, not all dramas are of storm proportions, and some storms blow over quickly.

Lucasbfr (09:16): "people will start to ask for heads on pikes"
One of the useful features of private mbots is that one particular screwup head will go on the pike, while the ecology of persistent vandal protection from the other private mbots continues.
Study up on the fragility of monocultures and the robustness of diverse ecologies, generalizable to all social and mechanical systems.

Lucasbfr (09:16): "I'm more in the favor of restricting the ability to set filters as much as possible, to people that have a high incentive to triple check before creating a new filter"
De facto done. To avoid getting their head put on a pike, such people would certainly include experienced vandal bot/mbot operators. These competent techies also aren't clueless about the political risks of their operation.

Lucasbfr (09:16): "I trust the devs to accept the good-advised help people want to provide."
Ah, the flip side of excessive central secrecy... excessive central trust. Devs don't know, and/or are too busy to do, everything that could be done.
As a helpful consultant I would not advise, nor as a dev would I do other than shelve, any filter parameter likely to be defeated by the vandal's public inspection of it. It's only common sense to save these for the day when secret Abuse filter parameters become available, one way or another.
Why not publicly benefit by implementing them sooner in this acceptable, accountable, and ecological private mbot form? Milo 19:16, 11 July 2008 (UTC)

It's very difficult to follow what you're saying with your novel way of interleaving wikicode and HTML. It doesn't look particularly attractive, and makes your comments, especially your replies, extremely difficult to read. In any case, having tons of extra processes programmed by a bunch of different people isn't efficient, is harder to maintain control over compared to a centralized system like the one in proposal now. Why have a bunch of extra processes that have to have variables and references passed between MediaWiki and amongst themselves every time someone makes an edit? It doesn't make sense to approach the problem that way when there is a more efficient and more easily managable method available. Celarnor ^{Talk to me} 02:32, 12 July 2008 (UTC)

Sorry to hear about your problems with reading comprehension, novelty, and algorithm analysis. Unfortunately, you haven't been able to integrate what I've written so far. Therefore you would be unable to follow my further attempt to explain why theoretical issues of efficiency don't trump a socially-determined application architecture.

I suggest that you move on to less challenging threads. Milo 06:40, 12 July 2008 (UTC)

I'm sure you mean well, but it seems pretty clear that you have very little experience in coding, at least for production environments; there are no theoretical issues of efficiency, they're all quite real. When you're talking about passing variables (or even references, really) between so many processes and waiting for the results, you're going to experience a massive drop in efficiency. This isn't like a cluster environment used for scientific computing where the goal is eventual processing power over speed of processing individual tasks. The idea is (or should be, at any rate) to process the request, run some MySQL queries, then generate the resultant page; what you suggest places a large number of other processes that the data has to be passed around to. This may not be a problem in your freshman CS classes with your webserver written in Java that handles maybe 2 requests a week, but on a production server that handles millions of requests a day, you'd better have really good reasons to introduce a host of processes on the toolserver that examine every single edit. One person who has a memory leak in their bot could literally grind Wikipedia to a screeching, unresponsive halt until someone pkills it. Your proposal has also effectively made the toolserver a production server, as it is completely necessary for the day-to-day functioning of the project, and that simply isn't possible; whenever it goes down, all edits will hang until either someone disables it by hand or the extension times out a connection to the server and disables itself (which is a great way to simply disable the filter by DDOSing the toolserver), opening us up to the very vandalism that this was meant to combat.

I'm sorry that you don't quite grasp basic concepts of computing and th, but they are, unfortunately, necessary to understand why what you suggest is a Bad Thing. I suggest that you move on to less challenging threads.

But humoring the idea a little more, even if we were to ignore the considerable practical issues (which are in and of themselves enough to abandon this idea), as others have said, this effectively changes the control of the mechanism to a single person, extended by the toolkit; any control the community would have would be separated by another level of indirectness; with the extension the way it is, the community can notice a problem, go to one of the admins and say "Hey, this needs to be changed." There isn't any third party involved. Just the community and the agents of the community.

Third, this would make it a lot harder to examine the filters and promotes decentralization and obfuscation; rather than going to a single page and viewing the filters (or description thereof, depending on the outcome of the above discussion of the abusefilter-view privileges), you have to hunt down a list of bots, then trying to view the information available, contacting people when necessary when that information isn't available. You're also effectively elevating bots to the steward level by providing them with access to the same tools as this filter; bots with those kind of privileges should never, ever be controlled by a single person. They've also been rejected by the community several times whenever they show up; hell, even adminbots are relegated to the most movement and renaming tasks for the most part. The bar for entry would be nigh-unattainable. Celarnor ^{Talk to me} 14:18, 12 July 2008 (UTC)

←Nah, those things won't happen. You couldn't read what I've already written, so you don't understand my proposal. Therefore I'll skip technical commenting on the house of fud you've conjured up. Programmer's machismo is bad form, so I'll skip those comments too.

Here are the only parts of your impressive 3.4K rant that are relevant:

"Third, this would make it a lot harder to examine the filters and promotes decentralization and obfuscation; rather than going to a single page and viewing the filters (or description thereof, depending on the outcome of the above discussion of the abusefilter-view privileges), you have to hunt down a list of bots, then trying to view the information available, contacting people when necessary when that information isn't available."

You have correctly analyzed this point, and, thanks, I see two ways to improve the level of concern about ease of filter-event followup.
I propose that each mbot's filter parameters should include an mbot/owner signature link-stamped into the log and the file-copied error messages, making it easier to review the filter action and contact the owner.

I further propose an Abuse filter page that should list all filter sets, both public and mbot-private. A horizontal row of dated boxes (say the last 31) should appear under each filter set. Each box should contain the number of times that particular filter set was triggered on that date. Clicking on a dated box should take the reader to a section of logs containing those filter events for a detailed event review. From the log page, the reader should be able to link to either the private owner's mbot user page, or the discussion page for the master Abuse filter's public filter sets.

"as others have said, this effectively changes the control of the mechanism to a single person, extended by the toolkit; any control the community would have would be separated by another level of indirectness; with the extension the way it is, the community can notice a problem, go to one of the admins and say "Hey, this needs to be changed." There isn't any third party involved. Just the community and the agents of the community."

Yes, third parties are a necessary condition at the root of my proposal. As I've previously stated several times, the community will permit only private owners to keep private anti-vandal filter parameters. The advantages of private anti-vandal parameters come together with private bot/mbot owners. Take both or leave both. Milo 20:06, 12 July 2008 (UTC)

This is a separate feature request. You would do well to come up with a better word for this functionality — I would open a bug report, severity enhancement, as an extension request, with a title like "Allow foreign code to hook into MediaWiki events", or something similar. Positing a use case would be a good idea, but please steer clear from defining and using terminology like 'mbots'. It would confuse the situation. — Werdna • talk 11:01, 13 July 2008 (UTC)

Werdna (11:01): "Allow foreign code to hook into MediaWiki events"

In my proposal, absolutely not. Foreign code would open the door to the fear show imagined above.

The mbots' code would be a standardized Abuse filter process module, probably written by you, with about the same code for each private owner. What each owner would do is install private Abuse filter parameters and external signal URLs in the module, in what amounts to an active configuration file. On an mbot owner's interrupt request command, the configured parameters with owner's signature stamp would be compiled into the main filter set for run-time efficiency.

There are several advantages to an active configuration module, including external signaling to standard bots. Most importantly, without code activity it wouldn't be a "bot", which politically it must be in some analogous form.

I understand your technical nomenclature discomfort with "mbot", or any other word containing "bot". What you call confusing the situation is a political bridge, designed to gain community consent for private parameters by analogy to standard bots.

Based on your valid reasons for publicly undisclosed Abuse filter parameters, my goal was a proposal to gain community approval of privately owned parameters in the presence of an urgent contextual need. (And btw, grawp hit an article on my watchlist several hours ago.) I have no interest in an abstract technical feature request, which anyway lacking such urgent context, would not be approved.

Since you reject the "mbot" term, a necessary community political component, and offer no politically-compatible replacement name, I assume that is the end of my proposal and this thread. Sorry that I was unable to assist you and the community. Milo 14:19, 13 July 2008 (UTC)

Um, what? He's saying that you should request a developer code such a feature (as this likely doesn't already exist), not propose it to the community. Most developers, especially if writing an extension (not part of the core software code), could care less about the "political" implications of the wording, clear and technically accurate are far more important. Many could care less if it would even be useful for Wikipedia. Mr.Z-man 00:15, 14 July 2008 (UTC)

I understood what Werdna said.

My late proposal does not exist outside of the context of the Abuse filter, and the code algorithm I outlined (as opposed to what others imagined without asking me) is integrated with it. I assume Werdna wrote most of the Abuse filter code? That means that Werdna, the proposer of the Abuse filter, had to at least agree that my proposal was interesting. "Agree that it was interesting" is technical politics. He didn't agree, so that's the end of my proposal.

No one with technical politics experience would naively repeat an Abuse filter auxillary proposal at bugzilla, after the principal AF proposer had rejected it here. Milo 07:05, 14 July 2008 (UTC)

Yes, I am suggesting that you request implementation on bugzilla, where further comment from developers can be had. My objection to the term 'mbot' was not political, it was for clarity's sake. Your proposal perhaps seems clear in your mind, but the rest of us get the impression that you started with the term 'mbot' and have been making it up as you go along. You need to have a clear, succinct proposal on bugzilla before you could hope to have this implemented — comments here are by Wikipedians, and therefore not particularly authoritative on the technical matters which they regard. You've also said "probably written by you". I should remind you that I am a volunteer developer, and work on things as I feel like it. Your proposal is currently too convoluted and unclear for me to even think about wanting to work on it. — Werdna • talk 02:38, 14 July 2008 (UTC)

Werdna (02:38): "My objection to the term 'mbot' was not political, it was for clarity's sake."

Yes, you made that clear, and I agree that was your motivation. I was the one who said I designed the "mbot" term as a political bridge to help you get what you originally wanted (undisclosed Abuse filter parameters).

Werdna (02:38): "you started with the term 'mbot' "

My first post shows that is not a fact: Milo (18:26, 10 July 2008)

I added "mbots" to the section title later: Milo (02:17, 12 July 2008)

In my first post I used "bot" in scare quotes, and explained:

A technical difference from usual script bots is that this kind of "bot" would supply filter parameters for the extension program running on the Mediawiki server.

...and all responders thought I was talking about some odd form of standard bot.

So in my second post Milo (06:02, 11 July 2008), I explained my reasoning and created "mbots" for my concept, because otherwise I couldn't even attempt to explain it further.

Werdna (02:38): "making it up as you go along"

You seem to think that's always bad; I think it's frequently good. I did do that with the "mbot" term, but mostly I did not. Yet I wish I'd had more chance to do so as a collaboration.

I do interactive planning over the course of top down design and bottom up implementation. I started with the top-down concept in the first post, which I did not change over the course of the thread. I had a bottom-up technical algorithm for implementing it, which so far hasn't changed either.

But I'm not familiar enough with the Abuse filter algorithm to be sure that my auxillary AF mbots algorithm didn't have conceptual interfacing bugs. Therefore it made no sense to post my algorithm mid-details until interaction with others reached that stage. I depend on collaboration with others to find that out, which interaction is a form of "making it up as you go along".

Werdna (02:38): "You need to have a clear, succinct proposal on bugzilla before you could hope to have this implemented"

My idea was to assist your original proposal. If you're against it, I have no further interest. Had you encouraged me, we could have discussed technical proposal process.

Werdna (02:38): "comments here are by Wikipedians, and therefore not particularly authoritative on the technical matters which they regard."

My proposal was half political, half technical. If Wikipedians don't politically buy into it, it's not useful. If techies don't buy into it as valid, it's not going to realize. If the master proposer it was intended to help doesn't buy into it, then I consider it unhelpful.

Werdna (02:38): "Your proposal is currently too convoluted and unclear "

It appears that no one understood the complete concept, or if they did, kept quiet. To his/her credit FatalError came closer than anyone else.

Werdna (02:38): "for me to even think about wanting to work on it."

Yes, of course. I was retrospectively describing what would have been necessary, had you been interested. You're opposed to a necessary part of the idea, so obviously you're not going to work on it. In practice that means no one else will either. End of proposal.

I tried to help you and the community, sorry that I could not. Milo 07:05, 14 July 2008 (UTC)

Here is MediaWiki, and here is AbuseFilter. Just because you don't have commit access to the official development trunk doesn't mean you can't hack something together and present it later and have it reviewed by the local devs once you're able to more clearly get across ... whatever it is you're trying to get across. Celarnor ^{Talk to me} 04:58, 15 July 2008 (UTC)

Top-down design should be followed by bottom-up implementation. What you suggest would be a bottom-up implementation following a failure of consensus for a top-down design. Typically this is a waste of someone's resources. (See the incomplete explanation Top-down and bottom-up design#Software development.)

The top-down design failed because Werdna objected to as confusing, the top level "mbot" political-bridge terminology that would have made the project useful. All such bridge analogies can be claimed to be confusing, since they intend to draw less distinction between two concepts. Without the "mbot" political bridge the proposal became unsellable, so there is now nothing compelling to bottom-up implement, especially in a parsimonious development culture.

Here is a semiformal description of the failed mbots proposal:

Background of the Abuse filter secrecy problem

• Anti-vandal filter parameters can be approximately categorized into those that do or do not depend on surprise. If they can view all anti-vandal parameters in advance, persistent vandals will program around parameters that depend on surprise, so those should be kept either private or secret.
• Anti-vandal script bots currently have private filter parameters unknown to the community, but bot owners are personally accountable for screwups and misuse. However, anti-vandal script bots are too slow for high-speed persistent vandalism, and can't intercept vandal-like edits before they are made.
• The Abuse filter extension is fast enough to stop high-speed persistent vandalism, and can intercept vandal-like edits before they are made. Unfortunately, filter parameters that are "private" when held by anti-vandal bot owners, are "secret" when held by a relatively few Abuse filter maintainers.
• The community objects to secrets because they are considered subject to either long-term abuse or lack of screwup accountability. On the other hand, everyone wants individual privacy, so to get it they have to give it to others.

Mbots proposal to solve the secrecy problem with privacy

• Mbots was a combined half-political and half-technical proposal.
• The political half was intended to gain Wikipedian consensus for converting Abuse filter parameter community secrecy into Abuse filter parameter individual-owner privacy.
• The political half was achieved by naming the Abuse filter code modules with a term obviously analogous to standard script bots, but still distinguishable from them.
• The "mbots" term suggested that mbots were like bots, in that the critical anti-vandal filter parameter elements that made them useful, were individually owned, were private, and that mbot owners were personally accountable for screwups and misuse of them. Abuse filter events that might be triggered by mbot private filter parameters, would be traceable through clickable owner's signatures stamped on the error message and the log file for each event.
• The technical half was creation of mbots software – multiple standardized code modules, which were to be child-process subfunctions of the Abuse filter, primarily intended to contain individually-programmable private-parameter data storage. Mbots were designed as active code modules rather than passive data files, partly because any analogy between active code script bots and passive data files would otherwise be too strained. Active code modules also allow useful triggered-event private signaling to the owner's standard bots, without private URL clutter being stored within the main Abuse filter. The mbot module also makes it relatively easy to add new active code functions standardized for all mbot owners.
• The mbots have standardized active code for all owners to avoid security and performance issues. Such issues might result from the random introduction of foreign code elements within the master Abuse filter, which is intended as a Mediawiki central function that checks all edits for possible vandalism. "Foreign" means written by and for an individual mbot owner. While all the mbot passive filter parameters are also "foreign", these have known limits tightly controlled by the master Abuse filter.
• The mbot's programmed parameters are periodically compiled into the master set, along with the owner's signature stamp for triggered-event responsibility tracing. After programming of updated filter parameters, the mbot owner issues to the master Abuse filter, an interrupt request command for compilation. Compilation of the stored parameters from each of the mbots allows the master Abuse filter to operate faster at run-time while it is examining all Mediawiki edits.
• With mbots named and implemented, a synergy was expected, because the anti-vandal advantage of surprise private script bot parameters, would have been combined with Abuse filter high speed and ability to intercept vandal-like edits before they are made.

Milo 07:28, 16 July 2008 (UTC)

Retest if rules change

The very reassuring test results on this filter are with one particular set of rules applied. I'm assuming that the same sort of test would be run each and every time the rules were tweaked, especially the minor uncontentious rule changes that according to sods law are most likely to have unintended consequences; but it would be nice to have that sort of commitment at this stage of the process. Jonathan Cardy (talk) 10:03, 16 July 2008 (UTC)

Not as thorough, but I'm thinking of implementing a software check anytime the rules are changed, which would check against the last (probably) 5,000 edits. — Werdna • talk 10:31, 16 July 2008 (UTC)

I would feel much more comfortable about this if the testing of any rule change involved the same sort of size of sample as you've done here. I appreciate that sounds painful, but if you tested on the previous 250,000 before each change you would only need to look at two groups - those that are no longer caught by the rule and those that are now caught but were previously clean (and of these you could ignore any that have been reverted). Assuming that the real work in the testing is looking at those records where the test result is different, then a small tweak that just identified an extra 1 in 1,000 edits as bad would be easily tested with circa 250 changes - and most of those could be ignored as reverted by others. However a rule change that picked up 1 in a thousand edits but with 1 in 10 of those as false positives would quite likely pass a 5k test. Jonathan Cardy (talk) 13:43, 16 July 2008 (UTC)

Checking 250,000 edits takes 10-15 minutes. This is not really an acceptable amount of load to subject the Wikimedia servers to. — Werdna • talk 13:45, 16 July 2008 (UTC)

Can you test in quieter time slots? Or is there provision to run tests in background? If not the cost will fall over the years as processing power gets progressively cheaper, and it has to be compared to the cost of false positives from an error in a future rule change. Jonathan Cardy (talk) 14:20, 16 July 2008 (UTC)

It is possible to test in the background. The issue is not responsiveness, but server load. As I have said, it's not really an acceptable amount of load to subject the servers to. A test over the last 5000 will take approximately 20 seconds, and pick up any glaring errors. This check is intended as a sanity check, not as a substitute for good filter design. The real test comes when the filter is activated, and any false positives appear during its operation. — Werdna • talk 00:27, 17 July 2008 (UTC)

Dry Run,Mark II

I've just finished a big binge on modifying the filters. With some tweaking, I've managed to get the detection rate up from 33% to 64%, but with a slight increase in false positives (from 4 false positives to 11 false positives). Therefore, currently, the filter I have my eye on has a sensitivity of 64.06%, and a specificity of 99.61%.

There's still a bit more work to do in reducing false positives (Almost all of them are clueless newbies moving pages that they've produced as root userpages. Example: 20080408231651: User:The Gladiators moving User:The Secret (Shareefa album) to The Secret (Shareefa album) with summary new page would trigger filter.). I think I can get rid of most of them by ignoring pages to which that user is the sole contributor.

It is worth considering that the filter, in its original form, or even its current form, would have been helpful to Wikipedia. Its false positive rate was 0.2% (and the highest it's been has been 0.7%). Even with the very high false positive rate, we could only expect 25 false positives per 7 months. That sounds like quite a number, but it certainly wouldn't be a doomsday when you consider that it corresponds to about one a week.

All this goes to show that careful examination of a filter's performance is required before we allow users to enable them. This reinforces my view that, even if filters should be viewable by all, it is perhaps prudent to restrict editing of them to a smaller group than administrators.

In furtherance of this goal of careful evaluation of filter performance before a filter is enabled, I will shortly allow access to a web-based version of my testing ground. Any user in good standing may request an access key, which will allow them to upload filters to check against the last 50,000 actions. The web client will give measures of specificity and sensitivity, as well as full details for any false positives or false negatives. — Werdna • talk 05:50, 18 July 2008 (UTC)

Remind me to ask for a key when you're ready, then. :) Kylu (talk) 05:52, 18 July 2008 (UTC)

How did you get those numbers anyway? Source? NanohaA'sYuri^{Talk, My master} 22:58, 22 July 2008 (UTC)

The numbers come from tests. The filter evaluates its ruleset against each edit in turn, and makes a judgement (yes/no) on whether to block or allow the edit. The sensitivity is the percentage of bad moves (moves which resulted in a block within 10 minutes) which triggered the filter, calculated by ${\frac {\mbox{number of true positives}}{{\mbox{number of true positives}}+{\mbox{number of false negatives}}}}$. The specificity is the percentage of edits matching the filter which are actually bad edits, calculated by ${\frac {\mbox{number of true positives}}{{\mbox{number of true positives}}+{\mbox{number of false positives}}}}$. — Werdna • talk 09:25, 24 July 2008 (UTC)

Agree?

I'm not certain if this has been said already, but it looks to me that we all agree that this is a good thing, the debate seems to be mostly "who gets access to what", and "tweaking the tools".

So do we all agree that this should be implemented? - jc37 20:33, 15 July 2008 (UTC)

No, like I said before (I did right?), the current system seems to be working, and if it "Ain't broke, don't fix it". Vivio Testarossa^{Talk Who} 22:48, 15 July 2008 (UTC)

I am frequently amused by people who attempt to cut through pages of discussion for a particular point, by quoting a one-liner. After the one-liner is quoted, people who agree in principle with the one-liner will flock to support it.

This is not a black-and-white matter, in which the system is either "broken" or "fixed". To characterise it as such is to ignore the fact that there are different levels of efficiency.

Wikipedia's handling of repeat vandals with known modi operandi is currently somewhat effective. We do stop them, but with a hodgepodge of adminbots and hard work by administrators. You have evidently not been involved with the cleanup of redirects after Grawp pays a visit. Neither have you been involved in the CheckUser frenzy that results after a visit. Therefore, our handling is effective insofar as it reverses vandalism.

However, my proposal is to "increase" the effectiveness of our handling, by targetting the vandals before they can vandalise, and by placing restrictions on their accounts and IP addresses when they try, resulting in zero actual vandalism, and all of the admin and checkuser work automated by software. This is an effective system.

You cannot possibly be suggesting that, because our current handling of repeat vandals does eventually reverse and prevent some vandalism, we should rest on our laurels and do what we currently do because it's "not broken". Here, we have an opportunity to improve the effectiveness of our handling of repeat vandals. Let us not ignore it because our current system is "not broke". - —Preceding unsigned comment added by Werdna (talk • contribs) 02:07, 16 July 2008

"Its not broken" is a bit of a fallacious argument. For the current system to be "broken," things like pagemove vandalism would have to be left unreverted and the vandals unblocked. With thousands of active users and hundreds of active admins at any given time, I don't see that happening unless we were totally overrun, in which case even this would probably be insufficient. Its going to be dealt with somehow - it will be either cleaned up manually, automatically or semi-automatically by bots or scripts, or we could use this to stop it from happening in the first place. Mr.Z-man 02:30, 16 July 2008 (UTC)

It's a thought-terminating cliché, really. I think this could be implemented agreeably. Stifle (talk) 10:22, 27 July 2008 (UTC)

Certainly, let's do it. I'm amazed this discussion is still going on. Tim Vickers (talk) 19:15, 4 September 2008 (UTC)

Final consensus-gathering

I'm still working on the technical aspects of this – I have very important exams coming up, and haven't been able to spend a lot of time on it, but I'm trying :). I am presuming at this stage that there is no objection to the following:

• Enable the abuse filter.
• Allow any administrator to edit/view all abuse filters.
• Allow any user to view all abuse filters which have not been hidden, and a brief description of all filters (which should be general enough not to give too much away, but specific enough to allow a user to figure out what part of their behaviour had been targetted.

— Werdna • talk 13:28, 5 September 2008 (UTC)

Will this lead to automatically reverting edits or preventing users from editing with no human intervention? --Apoc2400 (talk) 14:35, 5 September 2008 (UTC)

Yes, but the filters upon which the decision will be based will be open enough that you'll be able to figure out which one it is and complain about it when they start acting on your good faith edits. That said, there should probably be a noticeboard for false positives, or a template like {{editprotect}} to draw the attention of someone who can get the edit made. Celarnor ^{Talk to me} 15:55, 5 September 2008 (UTC)

I think this is the best implementation that balances security, openness, and effectiveness. If we restrict access more, we gain some security, and possibly some effectiveness, but we lose openness and if we restrict it too much, we may lose the ability to ensure the filters are updated promptly. If we loosen restrictions, it could be updated quicker and would be more open, but the security tradeoff would be too great. I personally don't see much of a difference between forbidding an edit (which we already do somewhat with the spam filter, titleblacklist, etc.) and allowing it, but immediately reverting it with a bot, which we currently do. There would still need to be some policy issues to work out, but technically, this seems good. Mr.Z-man 16:44, 5 September 2008 (UTC)

• I support the immediate implementation of this filter, as outlined by Werda above. Tim Vickers (talk) 16:46, 5 September 2008 (UTC)

Question, how will new filters be approved and implemented? RxS (talk) 16:51, 5 September 2008 (UTC)

See Wikipedia_talk:Abuse_filter#Assigning_permissions for the various levels of permission involved. Tim Vickers (talk) 17:28, 5 September 2008 (UTC)

Much of that discussion involves read permission, but some of it (plus the outline just above and the bottom of the project page) seems to grant all admins edit permissions on the filters with no approval process. Is that right? RxS (talk) 19:49, 5 September 2008 (UTC)

I am worried that it will bite new editors who don't know enough about Wikipedia to complain about the false positive. --Apoc2400 (talk) 17:04, 5 September 2008 (UTC)

That should be dealt with by the message that is displayed when an edit is disallowed. We can provide clear instructions on how to deal with a false positive. Since these are going to be very rare (about one a week) they can be dealt with swiftly. Tim Vickers (talk) 17:28, 5 September 2008 (UTC)

• I can agree with the basic idea above. For the issue of "hidden" filters, I still think transparency is ok. As an analogy, the checkuser software for this mediawiki installation is freely available as source code on the web. However, if we can trust administators to write a true summary of the abuse filters, I'm ok with it. It beats raising the edit count for autoconfirmed status. Protonk (talk) 18:06, 5 September 2008 (UTC)

• Based on my experience with the title blacklist, I'm uncomfortable with the idea of giving all admins the ability to edit abuse filters. It's too easy to accidentally block all pagemoves to titles containing the letter "p", and there's the risk that an overzealous vandal-fighter will set up a filter to automatically block a user for moving a page to Template Attribute Language Expression Syntax. --Carnildo (talk) 20:49, 5 September 2008 (UTC)
  • That's true, perhaps all admins would be able to request the edit permission, that should cut down on any "random fiddling" and "I wonder what this does" accidents. Tim Vickers (talk) 21:32, 5 September 2008 (UTC)
    • I'm wondering if perhaps it should be a separate permission, assignable by admins like ipb-exempt and rollback are. Admins would be able to give the permissions to themselves, but should be strongly discouraged from doing so unless they have a clue what they're doing. krimpet✽ 01:00, 6 September 2008 (UTC)
      • If admins don't know what they're doing, they should simply avoid the feature altogether. I don't see a real need to have a new userright for this specifically. And the filter has safety checks to ensure that things like blocking every edit are not possible. </cents value="2"> --MZMcBride (talk) 02:22, 6 September 2008 (UTC)

It should be noted that if a particular filter blocks more than 5% of actions, it will be automatically disabled. This threshold can be changed. To prevent immediate disabling of filters because it happens to match one of the first few edits made, this kicks in after five blocks. False positives are expected to be quite rare – with properly-tested filters, it can be reduced to one or two a month, which is quite acceptable in my eyes. Filters can be set to log only, which could be useful in evaluating filters. — Werdna • talk 08:07, 6 September 2008 (UTC)

• Go for it. This is a low risk option for preventing a few very specific classes of persistent vandalism: if it doesn't work effectively, or if it turns out to be counterproductive, it can always be turned off again. -- The Anome (talk) 13:03, 6 September 2008 (UTC)

I think we need to hold off on this until there's a better plan for implementing changing (or adding) filters. Many admins who don't know what they are doing may stay away but there are those that won't. And perhaps worse, over-enthusiastic admins that do know what they are doing can become overly aggressive. Some sort of lightweight vetting process is needed for proposed changes. RxS (talk) 15:18, 6 September 2008 (UTC)

What about making the rule that all new filters need to be run in log-only mode for a day, before they are turned on for real? That way we could see exactly what they will do. Tim Vickers (talk) 16:04, 6 September 2008 (UTC)

I would agree with log-only for a day, or more depending on how long it takes to get a hit. Mr.Z-man 17:32, 6 September 2008 (UTC)

That sounds reasonable, though I'd prefer a longer sample time. Is a day enough? How about filter changes, would it work the same way? RxS (talk) 17:57, 6 September 2008 (UTC)

If a filter doesn't get a hit in a day's worth of activity (about 120,000 edits), we can be confident it won't cause significant disruption once it is activated. It might be ineffective and not pick up anything, but that won't be a problem for other users. I'd make all changes to filters act in the same way, which should both deter people from fiddling with the filters too often and build in an additional level of safety. Tim Vickers (talk) 18:35, 6 September 2008 (UTC)

If both new and changed filters run in log-only mode for a day that'd be fine. The logs would be available to all users? RxS (talk) 02:10, 7 September 2008 (UTC)

It would be possible to implement this in software, with an "override" function for if we're dealing with something that needs an immediate response. — Werdna • talk 01:18, 7 September 2008 (UTC)

Logs are available to all users. I'm not sure that we should make testing compulsory – merely "strongly recommended". There will always be circumstances in which a one-day is unnecessary and would hinder the effective use of the abuse filter. — Werdna • talk 08:55, 7 September 2008 (UTC)

If the filter is tested against the database of old edits, as you did above, I agree that not much is gained by testing it again against live edits, but please make the default setting for new filters as log-only for one day. Id see this as a guideline - highly recommended, but could be overridden in an emergency. Tim Vickers (talk) 15:02, 7 September 2008 (UTC)

After considering a bit more, it makes sense that this should be socially enforced, not technically enforced. The reason for this is that I can't think of a sensible way to have it operate as, inevitably, someone has to review the log after a filter's been run in log-only mode, and take responsibility for taking the filter live. The default setting has always been log-only, so presumably we can ask people to wait before they tick any other actions. Note that safeguards will kick in as necessary for extra-bad filters, if somebody's really messed up.

With that said, please make known here any objections to the above proposal, with the addition that abuse filter access will be a separate group, but one which sysops can add themselves to (and can be removed from if necessary). If there is no objection, I plan to go for a final review of the code in a few days, with a view to filing a bug asking for the extension to be enabled towards the end of the week. — Werdna • talk 09:56, 8 September 2008 (UTC)

OK, sounds good to me. Tim Vickers (talk) 19:17, 8 September 2008 (UTC)

I object to the presence of private information (the IP address). If necessary, a checkuser can check it; no reason for them to see all such info any time they happen to enter the log. Other users should see no such information. עוד מישהו Od Mishehu 07:15, 9 September 2008 (UTC)

Why? That information is already stored in revisions, which, unless oversighted, can be accessed by anyone. What makes this log so different? Celarnor ^{Talk to me} 07:58, 9 September 2008 (UTC)

The IP address for all edits (including logged-in) is stored in the Abuse Filter Log, for easy access. This is useful because if an edit is blocked by the filter, the IP address will still be available for debugging and/or targetting blocks. It's only accessible by people with the appropriate permissions (i.e. checkusers) — Werdna • talk 08:04, 9 September 2008 (UTC)

Still, this information is only available to them if they go looking for it, and the fact that they get it is logged for other checkusers to see. Here, if Alison (an arbitrary checkuser), for example, happens to check on a log entry which doesn't need to have an IP blocked, she will accidently see the IP address; and if Lar (name chosen due to the open checkuser case, this isn't an accusation against Lar for abusing the tool) checks on a specific log entry to find an IP address of a false positive (clearly unnecessary), no one else will know about. עוד מישהו Od Mishehu 09:49, 9 September 2008 (UTC)

Shrug. I thought it would be useful, especially since we're dealing (presumably) mostly with IPs which have made vandal edits. We could always leave it disabled until somebody asks for it. — Werdna • talk 10:16, 9 September 2008 (UTC)

Suggested filters - Sandbox

Perhaps beside the point at the moment, but could we have a filter disallowing the removal or editing of the header in the sandbox - perenially blanked. We could also set a character limit to avoid text dumps - how about it? ╟─Treasury§Tag►contribs─╢ 07:11, 9 September 2008 (UTC)

Could be done. — Werdna • talk 07:42, 9 September 2008 (UTC)

I realise that it's not the specific intention of the filter, but it is presumably easy-ish (says someone with little programming experience!) and would be the only way of "part-protecting" the page. ╟─Treasury§Tag►contribs─╢ 07:43, 9 September 2008 (UTC)

Whether or not it's the "specific intention" of this extension is irrelevant. Just like User:Lupin/badwords contains elements which would be part of newby tests, and not just vandalism, even though it's original purpose is to simplify the task of finding vandalism edits. עוד מישהו Od Mishehu 06:25, 10 September 2008 (UTC)

Admin-only discussion?

Surely restricting the modification of the filters to admins requires an admin-only discussion area? This couldn't be on IRC; not all admins go there. How would this work? ╟─Treasury§Tag►contribs─╢ 07:17, 9 September 2008 (UTC)

Most filters would be publically viewable. — Werdna • talk 07:19, 9 September 2008 (UTC)

(ec)But if some filters are hidden by admins (as I believe can be done!) then there would have to be a private discussion of these, wouldn't there? When do you anticipate filters being hidden? Note, I am in favour of the AbuseFilter, I'm just interested in ironing out the wrinkles. ╟─Treasury§Tag►contribs─╢ 07:24, 9 September 2008 (UTC)

One way it could work: Have a specific page set aside for the purpose. Keep it protected from creation by non-admins using the title blacklist. Any edit there should require copying the last deleted version + a reply (preferably in a single edit), and then delete the page. Gets a bit messy, but this is what can be currently done. עוד מישהו Od Mishehu 07:22, 9 September 2008 (UTC)

That's a really nasty way to do it. There is a notes section available for all filters, including hidden ones. Discussion would be best done there, by email or on IRC. Werdna 08:05, 9 September 2008 (UTC)

I oppose the activation of this filter unless all filters are viewable. Hidden anything usually becomes poison to the editing project. NonvocalScream (talk) 14:14, 9 September 2008 (UTC)

That is a bit of a cover all scream. I fail to see how hiding a pattern to detect grawp would poison the wiki, all it will do is prevent grawp from getting around it. You don't get to see all the source code for all the bots out there, this is just the same thing. You still get to see the actions themselves. Regardless I think this has already been discussed. Chillum 14:17, 9 September 2008 (UTC)

Perhaps, for a "hidden" filter, the patterns and counts should be blanked, but the general logic should be included. For example, for grawp, the relevant triggers should involve move to pattern, edit summary contains pattern, and .... whatever. (At least all the grawp actions on my watch list would be caught by such a rule, but I don't know the false positive rate for what I'd propose.) — Arthur Rubin (talk) 15:14, 9 September 2008 (UTC)

The title blacklist has driven him to use other sorts of titles, like Titleblacklist ruined everything and Wooormmzzz. We will probably need to discuss repeatedly how to modify the filter to match his newest technique. Our anti-vandalism bots usually won't revert the same thing twice, as a step against false positives; this abuse filter doesn't have such a trigger. עוד מישהו Od Mishehu 04:43, 10 September 2008 (UTC)

Notification texts

Are these in a localised MediaWiki page somewhere? Can they be changed? Some of them don't read particularly well. Neıl ☄ 09:52, 10 September 2008 (UTC)

Same for the block text. Is it tweakable? -- lucasbfr ^talk 11:46, 10 September 2008 (UTC)

Of course. In the meantime, do suggest changes here. I wrote them in something of a rush, while I was focussing on code, not users. — Werdna • talk 12:34, 10 September 2008 (UTC)

Logging sample

Please note that a live sample of the logging system is available at [12]. — Werdna • talk 13:35, 11 September 2008 (UTC)

Private data

Will the private data include IP information (for logged in users)? NonvocalScream (talk) 11:56, 11 September 2008 (UTC)

There seems to be no documentation on this point (the documentation on the whole seems pretty poor here), but from browsing the code, I gather that the private data section will be viewable by anyone with the 'abusefilter-private' permission. The only discussion I can find as to who would get that permission is here. I'm concerned that the extension developers are of the view that accessing IP information would not be logged; certainly the code does not appear to provide for any such logging. --bainer (talk) 12:32, 11 September 2008 (UTC)

It includes only the IP. I added it for completeness' sake. It's been discussed above, if you read the whole page, and my response was that we might give out that permission if it's wanted, after the extension is installed, but that it's not really very important. — Werdna • talk 13:05, 11 September 2008 (UTC)

I'm sorry, I scanned the discussion over I don't see it, I missed it. So, the extension is not capable of doing username to IP relation? NonvocalScream (talk) 14:40, 11 September 2008 (UTC)

Ok, I see now it's discussed above. Nevertheless, some explanation should be made on the proposal page to say that the private data will not be displayed, if that is what the proposal stands for, at least to counter the misleading effect of the screenshot. Further, I still think that the permissions ought to be documented too, along with the rules syntax. --bainer (talk) 15:54, 11 September 2008 (UTC)

• I see the discussion now, I need to slow down and actually read these things. It must be said that any USER <-> IP relations fall under the privacy policy and anyone having that permission would have to be identified to the foundation and aged 18 years. Additionally if this is the case, then who is granting this checkuser related permission? NonvocalScream (talk) 17:45, 11 September 2008 (UTC)

Permissions are tied to user groups. So if the 'abusefilter-private' permission were added to the 'checkuser' user group, then everyone who is a member of that group would have that permission. See mw:Manual:User rights. --bainer (talk) 00:21, 12 September 2008 (UTC)

Just want to be sure that the permission does not get assigned to a different group. Who can assign these permissions should as well be limited to those people whom are CU or can grant such access. NonvocalScream (talk) 01:29, 12 September 2008 (UTC)

On Blocking

Obviously this has become a bit of a big issue. I'm quite suprised, as it hasn't come up in the two months that the abuse filter has been under discussion. Nevertheless, it has to be addressed. Here are my thoughts:

1. Current blocks of bad users are clearly not sufficient. In the several seconds it takes to block a high-speed pagemove vandal, they can make numerous moves. With a few accounts, they can cause damage.
2. False positives will be exceptionally rare. I've done tests with real data, and found a 0.4% false positive rate – that's a 99.6% specificity rate, corresponding to four bad blocks per thousand – fewer than ten bad blocks per year. I think real admins make a lot more mistakes than that. Of course, this is dependent on the filter, but we are certainly within our rights to demand long-term trials of filters before we let them start blocking people.
3. If a user is blocked wrongly, anybody can find the entry in the abuse log, and check out what actually happened. It shows a full diff of the edit/move that was going to be done, and which filter matched it. If the edit was good, then we can unblock immediately.
4. On reputation / block logs: the Abuse Filter user clearly states that the reason that the user was blocked was because they matched an automated filter. It provides a description of the filter, and the block message itself can clearly point to a process for dealing with the rare false positives. I would imagine that anybody reading the block log, who could see that the user was unblocked, would not think any less of the user.
5. On duration: It is my preference that users are blocked until they are exonerated. This is for three reasons. The first is that the abuse filter is designed primarily to be autonomous. It rather defeats the purpose to require an administrator to confirm the block. Relatedly, the false positive rate is expected to be so low (see above, 0.4%, or fewer than 10 per year), that it would be a little silly to require thousands of blocks per year to be reconfirmed by an admin, just to save from the four or five that shouldn't be reconfirmed. It makes sense to do things the other way around. The third reason is related to reputation/block logs. It is far better to see an indefinite block which has been reversed with the summary "false positive", than to see a 15 minute block only.

I wonder if others will discuss these issues with me. — Werdna • talk 12:51, 11 September 2008 (UTC)

Also, if blocking proves to remain an issue, how many would be interested in enabling it without blocking, and just using the blockautopromote feature instead, which removes autoconfirmed from the account in question? Of course, this would not block the IP address, and might not be as effective, but it might allay some concerns (which I think are allayed by the above in any case). — Werdna • talk 13:09, 11 September 2008 (UTC)

I would like that much better. Maybe after a rule has been running for a couple of months and hasn't had any false positives, it could be set to block instead of de-autoconfirm. But I really think it's a bad idea to allow brand new rules, untested and untried, from people who may not fully understand what they're doing, to block people altogether. Daniel (talk) 13:26, 11 September 2008 (UTC)

Would it be possible to simply block the IP address, without actually revealing it like an autoblock? This would prevent the users from editing without leaving the block log message, which seems to be one of the main concerns. Of course an admin will still have to block the actual account in the next 24 hours and it complicates things if they're using proxies or can switch IPs easily. Mr.Z-man 16:05, 11 September 2008 (UTC)

With the side effect of confusing the hell out of newer editors for 24 hours who don't know how to navigate the block log and encouraging the use of proxies so people can do their editing. Celarnor ^{Talk to me} 16:19, 11 September 2008 (UTC)

Oh, it's even worse than that; the editor won't even be able to figure out that they've been blocked by examining the block log. They just ... can't edit, and won't know why. Celarnor ^{Talk to me} 16:20, 11 September 2008 (UTC)

Unless of course they read and follow the directions on MediaWiki:Autoblockedtext, which they'd see when they try to edit. Given a requirement that all filters must be done with a dry run initially and the low false positive rates in the proposed filters, the odds that a real "newer editor" would be affected by this would be very low, but this would reduce the concerns by some people about direct blocks. Mr.Z-man 18:07, 11 September 2008 (UTC)

But wouldn't that mean that no one can find out whether a user has been blocked or not? I don't think people worry about block log entries here, people worry about bots blocking people. --Conti|✉ 18:24, 11 September 2008 (UTC)

Presumably it would log it somewhere, who tripped the filter, so they can be blocked individually. I fully support the filter being able to just block directly, I'm just throwing this out as a possible alternative. Mr.Z-man 18:58, 11 September 2008 (UTC)

Well, if this feature will be able to block people, those blocks should be noted in the block log, IMHO. --Conti|✉ 20:39, 11 September 2008 (UTC)

I don't see any reason for them not to get a template and an entry in the block log. Being secretive and blocking a user without telling them why they were blocked, that they were blocked by an automated system that could be wrong, and where to go for help doesn't make any sense to me; I just don't understand why we would want to hide the fact that they were blocked and why. Celarnor ^{Talk to me} 21:50, 11 September 2008 (UTC)

Degrouping Admins

One, seemingly overlooked, feature of this Abuse Filter was the fact that it can desysop suspected compromised administrators without warning. Straw poll and more information please? NuclearWarfare ^{contact me}_{My work} 20:31, 11 September 2008 (UTC)

I don't see a problem with it. Either the desysop was warranted, or it can be undone by a bureaucrat. Maybe the bot-thingy should leave a note at WP:ANI whenever it desysops someone, tho, for immediate review of the desysop. --Conti|✉ 20:38, 11 September 2008 (UTC)

If implemented, I would also like to see it done for any users with more than a few thousand edits; odds are, if established editors are tripping our gestapobot, it's probably an accident. Celarnor ^{Talk to me} 21:54, 11 September 2008 (UTC)

That is what the "abusefilter-autopromote-blocked" would do. MBisanz ^talk 21:54, 11 September 2008 (UTC)

I thought that was for de-autoconfirmation. I haven't seen anything about posting probable false positives anywhere in the proposal. Celarnor ^{Talk to me} 21:57, 11 September 2008 (UTC)

Bear in mind that the current proposal is to release the abuse filter "...with the desysop functionality disabled for now". _TalkIslander 22:24, 11 September 2008 (UTC)

That's not what I was talking about; Werdna has been quite clear in a number of places that the desysop functionality will not be initially enabled; I was talking about the idea of posting to ANI whenever an established editor was blocked by the filter so it could be reviewed by a human. Celarnor ^{Talk to me} 06:26, 12 September 2008 (UTC)

I would sure want to see the script before letting a bot desysop. Chillum 23:31, 11 September 2008 (UTC)

Those who have read the discussion, or, indeed, the several lines of proposal which I put on the administrator's noticeboard, know that I do not currently propose to enable this functionality on Wikimedia. — Werdna • talk 05:31, 12 September 2008 (UTC)

Notice links

Perhaps I'm missing something, but wouldn't a subpage of WP:AN be the most logical choice? - jc37 12:03, 13 September 2008 (UTC)

For what? — Werdna • talk 14:24, 13 September 2008 (UTC)

Above you asked in several places about where someone wishing to contact an admin should go. Unless they are blocked, I was suggesting a subpage of AN. (If blocked, I believe that there is already a mailing list for that.) - jc37 08:31, 14 September 2008 (UTC)

Hmm, I was thinking Wikipedia:Abuse filter/False positives, and a {{af-false-positive}} template, or similar. — Werdna • talk 09:34, 14 September 2008 (UTC)

I don't have a major preference, but why set up a noticeboard in another location, instead of being part of the AN system? - jc37 09:38, 14 September 2008 (UTC)

It's not something that needs the attention of administrators, rather discussion of the abuse filter. I don't have much of a preference. — Werdna • talk 06:06, 15 September 2008 (UTC)

If administrators are the only people able to fix whatever broken filter is causing the problem then it very definitely needs their attention -- Gurch (talk) 10:15, 16 September 2008 (UTC)

Well, wherever it is, we can all agree that it should definitely exist and be very visible. I'm not about to get into an argument about where to put the page. — Werdna • talk 11:15, 16 September 2008 (UTC)

Notification texts

Let's create a consensus on these before the filter goes live, shall we? I'm going to change it around a bit; see you you think of it.

Message name	Message text
abusefilter-warning
abusefilter-disallowed
abusefilter-blocked-display
abusefilter-degrouped
abusefilter-autopromote-blocked
abusefilter-blocker	Abuse Filter
abusefilter-blockreason	Triggered an abuse filter rule. Description of rule: $1

Basically, we have to set up an easy system to contact administrators/bureaucrats. An irc channel would be a good idea to setup as well. Also, what's with the 5th message? It struck it for not making any sense. NuclearWarfare ^{contact me}_{My work} 23:34, 10 September 2008 (UTC)

Actually, it seems to me that when that abusefilter blocks a user, the account name is abusefilter-blocker, and the reported reason is abusefilter-blockreason. עוד מישהו Od Mishehu 12:16, 11 September 2008 (UTC)

For then ending of abusefilter-blocked-display should say something along the lines of "If this has occurred in error, please explain using the {{unblock}} template". עוד מישהו Od Mishehu 06:34, 11 September 2008 (UTC)

Could I tweak those messages into colored boxes? It seems like if it is just text, people might not realize they were the ones who did something wrong and just keep clicking. MBisanz ^talk 12:19, 11 September 2008 (UTC)

Go for it. — Werdna • talk 13:06, 11 September 2008 (UTC)

"... egregious or repeated unconstructive editing will result in your account or computer being blocked." - could I suggest a slight reword here to get rid of the word 'egregious'? It's not a particularly common word, and I feel it could easily be replaced with something slightly more basic. _TalkIslander 15:44, 11 September 2008 (UTC)

I use 'egregious' quite a bit. What would you propose to change it to? Celarnor ^{Talk to me} 15:48, 11 September 2008 (UTC)

Actually, in all honesty, I see no problem with just removing it: "Unconstructive edits will be quickly reverted, and repeated unconstructive editing will result in your account or computer being blocked". _TalkIslander 15:51, 11 September 2008 (UTC)

How about "... flagrant or repeated unconstructive editing"? Celarnor ^{Talk to me} 15:54, 11 September 2008 (UTC)

It's better than egregious... _TalkIslander 16:06, 11 September 2008 (UTC)

It should be more specific than just "unconstructive"; this isn't meant to deal with the entire spectrum of unconstructive edits, and we should aim to be as specific as possible when discussing the intended functions of the abuse filter; it is meant to be able to deal with two specific types of unconstructive editing: a) egregious unconstructive editing (i.e, GRAWP pagemoves) and b) repeated unconstructive editing (i.e, adding "AWESOME" to a page a few hundred times or something over a period of a week. This text should reflect that; I don't have a problem with 'flagrant' taking the place of 'egregious', but the idea needs to be communicated. Celarnor ^{Talk to me} 16:16, 11 September 2008 (UTC)

How would 'blatant' strike you? "... blatant or repeated unconstructive editing"? Because egregious is barely used in my 'circles', I'm struggling to find a good match - blatant is definitely a very good word to use, but I'm not entirely certain it conveys the same meaning... opinion? _TalkIslander 20:10, 11 September 2008 (UTC)

Meh, I guess; it doesn't really convey the same meaning; really, flagrant or egregious are pretty much the idea trying to go across; I guess if it turns out that people can't understand it...Celarnor ^{Talk to me} 23:25, 16 September 2008 (UTC)

Important before this goes live: We still need ways to easily contact administrators. NuclearWarfare ^{contact me}_{My work} 20:28, 11 September 2008 (UTC)

We have people's talk page to request unblock, the IRC unblock channel, the unblock mailing list, and if all else fails, going to meta and asking someone there to let us know they want the block reviewed. How many other ways exist? MBisanz ^talk 02:39, 12 September 2008 (UTC)

We need an easier way for newbies who get caught by this to easily find that information. Even just a link to a guide for requesting unblock would be fine. NuclearWarfare ^{contact me}_{My work} 03:24, 12 September 2008 (UTC)

Discussion: blocking or de-autoconfirming?

Above, Werdna indicated that an alternative to rules blocking people was to remove their autoconfirmed status instead. Wikipedia:Established_users#Autoconfirmed_users notes that "[a]utoconfirmed status is required to move pages, edit semi-protected pages, and upload files or upload a new version of an existing file".

Would everyone prefer this? It would both minimize concerns about biting new users accidentally (ie. new users who have made 10 edits and are therefore autoconfirmed) as well as alleviate concerns about established users getting blocked, as well as reduce the potential for abusive use of the AbuseFilter. The downside is that it will have no effect on IP's and non-autoconfirmed users/actions; this is mitigated by the fact that a lot of the things the AF is trying to combat requires an account to be autoconfirmed.

So, a quick straw poll sounds good, if only to gauge general opinions.

Prefer de-autoconfirmed, blocking OK

Prefer de-autoconfirmed, blocking deal-breaker

1. Daniel (talk) 06:01, 15 September 2008 (UTC)
2. Risker (talk) 06:26, 15 September 2008 (UTC)
3. If we're going to have it at all. --NE2 06:55, 15 September 2008 (UTC)
4. Too much potential for abuse of the tool; besides, it doesn't really need that ability anyway...Celarnor ^{Talk to me} 06:33, 15 September 2008 (UTC)
5. Davewild (talk) 17:38, 17 September 2008 (UTC)
6. RxS (talk) 22:36, 19 September 2008 (UTC) I agree with Celarnor above, I'm still not happy with the proposed process for adding/changing filters. Blocking is secondary as long as the edit is stopped and auto-confirm is removed.

Prefer blocking, de-autoconfirmed OK

1. — Werdna • talk 06:04, 15 September 2008 (UTC)
2. --Chris 08:22, 15 September 2008 (UTC)
3. עוד מישהו Od Mishehu 08:49, 15 September 2008 (UTC)
4. So if the user is doing something that doesn't require autoconfirmed, the tool can only hold them back until an admin gets around to it? That seems like a big loss of functionality. Mr.Z-man 16:18, 15 September 2008 (UTC)
5. MBisanz ^talk 17:56, 15 September 2008 (UTC)
6. - jc37 18:17, 15 September 2008 (UTC)
7. De-autoconfirm only won't prevent template vandalism. Cenarium ^Talk 01:49, 16 September 2008 (UTC) (clarification : only for rules with consensus for this rule to block, this implies that the rule should be made public Cenarium ^Talk 09:22, 17 September 2008 (UTC))

   But the filter will prevent an edit from being made in the first place. --NE2 02:17, 16 September 2008 (UTC)

   Filters may not work every time, they'll try to bypass it, and they still can vandalize classically, attack users, etc. The sooner an account is blocked, the lesser damages. They shouldn't be given too many occasions to "test" a filter, they may adapt. Cenarium ^Talk 02:38, 16 September 2008 (UTC)

   The sooner a bad account is blocked, the less damage. The sooner a good account is blocked, the more damage. --NE2 02:57, 16 September 2008 (UTC)

   And, keeping the assumption of good faith in mind, it is better to minimize damage to good accounts than to maximize damage to bad accounts. Celarnor ^{Talk to me} 04:53, 16 September 2008 (UTC)

   I agree that blocking a good user is a bad thing, but this happen by mistake occasionally, and a good filter should minimize the number of false positives below this level. This is why I propose that filters with blocking enabled be accessible only to developers. It would avoid badly written filters to go mad or potential abuse by admins. Also don't forget that we should assume good faith on the population of all users, but in the population of users having, say, saved to move a page to ... is stretched by Grawp's..., it is unreasonable to assume good faith. And this is the kind of users, continuing with the same example, that the anti-Grawp-move-filter will block. Do you think there's a non-negligible probability that someone move a page to something like ... is stretched by Grawp's... legitimately ? Cenarium ^Talk 12:04, 16 September 2008 (UTC)

   I'm going to assume good faith until I see evidence to the contrary. As the abuse filter will never have a zero percent false positive rate, the fact that someone tripped a filter means nothing in and of itself; what matters more is what they've done, and that needs to be looked at by people before anything like blocking is done. Celarnor ^{Talk to me} 21:00, 16 September 2008 (UTC)

   Isn't saving to move a page to something like ... is stretched by Grawp's... an evidence to the contrary ? It is my understanding that a block is issued when a user triggers a certain rule from the filter, we can allow blocks only on obvious rules like this one. I clarified this above. Cenarium ^Talk 09:22, 17 September 2008 (UTC)

   There were still false positives in the test run; that is, situations where the filter was wrong and it flagged a non-vandalism move as Grawp vandalism. The filter is not perfect; and its extremely unlikely they will ever be perfect. Celarnor ^{Talk to me} 23:12, 17 September 2008 (UTC)

   But it won't block, so it's not a problem, and it'll help to reduce the false positives. Cenarium ^Talk 08:59, 18 September 2008 (UTC)

   Had the test been an actual run of the filter, there would have been 4 blocks of innocent users per 1000. Did you read the test results? Celarnor ^{Talk to me} 18:03, 18 September 2008 (UTC)

   What about blocking 3000 bad users v. blocking 4 good users? — Werdna • talk 05:58, 16 September 2008 (UTC)

   One good user blocked by an automated process is one too many. It quite frankly scares me that a developer with the experience you have is putting forward a serious proposal with that sort of attitude -- Gurch (talk) 23:46, 18 September 2008 (UTC)

   I'd rather de-autoconfirm 3004 users who tripped a filter, whose status as good or bad can later be determined and acted upon by a human eye. Celarnor ^{Talk to me} 21:29, 16 September 2008 (UTC)

8. NawlinWiki (talk) 17:55, 16 September 2008 (UTC)
9. Stifle (talk) 14:08, 17 September 2008 (UTC)
10. Absolutely. I think blocking would be best, since no one who is a legitimate good-faith user will ever use the words "grawp" and "pwnt" in the same edit or action. However, if people won't just can't live with a computer program blocking people, I'd be willing to accept the filter merely de-autoconfirming the vandal. Something needs be done to fix the problem of page-move vandalism, and this seems to be the best thing that has been thought of so far. If the filter is not allowed to block people at this time, maybe after a few months with basically no false positives, we can revisit this, and perhaps people will allow the filter to block vandals. J.delanoy^gabs_adds 03:36, 20 September 2008 (UTC)
11. The way I see it; vandal tries to move a page --> the filter kicks in and deautoconfirms --> vandal instead starts vandalising pages. ~ User:Ameliorate! ^{(with the !) (talk)} 12:13, 20 September 2008 (UTC)
12. Seems fine to me. Oh yeah, signing. Protonk (talk) 04:23, 22 September 2008 (UTC)\

@Yep, fine. — Arthur Rubin (talk) 07:03, 22 September 2008 (UTC)

Comments

• I've split the 'de-autoconfirmed' section into blocking deal-breaker and blocking OK. I'm assuming there are none who support blocking who would object to de-autoconfirming. — Werdna • talk 06:04, 15 September 2008 (UTC)

• Won't it have an effect on things that don't require autoconfirmation, since it will prevent the edit from being made? --NE2 06:12, 15 September 2008 (UTC)

• I don't really see how this helps alleviate concerns about established users getting blocked, although I do see how it reduces the potential for the abusive use of the tool. It still acts based on the actions of established users; the tool still has to notify an administrator, and an administrator still has to undo the action, regardless of whether it's a block or a deautoconfirmation. Celarnor ^{Talk to me} 06:32, 15 September 2008 (UTC)
  • But a user who is deautoconfirmed can still edit while it's being reversed, and can actively seek it being reversed, and can participate in any discussion about the reversal. Daniel (talk) 06:41, 15 September 2008 (UTC)
    • That's true, I suppose, assuming ANI or whatever venue they need to seek that in remains unprotected. Celarnor ^{Talk to me} 06:53, 15 September 2008 (UTC)
• I suppose it's less severe than a block. I don't understand what you mean by "abusive use of the tool"; surely this tool is no more abusable than a regular block button. — Werdna • talk 06:42, 15 September 2008 (UTC)
  • Even if its only allowed to act to 5% of edits (how is that calculated, anyway; in real time, by the minute/hour/day/week, or is it some arbitrary number (edits/timeframe) determined by statistical analysis?), there's a lot of potential for abuse in a tool that isn't completely open to the community; it could perform automated actions based on regular expression searching of usernames that an admin doesn't like--perhaps a particular admin doesn't like liberals, so they block anything containing an instance of liberal, democrat, free, etc--, pattern searching of the name of that administrator in a sentence containing "disagree" to prevent anyone from voicing a negative opinion somewhere... the possibilities are endless. But this would restrict what they could do to the reduction of autoconfirm, and someone can fight against that; they can't fight against a block or an outright "No, you can't post that". Celarnor ^{Talk to me} 06:51, 15 September 2008 (UTC)
    • What's more, an editor engaged by such methods isn't able to identify the abuser, at least not directly; if someone were to block me, I could look at the block log and see who did it; other editors can look at the block log and see who did it. I can go on IRC and say "Hey, guys, this guy is being abusive, can someone post an ANI thread?". If someone uses an abusive filter, unless there's some kind of stamp or something based on who edited it last, there's no way for me to tell that. While I might know what's going on, it's different for someone who is new; they generally seem to be able to make the distinction between "X blocked me" and "Wikipedia blocked me"; but, in this case, it really would be "Wikipedia is blocking me, I guess I should just quit now". Celarnor ^{Talk to me} 06:59, 15 September 2008 (UTC)
• You're looking way way into the extreme case. A similar level of technical aptitude is required for this as with the title blacklist, or to write a block bot. The title blacklist is arguably worse, as there's no log of what it matches. It would still allow people to block new accounts with the names liberal or whatever. The filters, as stated previously, are primarily available to Wikipedians in general. Your argument that it could be used for abuse is an argument against any sort of control system available – the difference here is the granularity available in the filters, and it is my contention that the checks and balances here are more than sufficient for reducing abuse. If worst comes to worst, we can always desysop/ban admins who cause problems, but I would see this as extremely unlikely. — Werdna • talk 07:07, 15 September 2008 (UTC)
  • You're right, the title blacklist is worse, and I have no love for it; I oppose that deeply, but I don't think it's going anywhere anytime soon. Assuming that we give read access to 1,895 administrators, I'm going to be generous and say that 30% are going to have the innate scripting knowledge/experience or the will to the read the documentation and understand the filters themselves. In an objective world, the whole "summary of the filters" thing would work, but unless that summary is determined by some uber AI residing on the toolserver, they're going to be written by hand by the cabal of people creating/editing the filters, which could include members of the Arbitration Committee. There's simply no oversight by the community, no way to make sure that what's said is going on is really what's going on, short of amassing data and trying to reverse-engineer the filters based on the publicly-available portions of the logs and the relevant diffs; however, even that may be useless if the edits are stopped before revisions are made. Anything with that much secrecy has huge potential for abuse, especially when, as you say, a level of technical aptitude is required which further erodes away the number of people that are capable of reading a filter and saying "Wow, this is bad". Celarnor ^{Talk to me} 07:17, 15 September 2008 (UTC)
  • Besides, there's no reason for it to be blocking anyway; considering that the main use of this (at least for the time being) is to prevent massive page-move vandalism, and page movement can only be performed by those with the autoconfirmation bit, and that it's much worse for an innocent person to be blocked than to have autoconfirm removed, it only makes sense to me that, at least for now, it should remove autoconfirm rather than block, since it has no reason to take that action anyway. Celarnor ^{Talk to me} 07:20, 15 September 2008 (UTC)

We need to keep in mind what future uses of this may mean. For now we're dealing with a vandal who moves pages, but later we may find ourselves fighting some user who keeps running vandal bots which can vandalize hundreds of pages in the time it takes an admin to find the account (or even IP address!), decide it's vandalizing, and block it. If there's some clear pattern, then we can use the filter to force the account to stop. I think a 15 minute block is a good idea - gives the human beings some time to consider it and decide if it's justified, while preventing more damage from the account during that time. עוד מישהו Od Mishehu 08:49, 15 September 2008 (UTC)

Even in that instance, the filter can simply prevent the edit from being made; there's no need for an automated process to block them; human beings can still consider the block while the vandal bot continually gets bombarded with "Sorry, you can't make that edit." Circumstances are the same; this way, we don't have to deal with innocent, confused new editors who don't know what's going on. Celarnor ^{Talk to me} 15:19, 15 September 2008 (UTC)

A cabal of 1600 people chosen by the community? Its not like this is some self-selecting group operating using secret mailing lists. Everyone with access to the filters will be appointed by the community and will still have to abide by community written polices. If you're suggesting all the administrators including ArbCom are corrupted in the same way, this extension should be the least of your worries. Additionally, I can't imagine it would be difficult to add an additional log for changes to filters, if one doesn't exist already (I haven't gotten around to testing it yet). Mr.Z-man 22:51, 15 September 2008 (UTC)

Is it possible to make certain filters and options accessible only to developers ? For example, a developer access is necessary to allow a filter to block or de-adminship, but any filter can de-autoconfirm, warn, disallow, report, etc. This would prevent abusively or badly written filters to issue blocks. Cenarium ^Talk 02:02, 16 September 2008 (UTC)

I highly doubt that all 1600 administrators are going to be actively involved in the process; but, yes, if that were the case, it would a cabal of 1600 users who had trust placed in them by the community in a previous, much less stasi version of Wikipedia where adminship used to be viewed as no big deal and would be given to anyone who wasn't a dick, who now access to secret routines and heuristics that go completely unchecked by the community; there's not even a special board of non-administrative trusted users who can view the filters to make sure that they are functioning as claimed by the authors in a description of the filters that isn't derived from any objective analysis but summarized by the authors of the filters themselves. Still, I don't think that's going to be the case; I doubt even half that number will have anything to do with it; I'd be surprised if 20% were actively engaged.

It isn't so much that those we choose in the future won't be problematic; with the community having the knowledge that anyone with administrative access can cause more damage faster than they could ever do so before, I think it's going to be a higher bar to get into the administrative caste, which makes sense. I'm more worried about those who already have the bit, especially since there's no regular reconfirmation of existing admins, who might be worthy of the trust that must be previously vested in an administrator, but isn't quite worthy of that now that there's a way to undermine the existing logging system and use un-monitorable filters to prevent their actions from being noticed or linked to them. Celarnor ^{Talk to me} 04:52, 16 September 2008 (UTC)

So we should assume good faith, except when it comes to admins, where we assume they're all conspiring together to accomplish some unknown goal that's contrary to the goals of Wikipedia? How would a board of trusted non-admins (which would presumably have to be chosen through some sort of election-like process) be any different than admins chosen through RFA? Mr.Z-man 13:14, 16 September 2008 (UTC)

Because...they're not admins, don't have any tools other than the ability to read filters, and could verify the functions of the filters for those outside of the administrative caste? It's an entirely different level of trust based on an entirely different function, I don't see how the two are remotely similar, outside of both of them being in a higher caste than regular editors. Celarnor ^{Talk to me} 21:07, 16 September 2008 (UTC)

With an exception towards developers, who go through an extremely rigorous process, my good faith is an exponential function that scales inversely to the amount of rights you have and the amount of time has passed since the community last evaluated your possession of said rights. Celarnor ^{Talk to me} 21:18, 16 September 2008 (UTC)

I still fail to see the difference. You seem to be assuming that every admin looks down on non-admins, or something. That getting the tools automatically changes people for the worst or that all admins are conspiring together toward some unknown goal (I must not have gotten that memo). Why does the assumption of good faith stop once someone passes RFA? If anything, getting onto the "non-admin abuse filter review committee" would involve less trust than we require for admins, bureacrats, and especially ArbCom. How is a group full of people who aren't trusted enough to be admins somehow more trustworthy than admins and arbcom? Also, how would you define "developers?" Mr.Z-man 21:27, 16 September 2008 (UTC)

No, getting the tools just makes you an extremely powerful user with an increasingly large number of abilities; by its very nature, power is a very dangerous thing, and anyone in possession of such power needs to be closely monitored, and having a system where you can take administrative actions in such a way that only other administrators can identify you as the one who performed them, making everything secret and invisible to non-admins is not the way to go about that. Regarding the other point, having it as less trust would be kind of the whole point. Less trust means more people can see the filters, means less potential for abuse. For my purposes, I define developers as people with shell access; however, I'm not entirely opposed to those with commit rights on SVN being excluded, if we're talking about using them for filters with blocking capability; there aren't a lot of people with shell access, after all... Celarnor ^{Talk to me} 21:35, 16 September 2008 (UTC)

Would restricting the ability to enable blocking filters to developers reduce those concerns ? Please see my comments above. Cenarium ^Talk 14:05, 16 September 2008 (UTC)

I wouldn't be opposed to that; although, editing them should also be restricted to developers, for obvious reasons. Celarnor ^{Talk to me} 21:07, 16 September 2008 (UTC)

Yes, a developer access would be necessary to modify a rule with blocking enabled. Cenarium ^Talk 09:22, 17 September 2008 (UTC)

The filters are absolutely not "unmonitorable". While some of the filters themselves will be restricted to viewing by administrators, every edit matched is detailed in the abuse log. — Werdna • talk 12:27, 16 September 2008 (UTC)

I can't see the details of the log; other people can't see it. Only the administrative caste can see it. Celarnor ^{Talk to me} 21:07, 16 September 2008 (UTC)

They are unmonitorable by us mere mortals. If this goes live, I've half a mind to request adminship purely so I can view the filters and copy them to somewhere viewable by everyone -- Gurch (talk) 12:33, 16 September 2008 (UTC)

I was thinking the same thing, actually; I wonder if anyone's going to go to RfA to patrol the filters...Celarnor ^{Talk to me} 21:41, 16 September 2008 (UTC)

It's not all filters either, it's an option. And while you can't look at the filters themselves, you can observe their effects. — Werdna • talk 12:36, 16 September 2008 (UTC)

There's a difference between what we want a filter to do, which should and will be the community's decision, and the code which implements this. There's no necessity to make the entire code of a live filter public and it has an obvious disadvantage. A filter is like a shield, giving out the codes is too risky. For the sake of transparency, it is possible to give out only certain rules of a filter, or old versions. Cenarium ^Talk 13:56, 16 September 2008 (UTC)

Really? The entirety of MediaWiki is open-source, as are most tools and bots. The Wikimedia projects are run almost entirely on open-source software. I find it hard to believe that this filter is the single place across all projects where this principle is to be suspended. -- Gurch (talk) 16:09, 16 September 2008 (UTC)

Why is there a difference between what we want a filter to do and the code which implements it? There shouldn't be, really, and if there is, then there's a problem. How are older versions and "certain rules", no doubt released by the author of the filter, useful in ensuring that a current filter isn't abusive; what's to prevent the author from releasing rules to which the community wouldn't object to, then simply not release the more abusive methods? What measures does the community have to analyze a filter's function outside of tedious reverse-engineering and data analysis? Celarnor ^{Talk to me} 21:07, 16 September 2008 (UTC)

Great. So, to verify that a filter is functioning properly, we have to reverse-engineer it based on a watered-down version of its log. I'm looking forward to this already. Celarnor ^{Talk to me} 21:10, 16 September 2008 (UTC)

"Really? The entirety of MediaWiki is open-source, as are most tools and bots. The Wikimedia projects are run almost entirely on open-source software. I find it hard to believe that this filter is the single place across all projects where this principle is to be suspended."

Not strictly true. We already run automated spam filters against all edits, which aren't public. — Werdna • talk 08:51, 17 September 2008 (UTC)

You mean the hidden "do not fill this in" field on the edit form (because people not using CSS don't matter)? -- Gurch (talk) 18:19, 17 September 2008 (UTC)

I didn't know about that, but if it is as gurch describes, then that hardly compares. Distinguishing between an actual browser and someone using a perl script or something who spoofed their user agent string and inserts spamlinks in articles via mutating URLs is hardly what this is. Celarnor ^{Talk to me} 18:38, 17 September 2008 (UTC)

We have certain restricted pages, like special:unwatchedpages (so that vandals cannot exploit this sensitive information). If the purpose of giving our source codes is to help other wikis and the research on wikis, then giving out old codes will serve this purpose, while we won't strand sensitive information. This is a compromise. Cenarium ^Talk 08:59, 18 September 2008 (UTC)

Special:UnwatchedPages is pointless. I don't think anyone has ever actually used it for anything useful -- Gurch (talk) 16:07, 18 September 2008 (UTC)

I was wondering the same... Cenarium ^Talk 16:16, 18 September 2008 (UTC)

UnwatchedPages doesn't have the ability to remove your ability to edit. Celarnor ^{Talk to me} 18:05, 18 September 2008 (UTC)

(unindent) Werdna's correct. http://noc.wikimedia.org/conf/ has the configuration files for Wikimedia, but certain variables are not public. And the "do not fill this in" field is to help prevent spam bots. (In this day and age, if you're not using CSS, 90% of the web is already screwed up for you, anyway....) --MZMcBride (talk) 23:53, 18 September 2008 (UTC)

Yeah, but Wikipedia's supposed to be in that 10% of sites that care about their content more than how much revenue they're generating, and thus actually goes out of its way to be accessible -- Gurch (talk) 23:58, 18 September 2008 (UTC)

Like all things in life, it's a balance. You could certainly file a bug to have mw:Extension:SimpleAntiSpam disabled on WMF wikis, but our quasi-obsession with making sure that Netscape 3 and IE 5 for Mac display every page perfectly is a bit irksome at times. --MZMcBride (talk) 00:01, 19 September 2008 (UTC)

But their users are important to us! Yes, both of them! :) -- Gurch (talk) 00:03, 19 September 2008 (UTC)

I'm referring to Extension:AntiBot.

AntiBot is a simple framework for spambot checks and trigger payloads. The aim is to allow for private development and limited collaboration on filters for common spam tools such as XRumer. (XRumer is actively maintained to keep up to date with the latest antispam measures in forum, blog and wiki software. I don't want to make it easy for them by giving them our source code.)

See anything you recognise from above? We're being even more lenient. Some filters, which are judged to be improved by secrecy, will be hidden, but accessible to administrators. Furthermore, we'll actually tell people what aspect of their behaviour we're targetting. — Werdna • talk 05:48, 19 September 2008 (UTC)

Test run

There are still issues under discussion, but I think it would be worthwhile to run a filter with limited functionalities and with filter access (view/modify a filter) limited to developers. Since blocking is an issue, it shouldn't block but only report to AVI or in another appropriate place. We still don't have a consensus on whether filters should be public, so we should leave this to discussion. The anti-page-move-vandalism filter seems to be the most appropriate choice for a test (and the demand is there, almost 300 bad moves today). The basic Special:AbuseLog would be visible to anyone, and details like diffs to administrators. Is it possible from a technical point of view ? Cenarium ^Talk 17:30, 16 September 2008 (UTC)

Making certain actions available only to certain users would be a bit annoying from a technical perspective? — Werdna • talk 08:53, 17 September 2008 (UTC)

I don't think it would be. I meant, is it possible to run the abuse filter this way in only a few days from now, or is it going to take several weeks to implement ? Since the community is divided on blocking and transparency, we shouldn't expect to fully implement this before some times. But I don't think a test of this sort would raise much opposition, and I suppose we can implement new features progressively. Cenarium ^Talk 09:14, 17 September 2008 (UTC)

There wasn't supposed to be a question-mark there. By my count, the support for enabling it without blocking runs above 85%. With blocking, down to 76%-ish. — Werdna • talk 10:28, 17 September 2008 (UTC)

If it helps, count me as 100 people -- Gurch (talk) 18:16, 17 September 2008 (UTC)

• Just do it, same way as rollback. Stifle (talk) 14:10, 17 September 2008 (UTC)
  • So, discuss it for another month, implement it after several sitewide polls, then run around screaming for a week? Mr.Z-man 23:28, 17 September 2008 (UTC)

According to the poll at the top of the page, the bot has not yet gained consensus in general, a test run cannot be executed untill such a time as a clear cut consensus is established to turn it on in the first place. Prom3th3an (talk) 01:09, 18 September 2008 (UTC)

No consensus in general, especially with blocks enabled indeed. But oppositions are raised based on blocking, administrators being able to modify source codes and release of the source codes. The latter, we can't act upon yet and is left to discussion. For the former, we can run the abuse filter with blocking disabled. For the concern on admins modifying filters, I proposed that filters be only modifiable by developers for the time being. But admins should be able to see them to reduce secrecy and allow discussion with devs. Cenarium ^Talk 09:28, 18 September 2008 (UTC)

I generally support this extension, although I certainly understand the concerns about false positives & potential for misuse of the filter list.

• In terms of false positives, it might help to allay fears if we have a test run, where the extension is installed & reports hits/positives rather than acting on them. A firm support from me would only come after seeing the results of such a test run.
• In terms of abuse; I think it's important to Assume Good Faith on the part of our developers & admins, who have shown they have the best interests of the project in mind. It should also be made clear that bad faith use of the filter list will have effects on one's user rights which are akin to those experienced in the past by admins who have intentionally deleted the main page & blocked Jimbo. Why not assume good faith on the part of all users instead? Because AGF isn't a suicide pact, we've seen that moronic trolls can disrupt the project - taking minimally invasive measures to stop them reduces the disruption for everyone. --Versageek 16:19, 22 September 2008 (UTC)

Vote (moved from WP:AN)

• No objections to this since the only controversial issue, automated desysopping, has been dropped. Stifle (talk) 11:53, 9 September 2008 (UTC)
• Support. Nothing wrong with blocking Grawp. If the thing screws up (rare) we can leave a note in the block log saying so. Giggy (talk) 11:57, 9 September 2008 (UTC)
• Oppose I will stuff BEANS up it's nose. —Preceding unsigned comment added by 86.165.38.72 (talk) 12:18, 9 September 2008 (UTC)

Well, you will when your block expires. _Gb^T/c 12:36, 9 September 2008 (UTC)

• I support this, obviously. Let's try not to hit the fan with it, though :) -- lucasbfr ^talk 13:30, 9 September 2008 (UTC)
• Support this seems to be an excellent feature of the MediaWiki that will bring a very large net positive to the project. I mean, who can complain about 1-2 mistakes PER YEAR just with the filter generated. Even if it messed up one in every7 ten blocks (yes, that would be annoying) it would still have a huge net positive to the project. — ^.^ ^{[citation needed]} 14:06, 9 September 2008 (UTC)
• woo-hoo! Let's see it in action. Guy (Help!) 14:54, 9 September 2008 (UTC)
• Support, given that we start with basic filters to make sure this isn't going to crash the wiki. I know you've tested this already, Werdna, but we're a good deal bigger than your average test wiki, and we've got the added issue of possible dramaz, something which can't be debugged. Hersfold ^(t/a/c) 16:32, 9 September 2008 (UTC)
• Support this is clearly necessary, is a net benefit to the project and there are safeguards in place. Hut 8.5 17:41, 9 September 2008 (UTC)
• As long as there are strong restrictions on who can create and edit filters, I don't have any objections. --Carnildo (talk) 18:58, 9 September 2008 (UTC)
• Support. Please let us know where the logs are.... — Arthur Rubin (talk) 19:06, 9 September 2008 (UTC)
• Barnstar for Werdna support This is an excellent piece of news. Hersfold makes a good point, though I imagine Werdna has considered it, and if he hasn't Brion will... Sam Korn ^(smoddy) 19:12, 9 September 2008 (UTC)
• Support Although I wish it had a feature to that came to your house and smashed your computer if you vandalized. MBisanz ^talk 19:14, 9 September 2008 (UTC)
• Object Unless all filters are made public. NonvocalScream (talk) 20:02, 9 September 2008 (UTC)
  • Making the filter rules public would allow smart abusers to design new attacks to avoid them. Is there some specific concern you have? Thatcher 21:31, 9 September 2008 (UTC)

Let us not be lazy, if they abuse - we block them. Remember our statement of principles bank in '01? Regarding open algorithms? This still holds. I think the idea of closed algorithms goes against us, as a matter of project principle. NonvocalScream (talk) 01:11, 10 September 2008 (UTC)

Well that'd defeat the purpose. As long as "secret" rules don't become the norm, I have no objections from having the "xx edits on userspace followed by yy moves" kind of rules hidden from public view (if admins can see the rules and the log is clear on which rule was triggered). -- lucasbfr ^talk 12:10, 10 September 2008 (UTC)

Hidden filters - logs - I don't like it. I oppose it. NonvocalScream (talk) 02:25, 11 September 2008 (UTC)

• • Presumably if someone has any serious issues then can post saying "Hey! I'm trying to do X and I can't." JoshuaZ (talk) 21:45, 9 September 2008 (UTC)
• Has my support. Impressive work by Werdna. Angus McLellan (Talk) 00:13, 10 September 2008 (UTC)
• Very strong oppose in principle to performing blocks or other admin actions by any sort of automated process. I know the intentions are good, but experience with bots shows that they tend to degenerate. The proposed blocks should be written to a log for human review. DGG (talk) 00:49, 10 September 2008 (UTC)
• Oppose per DGG. Admin actions should be performed by admins, not by a bot. I have no objection to bots being developed and used which assist admins, for example by identifying possibly problematic edits, but a bot running according to rules which cannot be scrutinized by the community is in no way suitable for performing admin actions. DuncanHill (talk) 00:55, 10 September 2008 (UTC)
• Support per my comments on the project talk page. Mr.Z-man 01:05, 10 September 2008 (UTC)
• Strong oppose Obama is a Muslim and will take away our guns Support, of course. Great concept, great work, erroneous blocks can be undone. user:Everyme 01:10, 10 September 2008 (UTC)

• Even stronger support iff Kww's suggestion for only short-term automated blocks is implemented. user:Everyme 12:44, 11 September 2008 (UTC)

• This has my complete support. Assuming we have a false positive, we can always unblock. Blocks are harmless and fully reversible. ^demon^{[omg plz]} 01:15, 10 September 2008 (UTC)
• It's about time. Let's do this already! SQL^{Query me!} 01:37, 10 September 2008 (UTC)
• When was a straw poll called for? Oh well, support as long as it doesn't do anything particularly "crude and drama-inducing", like Daniel said above. Calvin 1998 ^(t·c) 01:53, 10 September 2008 (UTC)
• Careful logging required, and a course of response for people who show up as false positives (collateral damage), and people standing by to provide prompt action on such responses. --Kim Bruning (talk) 01:55, 10 September 2008 (UTC)
• Neutral, leaning towards paranoia. Conservatively designed filters by Werdna may be OK, but when AF will be released to the wild, EACH AND EVERY change made by people who are unable to make a dry run on a full DB dump will cause the filter to degrade. I find it quite possible that ruining everything may be quite easy. MaxSem^{(Han shot first!)} 09:13, 10 September 2008 (UTC)

I hope the people will take great care before creating/tweaking any aggressive filter (I, for ex won't touch it since I am quite sure I would break something). I hope repeated screw ups will be severely admonished (or more). -- lucasbfr ^talk 11:45, 10 September 2008 (UTC)

• Conditional Support Non-aggressive filters are a must. There's been a reasonable number of people who've got caught up inadvertently by the title blacklist, so it must be less aggressive than this. Brilliantine (talk) 09:18, 10 September 2008 (UTC)
• I agree with MaxSem. I'm worried about the ability of people to write the complex-ish code required to run this thing. I'm unaware of the status of a JS tool to make writing code for this simpler (and less error-prone), but I still see it as a must-have before this goes live. --MZMcBride (talk) 09:34, 10 September 2008 (UTC)
• Support. I don't see why this wouldn't be handled carefully and responsibly. Fut.Perf. ☼ 09:40, 10 September 2008 (UTC)
• Support once the word "egregious" is changed in the localisation file to "obviously bad", or something similar, which is what it means, and which is less likely to confuse people - not everyone knows all the big words. Particularly as "egregious and unconstructive" is a tautology. Neıl ☄ 09:52, 10 September 2008 (UTC)
• Support. To those calling for the heuristics to be released, do you really need to look at the filter to know that moving WP:AN to WP:AN ON WHEELS will get you blocked, abuse filter or not? shoy (reactions) 14:33, 10 September 2008 (UTC)

You make the false assumption that only filters of that nature will be installed, which isn't necessarily true. There's nothing to prevent the filter-modify cabal from making a filter containing a regular expression that searches for sentences containing "(list_of_filter-modify_cabal)", "disagree" and "with" and calling it something completely unrelated to its actual function; since the community can't watch them, you have to place a LOT of trust into this cabal to not abuse their privileges. Celarnor ^{Talk to me} 16:01, 11 September 2008 (UTC)

• The idea that "proposed blocks should be written to a log for human review" would be rather helpful, and I'd prefer that. However, given that steps can be taken to remove the extension promptly if things get out of hand, I see no reason not to Support. Ncmvocalist (talk) 17:40, 10 September 2008 (UTC)
• Strong oppose. Bots shouldn't block people, period. The bot could make a list of problem users and individual admins could review the list and use their own human discretion. If this does get implemented, however, at a minimum, the bot should be required to list all blocks it has performed so that they can be easily reviewed. Corvus cornix_talk 19:27, 10 September 2008 (UTC)
• Oppose Blocks that a bot can do can be done with little effort by humans - decisions by humans based on balancing Good Faith interpretations of edits cannot be done by bots. Being blocked is chilling, and undoing that mistake does not bring that editor back. LessHeard vanU (talk) 20:58, 10 September 2008 (UTC)
• Conditional support—whereas it is given that the abuse filter extension without any filters has no effect, and a condition that all rules to be applied have a negligible false positive rate is used, and a condition that all rules are to be tested against historical changes for error rate before implementation, I find the addition of this functionality to be acceptable. I would find it most acceptable were an initial "dry run" made first: the first filters to be implemented should not block those who trip them. Also, blocking is not necessary for most filters: a filter that simply disallows moves to clear Grawp sockpuppets would be enough to largely nullify them, to be then manually blocked by our more-obviously trustworthy human administrators. {{Nihiltres|talk|log}} 02:05, 11 September 2008 (UTC)
• Oppose No blocks by bots. The many-wending ways of human editors are still beyond the ken of any script, to put it lightly. Otherwise I'd support: A bot spewing out diffs and usernames which might be blocked, after having been looked over by flesh-and-blood-ware, is another tale. This said, I have no worries about a bot automatically disallowing an account's pagemove or template space edits, or throttling. Lastly, I trust Werdna's skills and outlloook, but how can we know a Werdna (or someone like SQL) would always be watching this? Gwen Gale (talk) 02:14, 11 September 2008 (UTC)
• Oppose. It's too easy for software to misfire even after extensive testing, that happens even with the most widely used programs. Let the bot generate a list for high-priority admin review. Remember Sarah Conner - don't give control to Skynet! That's a joke of course, but a malfunctioning blocking-bot could affect many users and cause serious disruption. For example, what if the malfunction came during sensitive discussions on AN/I or RFAR, preventing a user from a timely response? However, as Gwen Gale noted, it's no problem if the bot is empowered to stop page moves or template edits, though if so, there should be an expedited page for reporting misfires. --Jack-A-Roe (talk) 02:39, 11 September 2008 (UTC)
• Oppose. I very much admire the work that Werdna has done here; however, I agree with DGG and Gwen Gale and LessHeard vanU. Blocks need to be made by humans who bear responsibility for their actions. I could live with prevention of page moves or template edits based on certain algorithms; however, those functionalities should remain open to the majority of our editors. Risker (talk) 02:46, 11 September 2008 (UTC)
• Oppose.Support This false positive rate of 1-2 year makes me more happy.Instead of just blocking, could this just fire off a report to an irc channel? I think that would solve most of the objections that people are raising. NuclearWarfare ^{contact me}_{My work} 03:03, 11 September 2008 (UTC)

We've had that for some time now, it hasn't reduced the amount of vandalism or made cleanup easier in any significant way. Response time is slightly faster. It still requires admins to do all the cleanup. Mr.Z-man 04:16, 11 September 2008 (UTC)

::Comment: I have noted that the false positive rate is around 0.2% currently, or one a week, as Werdna said. Is there a way to doing this so that instead of blocking people with flagged edits, their edit is placed in a limbo mode and a notice in an irc channel is opened for another administrator to review? NuclearWarfare ^{contact me}_{My work} 03:26, 11 September 2008 (UTC)

Note that for the rule Werdna described above, the false positive rate is 2-3 per year. Mr.Z-man 04:18, 11 September 2008 (UTC)

• Support. Great idea. Jayjg ^(talk) 04:00, 11 September 2008 (UTC)
• Great idea - this is the kind of thing we should be using technology to do. Kinks can be worked out, but anything that automates and potentially reduces the workload from fixing mass vandalism is a good thing. We shouldn't let perfect be the enemy of good enough. There are always going to be issues or "it would be nice if we could do xyz", but we shouldn't let that stop us from taking a step that would be a strong net positive. --B (talk) 04:06, 11 September 2008 (UTC)
• Possible compromise for the block haters In general, I support the filter. As a compromise with the people that dislike blocking, we could limit the blocks to a very short period, say 15 minutes, and have the filter send off an IRC or fill out a noticeboard. That way, a human has to decide to extend the block to any meaningful period, but the serial vandalism sprees still get nipped in the bud. I talked about this with DGG, and he gave it full support.Kww (talk) 04:40, 11 September 2008 (UTC)

  This doesn't make much sense to me. Isn't an indef block which is reversed by an admin within minutes better than a 15-minute block? — Werdna • talk 11:20, 11 September 2008 (UTC)

  Not at all, assuming you make it clear that the 15 minute block is merely a temporary measure until a sysop reviews the case. Why in your opinion is a quickly-reverted indef block any better? (I hasten to add that I'm not being critical - I think the work you've done is excellent - just want to hear your reasoning on this). _TalkIslander 11:28, 11 September 2008 (UTC)

  Well, for starters, 99.6% of blocks made by the extension (that's a real figure, by the way), will be on real pagemove vandals. Why would we make admins re-place those blocks when it's clear that they should stick? Obviously, a 15-minute block may not be actually removed by the time we've decided to remove it, and then, from a psychological perspective, the block log doesn't include a record that the block by the abuse filter was actually overturned. I would much rather have an indef block, then an unblock with the reason "Filter false positive", than a 15-minute block, without any clear evidence of an unblock. I realise that the absence of a subsequent block may hint at the idea that the block wasn't left standing, but if I were concerned with such things, I would still rather a confirming unblock in my block log. — Werdna • talk 12:41, 11 September 2008 (UTC)

  Give people time. If the percentages work out as well as you believe with everyone watching, consensus will change to do it the way you suggest. This lets you get real field time with everyone watching, and keeps the people that fear Starnet from being too wary to let you proceed at all.Kww (talk) 13:36, 11 September 2008 (UTC)

• Strong Support --Chris 09:31, 11 September 2008 (UTC)
• Support. Even tho not every of them is successful, there can be no evolution if we never try new things. DarkoNeko x 09:33, 11 September 2008 (UTC)
• Oppose bot blocking of registered accounts. If they are done they should be short term as above and clearly indicated as purerly preventive measures without any actual implication ony the editors behavior. Naive question (I haven't thought abut this much). Can we inverse usual blocking logic and have the rules rather trigger solely the autoblock and then have an admin follow-up with the accounts using it assuring in some way, that the account to be revived isn't immediately connected to the IP adress?--Tikiwont (talk) 10:01, 11 September 2008 (UTC)

  I have difficulty parsing your suggestion. — Werdna • talk 12:53, 11 September 2008 (UTC)

  Well i was thinking admittedly aloud, mostly in the line of the rules based engine preventing harm without directly blocking user accounts. So would it be possible that the engine only blocks the IP access, including the case when the IP is sued by a registered account (the page mentions those used in the last seven days). This way abusive editing would be stopped immediately, but the user initially only sees a message related to the IP as for an autoblock. Meanwhile (I understand roughly 24 hours) an admin can review the user pattern itself and impose an account block.--Tikiwont (talk) 08:44, 12 September 2008 (UTC)

  How is that better than an account block? Not to mention it'd expose the user's IP (privacy policy, anybody?) — Werdna • talk 14:25, 12 September 2008 (UTC)

  Well I am concerned about privacy as well and mentioned it or tried to in my initial post. Technically i may not knowledgeable enough to understand if these can be actually separated or why this would not be a concern the other way round. I would therefore appreciate if you could simply assume a different and maybe less technological mindset of others before even hinting that they aren't concerned about privacy. I actually appreciate your work and the diligence in following up on feedback.

  A motive for staring with the IP block would be that it doesn't make any difference for a positive, but if a wrong block results form some pattern, the editor in question would just see that they currently don't have access. Unless thy are subsequently blocked on the sole basis of their edit pattern as registered user or ask themselves for undoing of the autoblock, they are simply not able to edit but without personal block entry. But maybe this is not the place or time to explore a completely different schemes.

  If we stick to the current scheme, I wouldn't have the same high confidence as others but I also think that a neutrally communicated and swiftly removed wrong block wouldn't necessarily drive an editor wary. It is human interaction that counts and a wrong block by an admin can do the trick as well. --Tikiwont (talk) 15:08, 12 September 2008 (UTC)

  My error, I thought you were suggesting that we have users give their IP address to admins if they hit the filter; which would have negative privacy implications. I see your main concern is in the placing of a block log entry. Block log entries are essential, because they give a paper trail for what was done. A block log entry with a subsequent unblock is probably no big deal to most people (I think, anyway). A block which doesn't appear in the block log is just plain confusing, as well as kinda sneaky.. — Werdna • talk 15:14, 12 September 2008 (UTC)

  Thanks for clarifying. For the logs, I assumed that the IP blocks are logged as if they were autoblocks or range blocks, just not immediately on the account. In any case it might be better to stick now to evaluating the current proposal, and my oppose is now rather a weak one. It seems there is consensus heads to implement it and if there are problems we can still investigate alternatives further. --Tikiwont (talk) 09:17, 13 September 2008 (UTC)

• Strong support provided that Kww's frankly excellent suggestion above is implemented. Otherwise weak support. Why weak support? In all honesty, I think the benefits that this extension will bring outweighs (just) the problems caused by incorrect blocks - hence my support becomes strong if Kww's suggestion is implemented. This assumes that the desysop feature is disabled - I could not support at all in that case. _TalkIslander 11:03, 11 September 2008 (UTC)
• Support anything to stop my watchlist filling up with redlink grawp crap. Darrenhusted (talk) 11:11, 11 September 2008 (UTC)
• Support Shows promise in controlling spammers who manage to evade the blacklists, in addition to other P....R....O....B....L....E....M....S. I hate move-warring with vandals waiting for the admins to arrive. MER-C 11:55, 11 September 2008 (UTC)
• I dunno. On the one hand, this idea sounds pretty good, and I can live with a dozen or so false-positives a year. On the other hand, some admins seem to prefer to block as many vandals as possible, regardless of false-positives, so I'm worried if we'll still have just a dozen false blocks once the abuse filters will be implemented and editable by admins. --Conti|✉ 13:34, 11 September 2008 (UTC)
• Neutral. It's only a single detail, but I can't give my support as long as it's possible to create filters that aren't viewable by everyone. We have too much secrecy already with existing checkuser and oversight procedures, we don't need any more. Other than that, it looks like all my initial arguments against this have been addressed, and it should be a useful tool if used carefully. —Simetrical (talk • contribs) 15:14, 11 September 2008 (UTC)
• Weak support; I'm not a particularly big fan of not having the filters completely viewable by the public (especially, as the above notes, when we already have a number of "Secret Police"-esque systems in place such as checkuser and oversight), but given the simplicity of the filters that would be used, tweaking your edits in such a way as to evade the filters would be a relatively trivial manner. Provided that public consensus is sufficient to modify or remove a filter that we don't like, and that what data provided to the public is sufficient as to infer the functions of a given filter, then I don't really have a problem with it. It should be noted, however, that this system is very cabalistic by nature, and excluding consensus and the community would be very easy to accomplish; when/if that happens, I'm quite worried about the implications. Celarnor ^{Talk to me} 15:40, 11 September 2008 (UTC)
• Strong support Many (if not all) of the concerns addressed have already been resolved in last few revisions of the code, and frankly, we need this. Kylu (talk) 05:44, 12 September 2008 (UTC)
• Support. A lot of work has been put into this to make sure it works properly, and I'm satisfied it will do a great job. krimpet✽ 02:55, 13 September 2008 (UTC)
• Strong support per the comments above. ╟─Treasury§Tag►contribs─╢ 07:29, 13 September 2008 (UTC)
• Oppose due to the secrecy issue. Wikipedia is based on openness, and having the rules reviewed by others than those who write them will make sure that they are fair. Also, blocks based on "secret evidence" have a history of causing endless drama. I don't think secrecy is needed to stop Grawp and the like: the title blacklist has dramatically cut down on Grawp vandalism, even though it is open for all to read. The strength of this abuse filter is the flexible nature of the filters, not the fact that they're secret. I am convinced that this flexibility will allow us to write strong filters that will be hard to evade even though they are known. Is he back? (talk) 10:56, 13 September 2008 (UTC)
  • Evidence please. From my experience, the titleblacklist has not cut down on Grawp vandalism at all. All its done is make Grawp explore new Unicode and new tactics. Note that unlike the secret mailing lists, the evidence won't be at all secret. The logs will be available to all and the filters will be available to 859 users, including all of ArbCom. Mr.Z-man 16:35, 14 September 2008 (UTC)
• Strong Support with the hope that this will prevent most template vandalism as well. I'll comment further later. Cenarium ^Talk 15:13, 13 September 2008 (UTC)
• Oppose. People complain Huggle is misused, that is nothing compared to what this would result in -- Gurch (talk) 22:13, 13 September 2008 (UTC)

  People complain that huggle is misused because it encourages people to just click a button to mark an edit as vandalism, without really thinking about it. This is a totally different concept – the idea being that premeditated and predetermined rules will be applied equally (not depending on a user's mood, as with Huggle) to all actions which occur on the wiki, as opposed to huggle, in which split-second fallible and inconsistent human judgement is applied to all edits. I can't see how the two could possibly be comparable. If your concern is that users will apply filters without thinking, I can assure you that users setting a 'block' action on filters they create, without adequately testing those filters, will be looked upon dimly by myself and the entire community. Revocation of access to set the filters would be almost inevitable. — Werdna • talk 05:00, 14 September 2008 (UTC)

  All computer programs are stupider than all humans, even if those humans aren't really paying attention; a fairly universal principle that research into artificial intelligence has failed to change -- Gurch (talk) 11:33, 14 September 2008 (UTC)

  There's also the non-trivial matter that these 'premeditated and predetermined rules' will be kept a secret from those of us deemed unworthy of seeing them (i.e. 99.99% of all contributors) -- Gurch (talk) 11:36, 14 September 2008 (UTC)

  I understand the objection on the ability of filters to be hidden, but your other objection seems plain bizarre to me. Certainly, computer programs can't check every single edit and determine whether or not it's vandalism, but we can certainly detect a decent subset of them, as my false positive analysis has shown (Reminder: checked 250,000 page moves, got 60% of all page-move vandalism (somewhere around 3000 page moves), and only made 4 false positive errors.) That's a false positive rate of 0.1%. That's about the same number of false positives per year as Huggle has in ten minutes. I don't know how you can use a generalisation like "All humans are smarter than all humans" to object to something like this, which plainly doesn't depend on machine intelligence. — Werdna • talk 11:40, 14 September 2008 (UTC)

  What the false positive rate is now is irrelevant, since you're going to give control of the filter rules to administrators. I assure you it won't be 0.1% once they start fiddling with stuff, if the record of the title blacklist is anything to go by -- Gurch (talk) 17:07, 14 September 2008 (UTC)

  Filters can be set to log only. It would be my hope that users entrusted with the ability to modify filters will have the modicum of common sense required to set filters to log only before switching them on. Those who do not do so should not be modifying filters. — Werdna • talk 05:30, 15 September 2008 (UTC)

• Oppose. Warning messages are poorly worded (they automatically assume guilt on the part of the person who triggered them violating the principle of assuming good faith). Also per the blocking feature which options would it set? All of them? Also I would like to point out something mentioned by Mr.Z-man below, is that simply blocking there IP would be a bad idea. Since the extension is NOT a checkuser it cannot verify that blocking a vandal would NOT also block a good contributor. Futhermore if that happens to come from say a school with only one public IP, it would essentially block the whole school. Vivio Testarossa^{Talk Who} 01:21, 14 September 2008 (UTC)

  You are welcome to suggest alternative wordings for the block messages. I wrote them when i was in the middle of writing the code for the abuse filter itself, so the language isn't too crash hot. In terms of block options, autoblock will be enabled, as will account creation blocking (i.e. the standard flags we use for blocking vandalism-only accounts). As for collateral damage from blocks, the autoblocks will be subject to the autoblock whitelist, which prevents anything which needs collateral damage prevention from being autoblocked. I'm not sure of the relevance, if any, of your comment about the extension "not being a CheckUser" – the statement is also incorrect; extensions have full access to all data available to CheckUsers, plus a bit more. — Werdna • talk 05:00, 14 September 2008 (UTC)

  Note that my comment below has nothing to do with what it will actually do but was a possible alternative. The warning messages, like every other message on the site can be customized. Note that any time an admin blocks someone with autoblock enabled (which is the default setting), they're also hardblocking the IP for 24 hours, and we don't need to consult with a checkuser for every vandal we block, and an autoblock is just as undoable as a normal block. So turning autoblock when blocking the account on or blocking the IP address for a short time is no different than what we currently do. Mr.Z-man 16:17, 14 September 2008 (UTC)

• Support I don't know of any bugs or serious issues with this. If it malfunctions, it will be stopped and the code fixed so that the mistakes won't be made a second time. Captain panda 17:54, 14 September 2008 (UTC)
• Support, since testing has shown it to be extremely reliable and it is sorely needed. Tim Vickers (talk) 19:13, 15 September 2008 (UTC)
• Support, long overdue. NawlinWiki (talk) 17:55, 16 September 2008 (UTC)
• Strong Oppose Blocking is a per incident thing, you cannot define a block with a set number of conditions, thinking you can is just a joke. Prom3th3an (talk) 01:03, 18 September 2008 (UTC)
• Yum. Tasty but dry. Needs olive oil. Synergy 04:06, 18 September 2008 (UTC)
• Oppose If it is going to do the blocks itself I cannot support. Davewild (talk) 06:52, 18 September 2008 (UTC)
  • We also proposed to run it without blocking enabled. Cenarium ^Talk 09:10, 18 September 2008 (UTC)
• Support: just do it already, rollback-style. HiDrNick! 14:01, 18 September 2008 (UTC)
• Just a general comment; what does "temporarily restricted from executing some sensitive operations" mean in plain english? Does that mean you've been blocked from editing or accessing MI6 documents? Caulde 19:29, 19 September 2008 (UTC)

  It means you won't be able to do anything that you need to be autoconfirmed for; that is, the extension removes your autoconfirm bit, and you have to go hunt down a cooperative admin who realize that false positives exist to get the action reversed. Celarnor ^{Talk to me} 21:58, 19 September 2008 (UTC)

• Support - Tiptoety ^talk 23:11, 19 September 2008 (UTC)
• Support Like I did last time when the "secrecy issues" were worked out. Protonk (talk) 04:25, 22 September 2008 (UTC)
• Support I'd like to thank the numerous 'skynet' opposes for putting a smile on my face, however misguided... Seriously guys, it's not going to be given the launch codes. Honest :D. (also)Happy‑melon 11:32, 22 September 2008 (UTC)

  The software is fine. It's the people that are controlling what effectively amounts to the power to do anything on-wiki without having the action tracked to them and without community oversight that bother me. Celarnor ^{Talk to me} 15:39, 24 September 2008 (UTC)

  Unless of course, someone looks at the history for the filter that caused the problems to see who wrote it. Please don't try to scare people with lies, thanks. Mr.Z-man 16:14, 24 September 2008 (UTC)

  The edit history is useless data without diffs. There are no guarantees that malicious material was added by the most recent edit; if sensitive enough to only be tripped once in a great while, an abusive add-in could be added in one edit and stay latent through various "improvements" made by others, possibly even without their knowledge if all they're doing is tweaking small parameters. Without diffs, all we have is who edited this last. We don't have "This person caused this to occur". Please, when discussing something as powerful as this, try to use a little logic and look at it from the perspective of people not in the administrative caste. Celarnor ^{Talk to me} 16:31, 24 September 2008 (UTC)

• I can add diffs, if that would be helpful. The main problem is how to present that information in a big fat table. — Werdna • talk 00:04, 25 September 2008 (UTC)

• Support This tool could be very helpful and all major concerns seems to have been taken care of. Pax:Vobiscum (talk) 16:35, 24 September 2008 (UTC)
• Support — Jake Wartenberg 15:53, 28 May 2009 (UTC)

Script responds to 2 questions at once

Hello! So the script that helps with responses on this page appears to be bugged and will respond to 2 questions at once, with the intended response going to the question above it and the intended report you are responding to will instead receive the response of {{effp|undefined}}. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 15:57, 11 April 2022 (UTC)

Yes, I can confirm. Link for code: User:DannyS712/EFFPRH.js Rusty4321 ^{talk contributions log} 18:57, 13 April 2022 (UTC)

Ping to script creator: DannyS712 Rusty4321 ^{talk contributions log} 00:51, 20 April 2022 (UTC)

Just noting that I have experienced this too. NW1223 <Howl at me•My hunts> 02:44, 21 April 2022 (UTC)

I tried a quick fix to skip undefined values, hopefully that will work - I plan to rewrite that script eventually when I have time DannyS712 (talk) 17:25, 21 April 2022 (UTC)

@DannyS712: I'll check to see if that's fixed it. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 17:26, 21 April 2022 (UTC)

@DannyS712: That's fixed the issue of adding the undefined template to the report you are intending to respond to, however it still responds to the report above the one you click "Review report" on. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 17:29, 21 April 2022 (UTC)

That I'm not sure about, sorry DannyS712 (talk) 17:57, 21 April 2022 (UTC)

@Blaze Wolf I started a complete rewrite at User:DannyS712/EFFPRH/sandbox.js that should have almost all of the functionality (some of the response-specific fields are missing) except that you only review one section at a time, and I think it should be working. Want to try it out? DannyS712 (talk) 13:14, 20 May 2022 (UTC)

@DannyS712: Hello Danny! Apologies I was on a Wikibreak when you mentioned this. Is this still something I can test out or has it been added to the main tool? ― Blaze Wolf^Talk_{Blaze Wolf#6545} 20:07, 23 September 2022 (UTC)

That page is cursed in general. I tried to fix the last updated part of the infobox to the correct date and managed to break everything. casualdejekyll 03:37, 30 April 2022 (UTC)