Something else that I don't think has been said: Filter log entries would need to be deleted (as in "deleted for real with no backup") after 90 days, as per the data retention policy. Not just the "details", but the whole thing. If my IP happens to fall in the same range as some LTA, I don't want want that fact recorded forever.

Just tried again, this time with Chromium and the same tc settings, and the got the same error (Varnish XID 492021032). This is not a new problem; I just got around to reporting it now.

[mediawiki/skins/MinervaNeue@master] Update checkboxHack target node

https://gerrit.wikimedia.org/r/990144

So stepped through this with the debugger and I think I see what going on here.

I can reproduce this on enwiki with:

It looks like almost nothing has been said about private filters so far, beyond a few throttle settings. I think this task can be made public.

I set up public filter https://en.wikipedia.org/wiki/Special:AbuseFilter/1269 to test this. It currently trips on any three edits, by the same user, to the same page, within one second. It already has almost 100 hits in less than a day. I have no idea what the other users are doing, but I was able to trip it by attempting repeated identical edits:

Appears to be related to 7a7e8e94b. At least, when I manually remove the !important, I get a large red square background, which is an improvement over no background at all.

@Jdlrobson: Could this have something to do with the Codex switchover?

If anyone is looking for a quick workaround for their own scripts, adding uselang=en seems to do the trick.

When are y'all upgrading to Debian 11? That has PCRE version 10.36, and I cannot even reproduce this with 10.33.

From https://github.com/php/php-src/blob/PHP-7.3.31/ext/pcre/php_pcre.c:

But if I prefix the regex with (*NO_JIT) I get the correct result 100% of the time.

Still getting this for GET requests, but not POST requests on enwiki, even when I throw in junk to prevent caching:

Appears to be a JIT bug in some old versions of PCRE2 (and presumably "classic" PCRE, but I haven't tested):

PCRE2 version 10.32 2018-09-10
/a[\x{fd}\x{ff}]/i,utf,debug,auto_callout,jit=7
------------------------------------------------------------------
  0  63 Bra
  3     Callout 255 0 1
  9  /i a
 11     Callout 255 1 14
 17     [\xdd\xfd\xff\x{178}]
 57     Callout 255 15 0
 63  63 Ket
 66     End
------------------------------------------------------------------
Capturing subpattern count = 0
Options: auto_callout caseless utf
First code unit = 'a' (caseless)
Subject length lower bound = 2
aa
--->aa
 +0 ^      a
 +1 ^^     [\x{fd}\x{ff}]
+15 ^ ^    End of pattern
 0: aa

Thanks. Will this be a problem for a while on enwiki while the stale data is flushed out? Yes, it would be nice to do away with all those links eventually but they're everywhere...

Still something weird going on with protocol-relative (?) links, see https://test.wikipedia.org/wiki/Special:AbuseLog/99197 where a dummy edit apparently was seen as adding and removing about 30 links.

Is this ready to test on testwiki? I tried to add "spamsite.com" there, and got "Save failed".

I did a more thorough check at testwiki, including all supported URI schemes. There is still a problem with port numbers, see https://test.wikipedia.org/wiki/Special:AbuseLog/98932.

@Ladsgroup: Ooooh. When you siad "interface admins" earlier did you mean users with editinterface rights? No argument there. I thought you meant editsitejs. On enwiki all admins have editinterface rights, but only handful of "interface administrators" have editsitejs rights; hence my confusion.

It looks like there are over 1000 regexes doing something more complex than matching a single domain:

Some more questions:

This is not true (at least on enwiki), for the "disallow" action; a filter set to true will stop 100% of edits, until it is disabled. And this is a good thing, because sometimes when we're being attacked by proxies, the attacker's edits make up a substantial portion of recentchanges.

Please look at AbuseFilterEmergencyDisableThreshold configuration. I don't know where are you getting this but it exists.

I have notified WP:EFN and WT:SBL of this task.

You should use abusefilter for that. It has added_links variable for that.

Q1: How will this work when it's not a simple block of a single domain? For example, the global blacklist blocks any occurrence of "sexcam", "online-casino", and many other words anywhere in the domain.

No problems on test2wiki.

When does test2wiki update to wmf11? I want to be sure these changes cause anything unexpected at READ_OLD wikis, or we'll be dealing with issues at enwiki on Thursday.

Wait. Also mailto: links, see the reversed URL in https://test.wikipedia.org/wiki/Special:AbuseLog/98828

FWIW IPv6 links are fairly common on enwiki, as they're built into various "user info" templates, see https://en.wikipedia.org/w/index.php?title=Wikipedia:Administrator_intervention_against_vandalism/TB2&oldid=1157765051 for example. I have no idea how common port numbers are.

@Ladsgroup: Thanks. Tested this again, and most of the listed problems have been fixed. But I still trip AbuseFilter, SpamBlacklist and ConfirmEdit when I edit a page containing a link with a port number, see https://test.wikipedia.org/wiki/Special:AbuseLog/98826. I also discovered a new problem with IPv6 links; see https://test.wikipedia.org/wiki/Special:AbuseLog/98822.

(By the way, just look at all this text in the screenshots… ain't nobody reading all that. I had to resize the browser just to show the two messages I am describing. The notice about old revisions is not the only problem here. As long as there is just so much useless text, people will not read it, and will miss the important messages, even if – especially if! – we make them even bigger.)

Also reported at enwiki VPT.

Please see T337149 before deploying this to any more wikis. SCHEMA_COMPAT_READ_NEW is causing major problems with ConfirmEdit, AbuseFilter, and SpamBlacklist.

I can confirm that SpamBlacklist is affected by this too. This blacklist hit was triggered by attempting to add https://example.com to a page already containing https://spam.site. Not sure why the tags were removed.

Yes, AbuseFilter is affected by this, see the incorrect added_links and removed_links in my comment above. Any extension that uses getExternalLinksForPage will need to be updated, if the plan really is to do away with el_to.

And it gets worse. This also happen with:

But that makes it impossible to know if the path was "/" or empty, and the original URL can't be recovered, except from el_to which I gather from T312666 you plan on getting rid of.

Oh here we go:

// T312666
'wgExternalLinksSchemaMigrationStage' => [
        'default' => SCHEMA_COMPAT_WRITE_BOTH | SCHEMA_COMPAT_READ_OLD,
        'testwiki' => SCHEMA_COMPAT_WRITE_BOTH | SCHEMA_COMPAT_READ_NEW,
        'mediawikiwiki' => SCHEMA_COMPAT_WRITE_BOTH | SCHEMA_COMPAT_READ_NEW,
        'fawikiquote' => SCHEMA_COMPAT_WRITE_BOTH | SCHEMA_COMPAT_READ_NEW,
],

Could this have something to do with T326251 and e06f77134defc?

This even affects prop=extlinks:

Seems to affect more than just the ConfirmEdit. Check out this abuse log hit:

That would be better than nothing; and if it's easy enough to do while we are discussing better solutions, go for it. If it can also be given the same styling as with the 2010 interface (seems to come from classes mw-message-box mw-message-box-warning), that would also help. But the main problem is that the alerts disappear when you click anywhere else on the screen.

This seems to depend on the IP I connect to:

Haven't tested it, but nothing obviously wrong with the latest patch. I don't claim to understand the blocking code all that well though.

Thanks, that does it. Was it really always this way?

Bumping this. It's been 18 months now. If this were being exploited in the wild, would anyone even know?

In T264104#7395016, @Daimona wrote:

One year later, now that T288707 is resolved, it seems that we're indeed parsing stuff twice.

Supporting brotli compression (T137979), at least for API, might also help here.

So, something like the iiextmetadatafilter parameter for prop=imageinfo? I agree this would be useful. A typical filter hit is around 100 KB, and some filters on enwiki get tens of thousands of hits in a year. It would be nice to find out which parts of the filter are actually matching anything, without downloading gigabytes of data.

In T306660#7932309, @Jdlrobson wrote:

@suffusion_of_yellow , no, that's not true. Narrow screen doesn't mean mobile screen. Vector (intentionally) doesn't define a viewport, so users there will never get a narrow screen. Users on a mobile device will continue to see the desktop site with a desktop viewport zoomed out like so:

Something to remember: People using Vector on "narrow screens" are likely to be mobile users who dislike the (Minerva) mobile site. So a "solution" that makes Vector more like Minerva (e.g. collapsed sections) is exactly the wrong one. That would leave no escape, except logging in from every device, and every private tab, just to read a page.

Original thread was here. I'm trying to find if something occurs inside a table with an "Album" heading:

And another one: http://Draft:Getscreen.me. I got a CAPTCHA (from a non-AC account) even for a null edit on Wikipedia:Teahouse until I made this change.

I tried again on testwiki, enwiktionary, and enwikinews, and got an alert every time. Thanks for fixing this! Now where do we talk about disabling LiquidThreads on all WMF wikis?

It's installed but at Special:Version it's spelled "Liquid Threads" instead of "LiquidThreads". And I get no message bar. You can see the full list at https://noc.wikimedia.org/conf/highlight.php?file=InitialiseSettings.php. EIther wmgUseLiquidThreads or wmgLiquidThreadsFrozen force the extension to load.

In T295429#7499198, @Tgr wrote:

Maybe some extension/feature only enabled on testwiki is interfering? No idea what that could be.

First, @bwang and @ovasileva (and anyone else I've missed) thank you for implementing this! As you might know it's long been a pet peeve of mine.

In T295429#7494634, @Tgr wrote:

(Unless you experience this on an uncached view - you can tell apart cached views from the response headers having X-Cache-Status: hit or something similar vs. miss or pass on uncached views. Please reopen if you see this on an uncached view.)

Thanks @Dbrant for getting to this!

Do all the "trusted" proxies strip out existing XFF headers? I thought they usually just append another address.

In my opinion, just ignoring autoblocks for non-trusted headers won't be hugely harmful. If the vandal was using a proxy in the first place, then it's the proxy that will get hit by the autoblock, not the real IP. So the "abuse" scenario is:

(All this also applies to T276147. Only responding in one place.)

See T276149#7144054. (Should these tasks be merged...?) With 2.7.50362-beta-2021-06-04, the block message is there now, but it's not parsed. @Dbrant implied there might a newer version that does parse the message, but I can't find it.

@Dbrant: That link is a 404 but I tested on 2.7.50362beta-2021-06-04, which is the latest on https://releases.wikimedia.org/mobile/android/wikipedia/betas

! In T276149#7122539, @Dbrant wrote:

Tested in 2.7.50359-alpha-2021-05-27 on testwiki

Tested in 2.7.50359-alpha-2021-05-27 on enwiki