Would it be preferable to build this special page into its own extension or tap into an existing extension like CentralAuth?

All subtasks resolved. Closing Epic. ✅

Follow-up work in T345855: Update temporary username format . Thanks everyone for the lively discussion!

In T329913#8939120, @Seddon wrote:

In T329913#8873703, @Seddon wrote:

In T329913#8873702, @Tchanders wrote:

Thanks for this @Seddon - we also have a need to test on testwiki, since a lot of our changes are in CheckUser. We're currently working out an estimate for when we can deploy to testwiki (and which one), so will update you on this in a couple of weeks when @Niharika is back.

Awesome thanks @Tchanders!

@Tchanders and @Niharika just a ping to check in on timing for this. Design work is starting to come together for both iOS and Android and we could do with having this in place to be able to kick off engineering work

In T339252#9149621, @jsn.sherman wrote:

In T339252#9149497, @Soda wrote:

[...]

I'm unsure if just having the temporary account name being visible will be enough information for patrollers?

Genuine question: how do we determine that?

Additional info: the process for gaining access to IP addresses is laid out here:
https://foundation.wikimedia.org/wiki/Policy:Access_to_temporary_account_IP_addresses#Minimum_requirements_for_access

[...]

Also, we might want to consider building tools that surface some (ipinfo-view-full) information in PageTriage (ex: This IP address is in the same range as this other IP who recently also tried to create the same page a month ago etc) for administrators.

If I understand things correctly, I think we would need to implement the "reveal ip" button/workflow, which would then surface the ip info workflow. I'm not sure all legal and technical processes we would need to go through to implement that, but I did find this:
https://meta.wikimedia.org/wiki/IP_Editing:_Privacy_Enhancement_and_Abuse_Mitigation#How_will_the_IP_address_reveal_functionality_work?

In T339252#9148801, @Novem_Linguae wrote:

Looks like the save code is...

new mw.Api().saveOption( 'userjs-NewPagesFeedFilterOptions', this.encodeFilterParams() );

The documentation for mw.Api().saveOption() states that it uses https://www.mediawiki.org/wiki/API:Options.

The code for that eventually calls User->saveSettings(), which does touch the database, probably the user_properties table via UserOptionsManager-saveOptionsInternal().

Interesting. I would have guessed that PageTraige used browser localStorage, but I guess not. Using the SQL database makes the sessions per user rather than per browser, which I guess is good.

In T339252#9148138, @Novem_Linguae wrote:

Thanks for taking a look at this.

isAnon() could be replaced with !isNamed()

I suggest leaving the original code for this, instead of changing it. Special:NewPagesFeed is a public page that can be used by any editor. Allowing temp accounts to have their Special:NewPagesFeed filters be remembered between sessions seems harmless and low cost. Kind of like how we're giving them the ability to ping and receive pings. Open to other opinions though.

In T345678#9147746, @AntiCompositeNumber wrote:

This would also mean migrating the ~1160 users that have usernames beginning with a tilde (data from T332805). Does this sound reasonable?

This is likely to be controversial.

Thanks for filing the task @Whatamidoing-WMF and for updating TitleBlacklist, @AntiCompositeNumber.

In T345255#9132511, @tstarling wrote:

I believe it was @Prtksxna who expressed the concern that consecutive numbers, with most of the digits being the same between users created at a similar time, would be too hard for reviewers to distinguish in a changes list. I suggested a pseudo-random sequence as a way of making the numbers be easier to visually distinguish.

When this is deployed to production, names like "Unregistered 1" and "Unregistered 2" will be gone in an eye blink. Think about what it will look like with 7 or 8 digit numbers.

In T345578#9140769, @Tchanders wrote:

@Niharika Is this work included in T324492: IP Masking - MVP?

In T340275#8960404, @Bugreporter wrote:

I think T17294: Allow blocking of global accounts should be fixed instead.

@tstarling as the one who made this change would you be able to elaborate why you preferred the scramble method over the serial? Is there a benefit to using that?

I've created two other tasks to discuss the order of the temporary accounts (scramble/serial) and whether we need a prefix and if so what here:

• T345255: Decide the numerical order for temporary accounts (Scramble/Serial)

In T327420#9129012, @KStoller-WMF wrote:

In T327420#9126423, @Urbanecm_WMF wrote:
Thanks for mentioning this. I was under the impression that we (eventually) changed the answer and allowed temp users to thank/be thanked, since that's the easiest solution given we've notifications etc. available already, but that impression can be incorrect.

From a Growth PM perspective, I don't see the harm in allowing temp users to thank/be thanked. That seems like the simplest solution, and it seems odd to spend the time to remove it. However, that goes against the "make temp accounts similar to IP editing defaults" requirement, so @Niharika, perhaps you can chime in here?

Noting on this task that the related discussion is happening on T331058: Make Special:Mute only usable for named users

In T327420#8998782, @KStoller-WMF wrote:

StructuredDiscussions will be the most complex project to work with. Similar to VisualEditor, it makes edits via the API. As of now (tested at dewiki beta), the API attributes the edit to the IP address, instead of creating a temporary account (which is the intended behaviour). Ideally, after submitting, the temporary banner should as well (alternatively, a refresh can be triggered). Making the temporary account fully transferrable across domains would require a hop over login.wikimedia.org; it is unclear whether preserving one temp account when project-hopping is a MVP requirement.

@Niharika Is preserving one temp account when project-hopping a MVP requirement?

I think our team can take this on @Ladsgroup. Thanks for the offer though!

I agree with @Tchanders - including temp users in this dropdown does not make any value addition for the end user since temporary accounts cannot be added to groups. Once a user starts typing "* Unr....." they will immediate know that temp users are not a valid entry if we don't autocomplete, thus saving them the bother of finding the right user and trying to assign them rights.

But I'm wondering if it's a temporary problem to do with the DB migration, or whether it's likely to persist.

@Tchanders is there someone we can ping to ask about this? If it's a temporary problem then we may not need to do anything here?

In T331058#9107125, @RHo wrote:

Hiya, my 2 cents is that I agree that temp accounts should not be have the ability to mute others, but I am not sure why named users shouldn't be able to mute a temp account if it so happens that a temp account is someone they do not wish to have contact, per the use cases of this feature.

It also seems to make the temp account less than to IP editors, because you can currently mute IPs:

I'm fine with the current choice. We can re-evaluate once this is out to understand what the community deems useful information. Thanks for working on this task.

@RHo it's pending a technical investigation and will require whoever works on CentralAuth to confirm and implement this behavior. It will be captured on the officewiki page once it's confirmed we can do this. Thanks. :)

In T281487#9107574, @Umherirrender wrote:

Just change the wording?

ipb-action-create: Creating new pages and uploading new files
ipb-action-move: Moving pages and files
ipb-action-upload: Uploading files (including overwritting files)

That would fit better for the current implementation and avoids to distinct between upload and reupload (there are also user rights for reupload-own or reupload-shared, but that is blocked as well)

In T343322#9106448, @RHo wrote:

I think there will be a case for a while where there may be a mix of IP and temp accounts existing, esp as the MVP will not happen for all wikis at once, but the temp account is afaik a global creation. So for example, there could be a scenario where someone on say fawiki makes an edit without an account that creates a temp account, then goes to enwiki whilst in that temp account and makes another edit. In that case, what Recent Changes filter on enwiki would capture this person's edit?

Thanks for the presentation! For others who may be looking for a link, the tool is alive here: https://tool-watch.toolforge.org/

We asked an open question for the community on the IP Masking project page and we received feedback from about 10 people. Here's my summary of the feedback we received:

• 2 people said that they feel "~" is a good representation of the temporary nature of temp accounts and we should use that as a prefix. Some others used it in their examples which may indicate they are fine with this.
• 2 people said that "~" prefix could cause confusion because of SUL using them too
• Concern against ! was that it is typically used to indicate "not"
• Concern against '?' was that it is used in other ways that could be confusing
• It is hard to distinguish between an mash, dash, hyphen and minus sign
• Some people said that they are concerned about how long the usernames will get. There is support for using the year as a prefix, not just to shorten usernames but also to add a data point about the user.
• Several people supported the idea of breaking down temp usernames for easy readability such as ~2023~4024~1239
• Several people voiced enthusiasm for having year as prefix - both for identifying temp accounts and for determining how old a temp account may be when interacting with it

Hi! Thanks for adding me @JJMC89. We'll be happy to prioritize this. I'll provide another update here after consulting with my tech lead.

Seems to be done per @STran

In T342475#9046792, @Tchanders wrote:

@Niharika Thanks for outlining that. A couple of follow-up questions:

• If the user wanders off to wiki B, but only ever reads, should they see their temporary account name in the interface?

I don't think so. The idea is to preserve the current experience on wiki B - so it would be best not to create the impression that temp accounts exist on wiki B. It would be misleading to do that when we end up attributing the edits to their IP address when they eventually edit.

• If the user wanders back to wiki A again, should they still be signed in as the same temporary account?

Yes.

In T342475#9044603, @Tchanders wrote:

But if we want the user to act as a normal anonymous user on non-pilot wikis, we need to somehow suppress central login state there.

@Niharika Is this what we want?

• 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.

In T264940#7951797, @MisterSanderson wrote:

Stopped being updated for more than 6 months:
https://analytics.wikimedia.org/published/notebooks/AHT/ptwiki_dashboard.html

This looks good to me. Thalia and I went over it in our 1:1.