Page MenuHomePhabricator

How should blocks treat temporary users?
Closed, ResolvedPublic

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

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:

@Bugreporter What do you mean by "indefinite block for VOA"? Do you think there is a high likelihood of expired temp accounts being blocked?

Traditionally admins will issue indef blocks for vandalism-only users. It is probably not a good practice to do so on temporary users, since they will expire and become unusable.

However, rMW7440b2c22e3294d7b173202e3250c0e2c7982ebb described a different use case for indefinite blocks: if someone accidently logged out and make edit we may use hideuser to hide the temporary account, which must be blocked with an indefinite block. So indefinite blocks of temp accounts and blocks of expired temporary accounts has its use case. But admins should be able to know whether a temporary account is expired before blocking anyway.

Nothing should be done re blocks - the block will have no effect once the account expires, but it should still persist in the database, and allow the community to declare any new temporary accounts to be block-evading sockpuppets of the original temporary accounts for example.

However, rMW7440b2c22e3294d7b173202e3250c0e2c7982ebb described a different use case for indefinite blocks: if someone accidently logged out and make edit we may use hideuser to hide the temporary account, which must be blocked with an indefinite block. So indefinite blocks of temp accounts and blocks of expired temporary accounts has its use case. But admins should be able to know whether a temporary account is expired before blocking anyway.

There will be a visual indicator to see if a temporary account is expired - see T358469: Display expired temporary account names differently.

I will close this task since all outstanding sub-tasks are now closed. Please reopen if we missed something.

However, rMW7440b2c22e3294d7b173202e3250c0e2c7982ebb described a different use case for indefinite blocks: if someone accidently logged out and make edit we may use hideuser to hide the temporary account, which must be blocked with an indefinite block. So indefinite blocks of temp accounts and blocks of expired temporary accounts has its use case. But admins should be able to know whether a temporary account is expired before blocking anyway.

There will be a visual indicator to see if a temporary account is expired - see T358469: Display expired temporary account names differently.

I will close this task since all outstanding sub-tasks are now closed. Please reopen if we missed something.

Closing per above message.