Page MenuHomePhabricator

Users are unable to create more than 2 accounts per day
Closed, ResolvedPublic

Description

Apparently this has something to do with secret task T230304 and was rolled in to production ( https://phabricator.wikimedia.org/rOMWCcc631f226ded0656253eb25bc9dd4d8937019b5c ) by @Urbanecm

No on-wiki documentation appears to have been updated for this change, and it was not included in the current Tech News. Please advise if it was.

Who is managing the response to the secret ticket?
Was there community notification of this new restriction? (Where?)
What is the community communication plan for this going forward?

When will the next communication take place?
At what interval will this be reviewed?

Communities need to know if we need to start working around this by granting out throttle overrides to users, updating documentation, or otherwise managing the communication for this change.

Event Timeline

Xaosflux created this task.Aug 15 2019, 3:52 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 15 2019, 3:52 AM
Xaosflux triaged this task as High priority.Aug 15 2019, 3:53 AM
JJMC89 added a subscriber: JJMC89.Aug 15 2019, 3:58 AM
Xaosflux removed a subscriber: JJMC89.Aug 15 2019, 3:59 AM

Is there some sort of shadow task (such as how T212667 was previously used)?

JJMC89 added a subscriber: JJMC89.Aug 15 2019, 4:01 AM
Xaosflux updated the task description. (Show Details)Aug 15 2019, 4:13 AM
1997kB added a subscriber: 1997kB.Aug 15 2019, 4:23 AM

Hello,

I've implemented the restriction as an immediate response to a security incident, which is described in the restricted task you linked to. I'll try to answer your questions, but bear in mind the task is restricted, and as such, I'm not allowed to say much.

Who is managing the response to the secret ticket?

I'm not sure I understand the question correctly. The original response was made by me, but anyone having appropriate permission and knowing how to handle this kind of security incident can do such immediate response. Given this is a security incident, the security team is ultimately responsible, and is of course allowed to remove or alter any of the restrictions I've implemented.

Was there community notification of this new restriction? (Where?)

No, there wasn't any community notification.

What is the community communication plan for this going forward?

I'm not aware of any communication plan that was approved for this kind of cases nor this case in particular.

When will the next communication take place?

See above.

At what interval will this be reviewed?

This restriction is supposed to be very temporary, and is under constant review. It will be reverted as soon as possible.

Communities need to know if we need to start working around this by granting out throttle overrides to users, updating documentation, or otherwise managing the communication for this change.

As said above, this change is supposed to be temporary, and to be reverted as soon as possible. As such, I don't think it's necessary to update documentation, since it's possible this change will be reverted at any time. If this change is highly restrictive to someone, you obviously can grant account creator flag to bypass this limit.

I hope I answered all your questions. If you want to know anything more, feel free to ask, but - as said above - I may be unable to answer to all your questions.

Is there some sort of shadow task (such as how T212667 was previously used)?

Well, you just created one :).

Aklapper changed the task status from Open to Stalled.Aug 15 2019, 11:07 AM

@Urbanecm thank you for the initial response. For the first part, trying to determine if this is being proactively managed by WMF staff or volunteers - as employees are more expected to respond than volunteers. Recently when such a mitigation was deployed (T212667) the temporary measure persisted for 6+ months (you were one of the volunteers asking up on why it was not being acted on if I read right!).

Unless "as soon as possible" is a reasonable short period (perhaps a week), having a community communications plan would be helpful.

@Urbanecm thank you for the initial response. For the first part, trying to determine if this is being proactively managed by WMF staff or volunteers - as employees are more expected to respond than volunteers. Recently when such a mitigation was deployed (T212667) the temporary measure persisted for 6+ months (you were one of the volunteers asking up on why it was not being acted on if I read right!).
Unless "as soon as possible" is a reasonable short period (perhaps a week), having a community communications plan would be helpful.

It definitelly will be less than two weeks, and most probably less than a week.

Change 530364 had a related patch set uploaded (by Urbanecm; owner: Urbanecm):
[operations/mediawiki-config@master] Revert "Set account create throttle to 2 everywhere"

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

Mentioned in SAL (#wikimedia-operations) [2019-08-15T12:56:26Z] <urbanecm@deploy1001> Synchronized wmf-config/InitialiseSettings.php: Remove account creation restrictions (T230304, T230521) (duration: 00m 48s)

Change 530364 merged by jenkins-bot:
[operations/mediawiki-config@master] Revert "Set account create throttle to 2 everywhere"

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

Urbanecm closed this task as Resolved.Aug 15 2019, 12:57 PM
Urbanecm claimed this task.

Reverted. I've reviewed this and talked about this with a few of people, and it seems the restriction is no longer neccessary. As such, I've remove it. Thank you for your patience.

Restricted Application added a project: User-Urbanecm. · View Herald TranscriptAug 15 2019, 12:57 PM
sbassett moved this task from Backlog to Done on the Security-Team board.Fri, Aug 30, 4:11 PM