This page uses content from Wikipedia and is licensed under CC BY-SA.

Wikipedia:Edit filter noticeboard

Welcome to the edit filter noticeboard
Filter 1071 — Pattern modified
Last changed at 04:59, 11 July 2020 (UTC)

Filter 2 — Flags: disabled

Last changed at 21:32, 10 July 2020 (UTC)

Filter 225 — Pattern modified

Last changed at 14:56, 9 July 2020 (UTC)

Filter 861 — Flags: disabled

Last changed at 15:10, 9 July 2020 (UTC)

Filter 1058 — Actions: none

Last changed at 16:00, 9 July 2020 (UTC)

Filter 1074 (new) — Actions: disallow; Flags: enabled,private; Pattern modified

Last changed at 15:11, 9 July 2020 (UTC)

This is the edit filter noticeboard, for coordination and discussion of edit filter use and management.

If you wish to request an edit filter, please post at Wikipedia:Edit filter/Requested. If you would like to report a false positive, please post at Wikipedia:Edit filter/False positives.

Private filters should not be discussed in detail here; please email an edit filter manager if you have specific concerns or questions about the content of hidden filters.


Click here to start a new discussion thread


Disallow empty edit requests

Moved from WP:EFR: ~ ToBeFree (talk) 04:04, 1 June 2020 (UTC)
  • Task: Warn or disallow unregistered and new users from dropping an empty edit request on a talk page.
  • Reason: From a repeated WP:RFPP request to semiprotect Talk:TikTok where a pattern of various IPs with no pattern have been leaving multiple edit requests, leading to the talk page having been protected several times for up to a month, however I've observed similar behaviour on many pages over time. A user saving an edit with the content of Template:Submit an edit request/preload unmodified should trigger the filter, if it's possible to code a filter to do that. Preventing this specific edit would be more useful than whack-a-mole protections. Ivanvector (Talk/Edits) 17:09, 31 May 2020 (UTC)
  • It should be able to do that. We'd probably want a custom message displayed rather than the generic "your edit was unconstructive" for good faith edits of that sort. CrowCaw 18:23, 31 May 2020 (UTC)
This is a recurrent time-wasting problem at many other pages too. To avoid people just typing a random letter to circumvent this, maybe there should also be a minimal number of characters in the edit request – I don't know the exact number, a minimal valid request would be something like "Fix the typo in [word]" (16 + [word]); maybe like 20 or if we want to be even more lenient 10. Cheers. RandomCanadian (talk / contribs) 18:38, 31 May 2020 (UTC)
I don't think this activity is malicious, I think it's just not following instructions, possibly by non-English editors. I'd like to see how much of it goes away if just saving the default unmodified template is flagged or disallowed, before we talk about expanding the criteria. Ivanvector (Talk/Edits) 18:47, 31 May 2020 (UTC)
It's definitely not malicious. It's just like we regularly get non-native speakers posting their CVs at (ironically, but not accidentally) WP:AUTOBIO -- there's something about the instructions that people misunderstand. EEng 06:19, 1 June 2020 (UTC)
Altering {{Protected page text}} to offer a nice big green inviting button to take the user back to the parent page might reduce the occurrence of this error.
Altering "Cancel" across the wiki so it's a white-on-red button of equal prominence to "Publish changes" rather than a redlink may also help, not only for this problem, but in maintaining the consistent meaning of redlinks.
If this is the route by which editors are hitting this problem then, I'd say editors clicking on View source to take a look under the bonnet are at the more technically curious end of the spectrum and would be better served by an edit-filter rejection rather than a talk page message memorialising their mistake. Just my 2¢, Cabayi (talk) 07:54, 1 June 2020 (UTC)
@Cabayi: I'd be in favour of the change to {{Protected page text}}, and also in favour of disallowing empty edit requests through the edit filter. It's silly to make actual users review them, and just a waste of time overall - but of course, many people will, as you rightly point out, not be making them deliberately. This seems like a good approach to tackle the issue. Naypta ☺ | ✉ talk page | 14:30, 8 June 2020 (UTC)
  • Just a quick note that because this filter would be disallowing good faith edits in other areas of the encyclopedia, it would require community consensus before implementation per WP:EF. Sam Walton (talk) 10:31, 1 June 2020 (UTC)
  • Looks like we may need to disallow empty edit filter requests while we're at it [1]. EEng 19:02, 2 June 2020 (UTC)

This still happens. The IP here seems to have added a bunch of whitespace to evade the edit filter, while still typing a perfectly empty edit request... RandomCanadian (talk / contribs) 03:43, 8 June 2020 (UTC) Missed a few . RandomCanadian (talk / contribs) 03:45, 8 June 2020 (UTC)

@RandomCanadian: Nope - Special:AbuseLog/26948207 shows that the edit filter was tripped. Filing the BRFA now DannyS712 (talk) 03:46, 8 June 2020 (UTC)
@DannyS712:: oh, my bad, I thought it had already been enabled... trout Self-trout RandomCanadian (talk / contribs) 03:47, 8 June 2020 (UTC)

BRFA filed

Please see Wikipedia:Bots/Requests for approval/DannyS712 bot 71, where I request approval to revert the empty edit requests with an informative summary --DannyS712 (talk) 03:53, 8 June 2020 (UTC)

I'm putting the above on hold until the original discussion decides what to do - if the consensus is to just not allow blank edit requests in the first place, this bot is rather pointless. Primefac (talk) 14:09, 8 June 2020 (UTC)
Could we have the filter changed to disallow, as promised? This, or any of the other recent hits, doesn't look like a false positive to me... RandomCanadian (talk / contribs) 12:40, 17 June 2020 (UTC)
Disallow would be better than revert, also remember the disallow message can be changed to something custom. One of the reasons for these empty requests may be that people think "edit request" means requesting the ability to edit the page, so it can be clarified to "request someone else make the edit you want". Naleksuh (talk) 16:55, 23 June 2020 (UTC)
Aagh... If I could edit the filter I'd go ahead and WP:FIXIT but can't do that so commenting again so this doesn't get archived... RandomCanadian (talk / contribs) 21:39, 2 July 2020 (UTC)

Unprivate filter 34 (New or unregistered user blanking someone else's user or user talk page)?

Should edit filter 34 be public? I don't see a reason why this filter is meant to be private. I doubt it is specifically for any LTA accounts, and it is not that much different than filters 3, 30 and 33 in terms of blanking pages (all three filters are public). The only real difference is that it deals with user/user talk pages. Train of Knowledge (Talk) 07:06, 21 June 2020 (UTC)

There was a prior discussion about this in May. That filter still has a few details that appear to be targetting past vandalism and I argue that it's worth keeping Filter 34 private. More details in the prior thread. EdJohnston (talk) 13:51, 21 June 2020 (UTC)

1069 to disallow

1069 (hist · log)

Ongoing BLP concerns. Opting for a filter over semi-protection as we're probably gonna get some other updates to the article soon, in light of ongoing events. I'm not super-attached to that, though, so everyone should feel free to semi if they think it's necessary. (Log-only at the moment, will set it to disallow soon.) Enterprisey (talk!) 07:49, 24 June 2020 (UTC)

@Enterprisey For those unfamiliar with the article, would you be willing to explain the context in the notes? DannyS712 (talk) 07:57, 24 June 2020 (UTC)
Absolutely. Should have done that in the first place, thanks for the reminder. Enterprisey (talk!) 07:59, 24 June 2020 (UTC)

803

User:Sandbox's page ID has changed. 95.49.85.227 (talk) 21:39, 25 June 2020 (UTC)

Nice catch. Yes, it was deleted by @HickoryOughtShirt?4 and then recreated, resulting in a new page id. Its now <code>63640560</code> - can an EFM please update line 9 of the filter? DannyS712 (talk) 22:42, 25 June 2020 (UTC)
Sorry, what did I do? HickoryOughtShirt?4 (talk) 22:47, 25 June 2020 (UTC)
@HickoryOughtShirt?4 you deleted User:Sandbox - see Special:Redirect/logid/107226677 DannyS712 (talk) 22:59, 25 June 2020 (UTC)
Done. GeneralNotability (talk) 23:10, 25 June 2020 (UTC)

Proposing we set 1071 to disallow

1071 (hist · log) Changed link from 1069 to 1071. {{reply to|Can I Log In}}'s talk page! 05:46, 2 July 2020 (UTC)

Not seeing any false positives lately, and the edits just keep coming... Pinging Zzuuzz, who made it. Enterprisey (talk!) 22:37, 1 July 2020 (UTC)

Did you mean 1071? :) I agree there's no real false positives. However, the vast majority of this vandalism is not and cannot be detected by this filter, so disallowing will have a negligible effect. It is more of a canary in a coal mine. In some senses, as long as this vandalism is in 'raid mode', it is best to let a page get plastered with vandalism so it can be sooner semi-protected. IMO. However the pace of vandalism is changing, and I'm on a wikibreak, so I'll leave the decision to disallow to others. -- zzuuzz (talk) 22:48, 1 July 2020 (UTC)
  • ZERO false positives! It's very infrequent so I wouldn't imagine a swarm of false positive reports if it's set to disallow; since it's trolling vandalism, not every vandal fighter is going to RBI. Now public or private? It's possible you may have to switch it to private. {{reply to|Can I Log In}}'s talk page! 05:46, 2 July 2020 (UTC)
    It's not a particularly complex filter and there's not much more you can check for, so disallowing it now is a bit pointless. It's also not very high load, so it's not an undue burden, and a lot of the edits flagged by it were reverted by ClueBot anyway. I don't think keeping it in log is particularly problematic, it highlights IPs which may need to get blocked and pages which may need to be protected. ProcrastinatingReader (talk) 02:09, 4 July 2020 (UTC)

VPN filter

Hi can someone get me a filter that will block users who try to use a vpn on a wiki please? --Kreba4 (talk) 04:02, 3 July 2020 (UTC)

Open proxies and other problematic IPs are already blocked from editing (see also the meta page on it); and there are so far only very few exceptions to this. RandomCanadian (talk / contribs) 01:55, 4 July 2020 (UTC)
That's probably an overstatement. @Kreba4: There is no filter capable of doing this. If you could get a list of VPN addresses to put in a filter, you're better off directly blocking them instead of putting them in a filter. However, you will never get a full list of VPN addresses. -- zzuuzz (talk) 19:47, 5 July 2020 (UTC)

Helper right request

Nardog (t · c · del · cross-wiki · SUL · edit counter · pages created (xtools • sigma· non-automated edits · BLP edits · logs (block • rights • moves) · rfar · spi) (assign permissions)(acc · ap · fm · mms · npr · pm · pcr · rb · te)

I hereby request the edit filter helper right. Please refer to 1070 (hist · log) and the edit filter mailing list for the reason, which I'm not at liberty to disclose here given its sensitive nature. Nardog (talk) 21:15, 4 July 2020 (UTC)

Just noting to confirm that there has indeed been an email sent to the mailing list with a reason that can be considered sensitive. --DannyS712 (talk) 02:44, 5 July 2020 (UTC)
It's a reasonable need for the EFH bit. The question, of course, is whether we feel Nardog can be trusted with being able to see all of the filters (now there's an idea...being able to grant someone the ability to see individual private filters). I don't see any obvious red flags, and my gut says yes, but I'll do some due diligence tomorrow before giving a final !vote. GeneralNotability (talk) 03:30, 5 July 2020 (UTC)
  • Seems pretty unprecedented to request rights, much less rights considered as 'valuable' as EFH, without being willing to disclose any information as to why you require the right, making community vetting or scrutiny impossible. It might as well be a right given by an admin per the mailing list in that case, rather than bringing it to the noticeboard. Removal of rights, yes, often include private information and the reasons for this are often private and not disclosed, and the process for removal at WP:EFH mentions private reasons can be made in confidence, but the granting of the rights in the first place? Seems improper to grant like this. ProcrastinatingReader (talk) 06:31, 5 July 2020 (UTC)
    • I agree that this is likely unprecedented. I would suggest evaluating whether the user can be trusted, has the experience, etc. - everything except having a “Demonstrated need for access“ - with that one criterion being affected by the private information. Nardog communicated privately with existing edit filter helpers/managers, and has explained their perceived need. I haven't looked at it enough to support or oppose yet, but everything other than that one criterion can be evaluated using public information, and this one issue can be left to those with access to determine. DannyS712 (talk) 06:44, 5 July 2020 (UTC)
      • That one criteron you're asking us to ignore is the big decision maker, worth more than the rest combined. Plenty of qualified people make their request on this board and get tossed away, or told that RfA is right around the corner. Just looking at the archives for EFH requests, requests have been denied to users who can "show a demonstrated need" because apparently "their need wasn't good enough". Creffett himself could be an example of that, he was denied EFH at this board just months before he was approved overwhelmingly at RfA. Mdaniels above has a stalled request.
      I'm strongly opposed to giving rights to someone who wants them apparently based on one filter, is not an SPI clerk, cannot show technical competence and a reason for the rights. I'm not saying they don't have a reason or the competence, I'm saying the process here is entirely flawed if they cannot justify to the community, in public, why they should have the rights just like everyone else has had to do, including yourself, from EFH/EFM, admin, to CU/OS. No reason for the rights is compelling enough to ignore this transparent process. ProcrastinatingReader (talk) 07:00, 5 July 2020 (UTC)
      ProcrastinatingReader, maybe this will help - we're being secretive here because of what 1070 is doing. Nardog is aware of what it is tracking (a specific LTA) and is doing some work in tracking that LTA. If I understand correctly, Nardog is also the one who suggested that filter. This is absolutely a strange case, but I believe they have a demonstrated need to see this filter. GeneralNotability (talk) 12:53, 5 July 2020 (UTC)
      GeneralNotability, thank you. That's an acceptable explanation. I don't expect (or want) a technical rundown of 1070 in public, but the reason why one wishes to help, and what help they'll do (suggesting changes, helping make new filters, etc), is never 'private'.
      imo being able to see the logs for one filter, even if they want to help with that particular LTA, doesn't warrant the whole kit. I second what Crow said on how they could help: they can communicate with an EFM to help improve the filter, including getting logs from that EFM, and admins can do the tracking as normal afterwards. ProcrastinatingReader (talk) 17:05, 5 July 2020 (UTC)
  • For the moment, I don't think one filter's need warrants the whole kit. There is ample precedent to share single filter details and logs via email with involved users (typically EFMs from other wikis, but still...), and would not be opposed to doing so here. Ideally it should be watched by an EFM/admin who can take immediate action or who can adjust the filter as needed when the LTA strikes. CrowCaw 16:13, 5 July 2020 (UTC)
  • Oppose primarily due to invoking some cloak of secrecy here, Nardog try explaining your request better. — xaosflux Talk 19:36, 5 July 2020 (UTC)
    • @Xaosflux: Fair enough. The reason for the request is to track the activity of an LTA with a history of POV pushing and harassment and suggest adjustments to the filter should the need arise, but their behavior so far indicates they're sophisticated enough that describing them any more specifically could very well jeopardize the purpose. Consult Wugapodes, the creator of the filter, or any of the admins I mentioned in the email if you need corroboration.
      If I need to prove I can be trusted with the whole set, then I can only hope my activity at AIV, UAA, etc. speaks for itself. Nardog (talk) 21:38, 5 July 2020 (UTC)
      • @Nardog: thank you for the update, strike the oppose; somewhat neutral that the need for just you to track one LTA isn't that persuasive - any of the admins should be able to deal with something like that. — xaosflux Talk 21:55, 5 July 2020 (UTC)
  • Obvious support from me as I suggested Nardog request EFH to help me with 1070. Perhaps this is not a typical request, but it is within our existing policy. Drafting 1070 would be much easier if the person who knows the LTA best can see it and its logs. I've only known about this LTA for a few days, and I don't have a great grasp on what is and is not a false positive. Crow is correct that ideally [1070] should be watched by an EFM/admin who can take immediate action or who can adjust the filter as needed, but to my knowledge that confluence of LTA knowledge and user rights doesn't exist. The next best option is granting Nardog EFH. Of course I could email Nardog the regex and log hits periodically, but that seems like far more work for essentially the same outcome as granting EFH. The request is for read access, so the potential harm is him disclosing the contents of a private filter. Given his track record on the project, I don't believe that will happen. Tl;dr: Support because my job would be made easier if Nardog had EFH. Wug·a·po·des 04:06, 6 July 2020 (UTC)
  • The EF Requests page has a long history of non-EFM/EFH posting requests and keeping updated as to hits and misses. The same has been done to the EF Mailing list for things too sensitive to post publicly. In the case we have here, that's all EFH is going to buy anyway as the details will still need to be sent to an EFM to tune the filter. Sending diffs of the LTA to the list along with a summary description will quickly make it clear how he works, as well as making FPs obvious for tuning out of the filter. In addition to seeing logs, one also needs to know the quirks of how the filter engine works; right now 1070 is almost all false positives just based on the search entered not taking into acount what the filter does at the basic level. CrowCaw 14:22, 6 July 2020 (UTC)

Era style changes

In a recent discussion several highly respected editors have mentioned that WP:ERA violations remain an ongoing headache. I wonder if it wouldn't make sense to filter for IPs changing established era format in a given article. For example, this might be the logic for checking for changing BCE to BC:

  • (1) edit by an IP, in article space
  • (2) added lines contains "BC" or "B C" or "B.C" or "B. C" [quick check that allows immediate exit in most cases]
  • (3) added lines like "(\d[ ]*B[. ]*C[. ]*[^E])|(B[. ]*C[. ]*\d)" [BC or B.C. (but not BCE or B.C.E), followed or preceded by at least one digit, is being inserted]
  • (4) existing article text not like (4) [article doesn't already have BC/B.C. with digits]
  • (5) existing article text like "(\d[ ]*B[. ]*C[. ]*E)|(B[. ]*C[. ]*E[. ]*\d)" [article already has BCE/B.C.E. with digits]

Of course, the above would be extended to also check for BC -> BCE, AD -> CE, CE -> AD. Wouldn't be 100% effective, but should really cut down the burden. The quick check at (2) should make it cheap (though the "quick check" for the AD/CE case won't be as cheap).

Having said all the above, to avoid false positives it probably needs to ignore anything inside quote marks or templates (thus exempting quoted material and citations); do we have an established formula for that? Thoughts? EEng 20:38, 5 July 2020 (UTC)

<sound of crickets chirping> EEng 04:53, 11 July 2020 (UTC)

EFH/EFM audit?

Hey folks, I've been thinking about this for a while, but the Nardog discussion reminded me: how do people feel about auditing the current (non-admin) EFH and EFM groups? My rationale is principle of least privilege/reduction of attack surface - by removing the perm from someone who doesn't need it, if their account is compromised it's less of a threat. I've exclude admins because a) they already have EFH powers by virtue of the admin bit, b) they can self-grant EFM at will, and c) if an admin account is compromised we have much bigger concerns. I'm open to auditing admins anyway if people want, but it just doesn't seem as useful. Outline of how I'd want to go about this:

  • Mass-message EFH/EFMs saying "do you still need this permission"
    • Low bar to keeping - just "yes, I still want it" is enough
  • If anyone asks for the perm to be removied or doesn't respond within, say, a month, remove the perm
  • Anyone who has the perm removed through this process may get it back upon request without the full EFH/EFM vetting discussion (I hope this part will make people more willing to agree to remove the perm if they don't need it)

For reference: list of EFHs (including two admins who don't need it), list of EFMs (by my count, 11 non-admins). GeneralNotability (talk) 16:56, 6 July 2020 (UTC)

I removed the 2 redundant EFH's; we do periodic checks for 1-year inactivity on the non-admins already. I'm not too worried about requiring a continual opt-in for active users on these. — xaosflux Talk 18:17, 6 July 2020 (UTC)
Xaosflux, okay, that works, I wasn't aware of the existing periodic checks. GeneralNotability (talk) 18:24, 6 July 2020 (UTC)
We don't really formally document it like we do for admins and crats. — xaosflux Talk 18:24, 6 July 2020 (UTC)

Facebook warn edit filter

Moved to WP:EFR: ProcrastinatingReader (talk) 21:10, 9 July 2020 (UTC)