Hosta

Archives

Index 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 11

Permissions archives

Sections older than 10 days may be automatically archived by Lowercase sigmabot III.

Hello everyone! I'm an admin from SqWiki. For many months now we're disturbed by a vandal which changes dates and other numbers in articles just for malicious purposes. Can someone help us set up a filter that would catch up edits which contain only number changes without providing any summaries? Maybe you already have such a filter I can copy to my community? - Klein Muçi (talk) 13:40, 22 February 2023 (UTC)Reply[reply]

@Klein Muçi can you provide a couple of example diffs? — xaosflux ^Talk 14:21, 22 February 2023 (UTC)Reply[reply]

712 (hist · log) is one that jumps to mind. Otherwise this kind of vandalism (WP:SNEAKY) is a tough problem to deal with in the general case, because a lot of number changes are vandalism, but some are corrections to inaccurate data (or effectively reverts of previous vandalism). AFAIK the best defence against this is recent changes patrolling, because it's very difficult for a filter (or even something smarter like an AI vandalism bot) to know if these changes are legitimate or not.

It could also be justifiable for your community to disallow unregistered users from making these kinds of changes, but that's more of a community/policy decision, as it involves a trade-off which would also block many legitimate edits. Only applying to edits without a summary is reasonable, but if you can circumvent it just by adding a summary then I imagine it's unlikely to be of use for long. Perhaps a more targeted filter for your particular vandal is possible. ProcrastinatingReader (talk) 15:25, 22 February 2023 (UTC)Reply[reply]

ProcrastinatingReader, @Xaosflux, hello and thank you for your expressed interest! It so happens that we have already discussed this matter together a few months ago: Special:Diff/1091973424#mw-diff-ntitle1
It's the same problem persisting. You say
It could also be justifiable for your community to disallow unregistered users from making these kinds of changes, but that's more of a community/policy decision, as it involves a trade-off which would also block many legitimate edits.
and that is the exact situation in which we are. Being a small wiki, we generally don't allow small number only edits by IPs without summaries even when we don't have a strong reason to suspect they might be vandalisms, the reason for that being that we lack the active volunteers needed to check and approve each of those edits. So that is a trade-off we have already been accepting for more than half a year now. The filter would just make de facto manual work that has been already happening for a long time easier. If you find the courage to travel on the rabbit hole of links I've brought above you'll see a lot of more details for this situation which is a desperate recurring request from me now. You'll also see that some MediaWiki changes we're issued to accommodate such a request but all started discussions were closed without any fruitful results. — Klein Muçi (talk) 17:01, 22 February 2023 (UTC)Reply[reply]

@Klein Muçi this ask seems a bit narrower in scope, can you provide a couple of diffs that are still in recent changes that illustrate the current edits? — xaosflux ^Talk 17:15, 22 February 2023 (UTC)Reply[reply]

Xaosflux, I've currently blocked for the millionth time the IP user which usually does these kinds of edits so I'm not sure if there are any on recent changes left (90% of those edits for us come from that one single user) but maybe I can find some old ones or imitate them artificially in my sandbox? Would any of those methods benefit you? — Klein Muçi (talk) 17:22, 22 February 2023 (UTC)Reply[reply]

@Klein Muçi In last 90 days should be fine, even if already reverted (so long as not deleted). Reason why is so that the AF Examine tool can be used to get the most details out of the edit. — xaosflux ^Talk 17:25, 22 February 2023 (UTC)Reply[reply]

Xaosflux, yes, I understand. I'm guessing some sandbox artificial edits would also help then, no? That would be easier to achieve than finding past edits. — Klein Muçi (talk) 17:28, 22 February 2023 (UTC)Reply[reply]

@Klein Muçi they could, but this was also to attempt to determine if how you describe the situation above is actually what the situation is; rules are programmatic but memories can be fuzzy :D For example is it ONLY strict number changes such as "156156" --> "156256", or is it also things like "100 003,1415" --> "100 003,1115", "3,14" --> "31,4", and "tetëmbëdhjetë" --> "gjashtë". Is it really null edit summaries, or is it also edit summaries that aren't null, etc. — xaosflux ^Talk 17:49, 22 February 2023 (UTC)Reply[reply]

Xaosflux, Edit 1, Edit 2, Edit 3.
These are all artificial edits. The first is full page edit with one single page, the second is full page edit with multiple changes and the third is a section edit (is this really "without summary"?).
I fully agree with your logic. Such variations do indeed exist for us but the idea is to hopefully get the code/regex for the general case and further modify it as needed. If you wish to go the extra mile, you might present me with the "general regex" and a variation where space + commas/periods are introduced. I believe that would be more than enough for me to model on further changes. — Klein Muçi (talk) 18:59, 22 February 2023 (UTC)Reply[reply]

OK, that matches: 6358179, 6358180, and 6358181. — xaosflux ^Talk 19:07, 22 February 2023 (UTC)Reply[reply]

@Klein Muçi so for example, notice that third one: it does have an edit summary: /* Filmografia */. — xaosflux ^Talk 19:08, 22 February 2023 (UTC)Reply[reply]

Xaosflux, I see. Any way to include such changes that have no manual inputted summary?
If not, let's stick with whole page edits, only number changes without summaries by IPs (even though the artificial examples I brought were made by registered accounts). — Klein Muçi (talk) 01:10, 23 February 2023 (UTC)Reply[reply]

Sorta, the "only number changes" is the hard part of this (and a MVP) - so that's the first hurdle, lets see if anyone comes up with any bright ideas for that first. — xaosflux ^Talk 01:52, 23 February 2023 (UTC)Reply[reply]

I commented on phab:T220764 that having better diff info to AF may solve this. — xaosflux ^Talk 15:51, 23 February 2023 (UTC)Reply[reply]

┌─────────────────────────────────┘
Just letting everyone know that after some experimenting and some help from some users, I've managed to cook up something that works well enough on what I wanted to achieve: w:sq:Speciale:AbuseFilter/20
This is currently being closely monitored to further fine-tune it and lower false positive numbers. — Klein Muçi (talk) 15:29, 25 March 2023 (UTC)Reply[reply]

There's an RfC at m:Requests_for_comment/Make_global_abuse_filters_opt-out to make global abuse filters apply to enwiki and other large wikis. I think we should opt-out since we don't have the issues mentioned and shouldn't allow meta admins to bypass our local guidelines. Galobtter (pingó mió) 06:58, 18 March 2023 (UTC)Reply[reply]

• Support opt-out. There's lots of reasons, but simply, our local capabilities are more than adequate. -- zzuuzz ^(talk) 08:30, 18 March 2023 (UTC)Reply[reply]
• Opt-out we don't need this. I could list lots of reasons, but having too much overlap with the also-local ones and wanting local custom warnings to be first is one. — xaosflux ^Talk 09:14, 18 March 2023 (UTC)Reply[reply]

  When both a local filter and a global filter are triggered for an edit at the same time, shouldn't the local filter's warning message be displayed instead of the global one? 0xDeadbeef→∞ (talk to me) 17:48, 18 March 2023 (UTC)Reply[reply]

  @0xDeadbeef suppose more testing is needed, when multiple filters all hit at once (even just locally) sometimes the results are odd. — xaosflux ^Talk 08:51, 19 March 2023 (UTC)Reply[reply]

  This sounds like a bug. Is there a Phab ticket somewhere or should I create one? 0xDeadbeef→∞ (talk to me) 08:55, 19 March 2023 (UTC)Reply[reply]

  Not sure if a bug, it may be deterministic (say there is a local warn, but a global disallow, there may actually be an order of precedence) - but pretty sure we run in this even locally if there are multiple warn filters hitting at once. — xaosflux ^Talk 09:10, 19 March 2023 (UTC)Reply[reply]

  Follow up: a "disallow" filter has the impact of protection and or a block, and we have more than enough local resources to make decisions about who may or who may not edit here. Compare configurations such as the MediaWiki:Spam-whitelist and LSGB - except in this case, there is no local whitelist. — xaosflux ^Talk 08:55, 19 March 2023 (UTC)Reply[reply]

  @Xaosflux: That's T45761. Certainly would be nice to have, but I would think that having more en.wp EFMs have access to global filters (as I suggested below) and the option to exempt "enwiki" inside the filter itself should cover most use cases? Legoktm (talk) 02:28, 20 March 2023 (UTC)Reply[reply]

  Having that open for 10 years isn't very promising. And having to run a "And not on project [array of projects]" on every filter is a bad idea. Also, not really a fan of making project admins meta efm's just to exempt their own projects. — xaosflux ^Talk 09:22, 20 March 2023 (UTC)Reply[reply]

• Opt-out In addition to everyone above, the English Wikipedia does not generally like the usage of global rights (see Wikipedia:Global rights policy), and I seen no reason to make an exception here. * Pppery * _{it has begun...} 14:03, 18 March 2023 (UTC)Reply[reply]
• Can someone who can view the private global abuse filters perform some kind of review to determine their utility for English Wikipedia? Perhaps there are some that may be helpful (or reproduced locally)? isaacl (talk) 15:06, 18 March 2023 (UTC)Reply[reply]

Support opt out - Out of lack of need and filters overlapping. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 16:20, 18 March 2023 (UTC)Reply[reply]

• Opt out. The English Wikipedia is more than capable of managing its own day-to-day operations without WMF involvement. Thebiguglyalien (talk) 18:01, 18 March 2023 (UTC)Reply[reply]
• Support opt out. I have been blocked only once on a Wikimedia Wiki—a false positive on a misconfigured global edit filter affecting the English WikiNews occurred when I was reverting vandalism, and the filter was set to block users automatically. Had Operator873 not stepped in to quickly unblock me, this bad global filter would have actively and substantially prevented me from continuing to revert vandalism while the Wiki was actively under attack from an IP-hopping vandalbot. I have low confidence that the global edit filters have the ability to automatically and appropriately block users in a manner that is consistent with the English Wikipedia's blocking policies, and I think that an opt-out is necessary to prevent future disruption to the English Wikipedia associated with the risks of these sorts of misconfigured global filters. — Red-tailed hawk _(nest) 18:56, 18 March 2023 (UTC)Reply[reply]

  Red-tailed hawk you were blocked by a local filter on that project as a direct result of my action. My first change to the filters were to a local one that had block enabled and that is the action that lead to your block. After I saw that my action on that filter resulted in you being blocked, I reverted the change and created a dedicate filter which I should've done from the very beginning. Your block was a direct result of my mistake on a local filter with block enabled and I wholly own my mistake. This wasn't a global filter issue as global filters do not auto-block. Operator873 ^connect 20:05, 18 March 2023 (UTC)Reply[reply]

  I had assumed that this was a global filter because I thought that Stewards generally couldn't edit local filters. I apologize for my mistake. That being said, I do support an opt-out of the global filters due to redundancy with EnWiki filters as well as the delocalization of the decision on whether to warn or deny users for edits away from our community. — Red-tailed hawk _(nest) 21:37, 18 March 2023 (UTC)Reply[reply]

  For what it's worth, there are global filters that block users (LTA 306) as well as ones that block autopromotion (fuerdai vandalism, WP0 copyright infringement prevention mechanism). Blocking decisions must remain local to EnWiki. — Red-tailed hawk _(nest) 21:42, 18 March 2023 (UTC)Reply[reply]

  I mean, en.wp EFMs deployed a filter that prevented anyone from adding the letter j (or some other letter, I might've gotten it wrong) for a few hours. Mistakes happen, it seems a bit extreme to opt-out solely on the basis that people could screw up (they will! but so will local filter editors). Blocking decisions haven't been solely local to en.wp for years now; stewards have mistakenly locked accounts or globally blocked IPs, but no one is calling for en.wp to opt-out of those global mechanisms. Legoktm (talk) 02:25, 20 March 2023 (UTC)Reply[reply]

  The edit filter would create local blocks. Would you please tell me what people other than EnWiki admins have the policy-based authority to issue blocks locally on EnWiki? — Red-tailed hawk _(nest) 02:49, 20 March 2023 (UTC)Reply[reply]

  Is there a meaningful distinction between a "local block" and other measures that have the same effect of preventing someone from editing? Like, hypothetically if global filters set global blocks instead of setting local blocks, would that be fine then?

  I should say, disallowing global filters from setting local blocks seems entirely reasonable to me. I just don't agree with the premise that currently blocking decisions are solely local. Legoktm (talk) 03:09, 20 March 2023 (UTC)Reply[reply]

  I think that there is a meaningful distinction inasmuch as personal accountability is concerned. On the English Wikipedia, we have WP:ADMINCOND and WP:ADMINACCT: both of these allow users to hold specific admins to account for making bad blocks and bad admin actions. We also have a body that is accountable to EnWiki that allows for desysopping admins who fail to adhere to these criteria.

  No such accountability is guaranteed to the English Wikipedia community if Meta admins screw up, and those very same Meta admins are not required to have undergone vetting by the English Wikipedia community prior to being given the tools that would allow them to make decisions of blocking on EnWiki. The only policy on Meta allowing desysopping of full Meta-Wiki admins is one that pertains exclusively to inactivity. This setup would create a poor governance structure, where people who are fundamentally unaccountable for their screw-ups would get to make blocking decisions.

  As for why global locks and global blocks are different: neta admins do not have the policy-based authority nor technical ability to issue global blocks nor global locks. That is reserved for the Stewards, who are accountable to the community through elections and re-confirmations.

  Good community governance proceeds from accountability to that community, but failure to establish accountability creates weakness in governance structure. If we are to retain a strong and effective governance structure, and to mitigate risks associated with privileged users, then keeping local blocks local makes sense. — Red-tailed hawk _(nest) 07:04, 20 March 2023 (UTC)Reply[reply]

• Support opt-out At the end of the day, the far reaching effects on enwiki of any mistakes, or unintentional implementations can be far and wide, with not many users who are active to fix them. We have far better quantity and quality of EFMs here then we do xwiki. I would like to think enwiki can hold it's own water about this. -- Amanda (she/her) 20:14, 18 March 2023 (UTC)Reply[reply]
• It depends:
  • Support opting-in to logging and tagging, if the condition limit is doubled. If a little bit of clutter in our AbuseLog helps global patrollers track cross-wiki abuse, so what?
  • Weakly support opting-out of warn and disallow actions. I'm not comfortable with this, but that's mostly because I can't see what's really going on with the private filters. Maybe it's not as bad I as imagine? I'd support enabling these actions, but only with a sunset period, of, say, a month or two. If it causes too many problems, then no need for a second RFC.
  • Strongly support opting-out of blocking action. First, blocking filters (even local blocking filters) are not a good fit for enwiki's "clean block log" culture. I've seen long-time users quit after one 24-hour block. Second, this would effectively give meta-wiki admins the ability to block enwiki users. And third, there's a WP:BEANS reason that I'm sure at least TheresNoTime and a few others are aware of. That reason alone is deal breaker.
• If such fine-grained control is not possible, then I simply support opting out entirely. Suffusion of Yellow (talk) 20:37, 18 March 2023 (UTC)Reply[reply]

  Do we know the effect that opting in would have on the condition count? — Red-tailed hawk _(nest) 22:01, 18 March 2023 (UTC)Reply[reply]

  From phab:T309609 I gather that global filters would count against the limit. But the limit can be raised. Suffusion of Yellow (talk) 22:06, 18 March 2023 (UTC)Reply[reply]

• For reference, this is the list of enabled global filters. I find it interesting that one filter is set to block and a couple others are set to block autopromote when there's the message on the abusefilter edit page for both that says "(do not set on global filters)". I'm not necessarily opposed to allowing logging as SoY mentions but as of yet that debundling is not possible. Galobtter (pingó mió) 21:09, 18 March 2023 (UTC)Reply[reply]

  From meta:User:Legoktm/Global_filters_everywhere I gather that it's technically possible, using the $wgAbuseFilterLocallyDisabledGlobalActions. Suffusion of Yellow (talk) 21:15, 18 March 2023 (UTC)Reply[reply]

  Struck, that's good that it is. I think opting in only to logging filters is something that we could definitely do if needed. Galobtter (pingó mió) 21:29, 18 March 2023 (UTC)Reply[reply]

• Support opting out of warning, disallowing, and blocking actions. As somebody who watches the edit filters here and cross-wiki, having the global abuse filter log actions here would be helpful. However, we should definitely opt-out of the more direct actions, such as warning, blocking and disallowing, where we have our own filters here.—*Fehufangą (✉ Talk · ✎ Contribs) 22:59, 18 March 2023 (UTC)Reply[reply]
• Support opt out, and FYI for @Suffusion of Yellow, Galobtter, and Red-tailed hawk: I intend to get T332521 (setting wgAbuseFilterLocallyDisabledGlobalActions) resolved in the next few days — TheresNoTime (talk • they/them) 22:52, 19 March 2023 (UTC)Reply[reply]
• There are good reasons to opt-out, but I think focusing on them misses out on the long-term advantages and opportunities that having global filters brings us. en.wp hasn't opted out of other global anti-vandalism/spam tools like the global spam blacklist (technically possible) or global blocks (also technically possible) or the global locking of accounts (not technically possible). Why should filters be treated differently? en.wp has a lot of filter experience, I'd much rather see a good amount of our EFMs start operating on the global level to improve all Wikimedia wikis at once instead of constantly duplicating efforts. Legoktm (talk) 02:20, 20 March 2023 (UTC)Reply[reply]

  We do manage local whitelists for GSBL and GBs, there is no whitelist for GAF. — xaosflux ^Talk 09:42, 20 March 2023 (UTC)Reply[reply]

  Give us some mechanism to disable any one filter locally, and I would say we should accept the global filters except for individual ones we choose otherwise. We have this feature with global blocks and global blacklist; We probably rarely use this, but the fact that we can is crucial here. Animal lover |666| 22:14, 20 March 2023 (UTC)Reply[reply]

• Absolutely allow opt-out from each global filter; this probably requires general opt-out from the global filter system. We certainly should have filter managers keeping an eye on global filters and decide on a case-by-case basis what we want. However, our filter managers (except where our community says otherwise) should have the last word for each filter, not some global authority (except for possible disallowing where legal issues make it necessary; should this actually be necessary, the Foundation can handle it here directly). Animal lover |666| 09:10, 20 March 2023 (UTC)Reply[reply]

  Just for the record, I would support a bot which copies all new global filters to our local filter system, and copies modifications from all global filters which remain unmodified here. This would certainly meet the "opt out from individual filters" criterion, as we can simply disable a filter as a means of opt-out. Animal lover |666| 11:43, 21 March 2023 (UTC)Reply[reply]

• Support opt-out and I'd expect the consensus here to be pretty close to unanimous. This global abuse filter sounds fantastic for smaller wikis that don't have enough people with the right skillset to manage a robust filter. It isn't a problem we experience here on enwiki. Every indication I've seen shows that we're more than capable of managing our own filters per our local policies. The Wordsmith^{Talk to me} 13:42, 20 March 2023 (UTC)Reply[reply]
• Support opt-out Not an improvement for en-wiki and an ivory-tower-created version is likely to be inferior at best. North8000 (talk) 18:40, 20 March 2023 (UTC)Reply[reply]
• Oppose opt-out I'm definitely in the minority here, but my viewpoint lies in supporting global contributions to anti-vandalism; vandalism is vandalism in any project. EpicPupper (talk) 20:03, 20 March 2023 (UTC)Reply[reply]
• Support opt-out, except for tracking (if that's possible) - The underlying global RfC makes perfect sense, btw, I've no issues at that level. But for the reason covered above, we don't need it. If there's a way to keep the tracking bits working, then why not aid the global side to the degree we can? Nosebagbear (talk) 23:43, 20 March 2023 (UTC)Reply[reply]
• Support opt-out. We are plenty capable of managing our own filters here. —Compassionate727 ^(T·C) 02:35, 21 March 2023 (UTC)Reply[reply]
• Case-by-case. I think there should certainly be an option to pick and choose which abuse filters should not apply to English Wikipedia. However, I also believe that fully opting out can make it harder to catch cross wiki abuse. The global title blacklists and spam blacklists already allow for that. If we can pick and choose which filters should and shouldn't apply to us then it is all good. That will only be possible, though, if abuse filter managers here are given permission to view the contents of private global filters on Meta-Wiki. Aasim - Herrscher of Wikis ❄️ 19:57, 22 March 2023 (UTC)Reply[reply]

  To add on to this: the only global filters that should be enabled on the English Wikipedia are those to enforce global policies on vandalism, spam, T&S, etc., not all global filters. Aasim - Herrscher of Wikis ❄️ 20:00, 22 March 2023 (UTC)Reply[reply]

There is a backlog of pinned requests needing further review at WP:EFFPR, with the oldest one going back nearly a month now. Some additional eyes/investigations are needed. Taking Out The Trash (talk) 15:52, 21 March 2023 (UTC)Reply[reply]

I checked ~200 of the edits that were tagged for Special:AbuseFilter/432, and didn't find any false positives. I think it can be set to disallow - thoughts? Galobtter (pingó mió) 06:31, 24 March 2023 (UTC)Reply[reply]

I've checked a few past hits and I didn't find any false positives too. +1 on setting this to disallow. 0xDeadbeef→∞ (talk to me) 08:04, 24 March 2023 (UTC)Reply[reply]

Seems fine. Out of the last 100 hits with saved changes, only [1] and [2] (plus a few that I reverted myself) weren't reverted. I'm not sure either is bad-faith, but so long as there is a custom message, I think the high volume of edits justifies setting this to disallow. Suffusion of Yellow (talk) 23:37, 24 March 2023 (UTC)Reply[reply]

Yeah I'd convert the custom warning to a similarly worded custom disallow. Galobtter (pingó mió) 04:31, 25 March 2023 (UTC)Reply[reply]

I agree with @0xDeadbeef and @Suffusion of Yellow. You should really never have to start a line with lowercase letters, so there should be only a VERY small amount, if any, of false positives. I think we definitely set the filter to disallow. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 10:55, 25 March 2023 (UTC)Reply[reply]

This filter probably also only applies to new users, making the risk of false positives even lower. Animal lover |666| 10:57, 26 March 2023 (UTC)Reply[reply]

True. Honestly this should have been set as disallow sooner. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 12:20, 26 March 2023 (UTC)Reply[reply]

@Galobtter: As you are an edit filter manager, I think you can go ahead and set it to disallow. There is clear consensus here. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 12:20, 26 March 2023 (UTC)Reply[reply]

 Done — TheresNoTime (talk • they/them) 00:53, 28 March 2023 (UTC)Reply[reply]

 Thanks - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 00:56, 28 March 2023 (UTC)Reply[reply]

@TheresNoTime: Did you mean to set that to warn+disallow, instead of just disallow? Currently MediaWiki:Abusefilter-warning-lowercase-letters is telling users to press 'Publish changes' to continue, at which point they'll get the generic disallow message. Suffusion of Yellow (talk) 23:48, 30 March 2023 (UTC)Reply[reply]

Nice catch @Suffusion of Yellow! You’re right, that should probably be changed. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 00:51, 31 March 2023 (UTC)Reply[reply]

I fixed the filter to now use MediaWiki:Abusefilter-disallowed-lowercase-letters. Galobtter (pingó mió) 08:32, 31 March 2023 (UTC)Reply[reply]

Filter #716 currently tags edits by new users that tag/detag pages as good articles or featured articles. Lots of the hits are vandalism, so I think this should definitely be set to warn. New users shouldn’t be doing this anyways. It could be set to disallow, but what do you think? - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 00:46, 28 March 2023 (UTC)Reply[reply]

It seems a lot of these hits are otherwise disallowed though — e.g. this recent IP. — TheresNoTime (talk • they/them) 00:59, 28 March 2023 (UTC)Reply[reply]

Yes, they usually are, but not always. I see no harm in changing this to warn or disallow. Do you @TheresNoTime:? - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 01:03, 28 March 2023 (UTC)Reply[reply]

I guess not, at least for warn —  Done — TheresNoTime (talk • they/them) 01:08, 28 March 2023 (UTC)Reply[reply]

I have seen this filter catch a lot of phone numbers with few false positives. I believe that we can start having the filter warn users. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 21:12, 2 April 2023 (UTC)Reply[reply]

I think that's way too premature. Only a few hours ago it was realised that a simple timestamp would trigger a false positive. I hate to think how many other potential FPs are just waiting to be found. I suspect there are many. Let's let it run longer. -- zzuuzz ^(talk) 21:23, 2 April 2023 (UTC)Reply[reply]

I was unaware of the timestamp issue. Sorry! - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 21:27, 2 April 2023 (UTC)Reply[reply]

As zzuuzz said - I appreciate the enthusiasm, but I'm monitoring the filter and will ask about setting actions when I'm satisfied that there will be a low false positive rate, which might take a few weeks. Galobtter (pingó mió) 21:26, 2 April 2023 (UTC)Reply[reply]

Okay. I look forward to hearing from you. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 21:27, 2 April 2023 (UTC)Reply[reply]