Page MenuHomePhabricator

How should blocks treat temporary users?
Open, Needs TriagePublic

Description

From T326759#8653302:

Blocks (AHT)

  • Should blocked IPs defined in DnsBlacklistUrls and SoftBlockRanges apply to temporary account users?

Yes - T343704: Ensure temporary users are blocked by configured IP blocks

  • Should it be possible to suppress a temporary account user? (It's not possible to suppress an IP user.)

No - T343705: Ensure temporary accounts cannot be suppressed via "hideuser"

  • How should autoblocks work for temporary accounts? (Blocked on community consultation as commented here: T300294#8476287)

This is working as desired - see T332231: [Investigate] Autoblocks behavior for temporary accounts

  • If the "Apply block to logged-in users from this IP address" is unchecked, should it block temporary account users?

Yes - T343714: Soft blocks against an IP address should block temporary accounts using that IP address

  • Should BlockDisablesLogin prevent a user from making a temporary account?

N/A - see T338836#9073827

Note that GlobalBlocking recognizes "anon only" blocks too.

Related Objects

Event Timeline

(It's not possible to suppress an IP user.)

It is possible to suppress the ip of a revision on a single page. It seems this comments referes to the "hideuser" feature on Special:Block (want just note about the right naming here)

(It's not possible to suppress an IP user.)

It is possible to suppress the ip of a revision on a single page. It seems this comments referes to the "hideuser" feature on Special:Block (want just note about the right naming here)

Ah thanks for clarifying! Yes, it just means hideuser here.

  • Should blocked IPs defined in DnsBlacklistUrls and SoftBlockRanges apply to temporary account users?

If they apply to unregistered editors at present then they should also apply to temporary accounts.

  • Should it be possible to suppress a temporary account user? (It's not possible to suppress an IP user.)

We want to keep the temp accounts experience consistent with current experience for unregistered users so we should disallow hideuser for temp accounts if it is disallowed for IPs currently.

  • How should autoblocks work for temporary accounts? (Blocked on community consultation as commented here: T300294#8476287)

We have since discussed this and the expected behavior is in place: T332231: [Investigate] Autoblocks behavior for temporary accounts

  • If the "Apply block to logged-in users from this IP address" is unchecked, should it block temporary account users?

Yes. Temporary accounts should not be treated the same as “logged-in users”.

  • Should BlockDisablesLogin prevent a user from making a temporary account?

No. Temporary accounts are not proper accounts so it makes sense to not disable them. Is this a config option that can be customized on a per-wiki basis in case a wiki wants to change it?

  • Should it be possible to suppress a temporary account user? (It's not possible to suppress an IP user.)

We want to keep the temp accounts experience consistent with current experience for unregistered users so we should disallow hideuser for temp accounts if it is disallowed for IPs currently.

Besides consistency, temporary users should never need to be hidden since their username is automatically generated.

  • Should BlockDisablesLogin prevent a user from making a temporary account?

No. Temporary accounts are not proper accounts so it makes sense to not disable them. Is this a config option that can be customized on a per-wiki basis in case a wiki wants to change it?

If $wgBlockDisablesLogin is set to true, blocked users will be signed out and future attempts to sign in will fail.

This setting only makes sense for wikis that require an account to edit (or even read). Such wikis should not have temporary accounts.

WMF's config only enables this setting for private wikis plus votewiki and labswiki. I would not expect that to expand.

  • Should BlockDisablesLogin prevent a user from making a temporary account?

No. Temporary accounts are not proper accounts so it makes sense to not disable them. Is this a config option that can be customized on a per-wiki basis in case a wiki wants to change it?

If $wgBlockDisablesLogin is set to true, blocked users will be signed out and future attempts to sign in will fail.

This setting only makes sense for wikis that require an account to edit (or even read). Such wikis should not have temporary accounts.

WMF's config only enables this setting for private wikis plus votewiki and labswiki. I would not expect that to expand.

This makes sense to me. BlockDisablesLogin should not be set to true on wikis where temporary accounts are enabled. Therefore we don't need to implement any special handling of BlockDisablesLogin for temporary users, so there's nothing to do here.

Moving this task to the backlog since the work is captured in subtasks, which are in progress.

Blocks of expired temporary accounts make no sense (but admins may tend to use indefinite block for VOA) and they will inflate the database and confuse users. So some proposed ideas:

  • Prevent blocks of temporary accounts for more than the lifetime (one year in Wikimedia wikis)
  • Prevent blocks of already expired temporary accounts
  • Automatically purge blocks of temporary accounts upon expiration