I'd go even further given how easy it is to change IPs to just require it on every case. That simplifies the logic. We already require captcha for every user creation regardless.

In T357778#9551525, @Ladsgroup wrote:

I'd go even further given how easy it is to change IPs to just require it on every case. That simplifies the logic. We already require captcha for every user creation regardless.

We can make that configurable and observe what happens in some pilot wikis (T357763: [Epic] Create a temporary accounts initiative Grafana dashboard). I hesitate to say that we set "always show a CAPTCHA for temp account creation" as the default, because that diverges significantly from the status quo, in regard to barrier to entry for editing.

Fair, in adding links, the user clicks on Publish and then sees a captcha, maybe if we show captcha before that it would reduce the barrier but yeah. Very non-scientific gut feeling. Nothing concrete.

The proposed mechanism for showing the CAPTCHA is in this patch (T20110: Define AbuseFilter consequence to display a CAPTCHA).

@kostajh Are you actively working on this task? Did we establish what the Xs and Ys will be for the signals listed in the description?

In T357778#10006156, @Niharika wrote:

@kostajh Are you actively working on this task?

I've claimed it only because the mechanism for this work is via T20110: Define AbuseFilter consequence to display a CAPTCHA, which I am moving forward. I'll unclaim it, though, because in retrospect there are some other actionables here.

Did we establish what the Xs and Ys will be for the signals listed in the description?

We did not. But I think this could be in the hands of AbuseFilter maintainers, after we define the variables they can use for this.

I think what needs to be done to meet the examples in the description is:

In T357778#10095552, @kostajh wrote:

In T357778#10014107, @kostajh wrote:

In T357778#10006156, @Niharika wrote:

@kostajh Are you actively working on this task?

I've claimed it only because the mechanism for this work is via T20110: Define AbuseFilter consequence to display a CAPTCHA, which I am moving forward. I'll unclaim it, though, because in retrospect there are some other actionables here.

Did we establish what the Xs and Ys will be for the signals listed in the description?

We did not. But I think this could be in the hands of AbuseFilter maintainers, after we define the variables they can use for this.

I think what needs to be done to meet the examples in the description is:

scenario	task
the user's IP is known to iPoid-Service	T354599: [EPIC] WE4.2.14b Provide IP reputation variables in AbuseFilter
the user's IP is linked with X number of temp account creations in the last Y minutes	new task needed to create an AbuseFilter variable for "IP linked with {threshold} account creations in {threshold} time"
the user's IP is linked with X number of temp account edits in the last Y minutes	new task needed to create an AbuseFilter variable for "IP linked with {threshold} temp account edits in {threshold} time"

I'll make tasks for this. Otherwise, this task is resolved, as the ability to require a CAPTCHA as part of the temporary account creation flow was done in T20110: Define AbuseFilter consequence to display a CAPTCHA.

Filed as T374521: Create AbuseFilter variable for number of temporary account creations in the last hour from an IP and T374522: Create AbuseFilter variable for number of temporary account edits in the last hour from an IP