Wikipedia:Requests for comment/Temporary account IP-viewer

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

(TL;DR) There is consensus for the WMF requirements + demonstrated need for access + admin discretion.

This request for comment focused on what the minimum criteria for granting the temporary account IP viewer permission (TAIV) should be. The RfC was opened with two questions—the criteria for granting and the criteria for revocation. The revocation RfC was closed after the WMF clarified that admins are able to remove the permission without involvement from the stewards, leaving the question of what the requirements for granting the permission should be.

Starting with what was in scope for this RfC: the WMF requirement includes 6 months' tenure, 300 edits, an application for access, opt-in via Special:Preferences, and an agreement to use it only for investigation and prevention of policy and guideline violations. Lowering that was beyond the scope of the RfC, though some editors did take the time to note they felt that this was a very high bar, especially compared to the current minimum of zero requirements, and zero applications, and zero restrictions on the data use.

The rest of the discussion focused on whether we should, as part of enwiki policy, place additional conditions on the grant of TAIV. Three different proposals were floated:

Raising the edit requirement from 300 to 500
Requiring a demonstrated need for access (e.g. SPI, NPP, anti-vandalism)
Giving admins the discretion to decline requests even though they meet whatever requirements are set

There is consensus against adopting an increased edit count. Editors in support of 500 edits noted that this would bring parity with the requirement for an automatic grant of extended confirmed. Editors opposing noted that the WMF had conducted actual research before arriving at the 300 edit count figure, and the jump to 300 edits was already a massive increase on the current requirement of 0 edits. There is no policy-weighting that goes on here, so I would be supervoting if I did not close in favor of the side whose arguments convinced a supermajority of participants (roughly 17 supported 300, while 8 supported 500).

There is weak consensus to require a demonstrated need for access. I count approximately 14 editors who support requiring a demonstrated need for access including, without limitation, SPI, NPP, anti-vandalism, compared to 9 editors who opposed such a requirement. (I understood editors who supported the WMF minimum without relevant elaboration as a !vote against demonstrated need, albeit a !vote without argument.) Those arguing against this largely centered their arguments about the current (lack of) requirements to view this permission, and that if you don't want your IP address to be available, you can create a free account even without providing an email address. Those supporting grounded their arguments in protecting editor privacy—just because we are currently lax about privacy does not mean we cannot become more strict about it, and also wished to avoid fishing expeditions. Again, this is creating policy, so there is limited argument-weighting that I can do. Therefore, I find consensus in favor of the option which convinced 60% of participants. I'll note that this is a weak consensus and "demonstrated need" was neither explicitly defined nor a particularly high bar. Admins should use their judgement about what constitutes a "demonstrated need", but as long as a requester can point to something, this criterion is met.

There is clear and substantial consensus that admins have the discretion to decline the right even if the requirements are met. This is not actually in the WMF minimum, but editors throughout the discussion generally assumed that admins can decline to grant the permission, regardless of whether the account meets the minimum criteria. Nobody really argued the opposite, that admins are unable to decline a request if it meets the policy requirements.

There was no discussion on when the granting can start, but admins already have the technical ability to grant the permission (even if it is useless for the next month) and I don't think we want a flood of applications when IP masking is rolled out. Following the normal rule that changes to policy take effect immediately unless otherwise specified in the proposal, I will set up WP:PERM/TAIV after closing this discussion and it will be open for business immediately. Interested non-admins are welcome to apply.

Respectfully submitted, House Blaster (talk • he/they) 21:14, 2 August 2025 (UTC)[reply]

Discussion preceding this RfC and ongoing discussion about the intersection of TAIV and other user rights.

See also this FAQ.

What should the minimum criteria for granting the TAIV user right right be? 17:01, 21 June 2025 (UTC)

Background

The WMF is removing public access to IP addresses and replacing them with temporary accounts. (This will not affect visibility of IP addresses or edits from before implementation.) Temporary accounts are tied to browser cookies, which are set to expire three months from the first edit. This means that they will be different across web browsers and devices. The WMF has determined that temporary accounts are necessary to protect user privacy and comply with legal requirements, while maintaining the ability to edit Wikimedia sites anonymously.

The WMF has also created a new user right for access to temporary account IP addresses, which has come to be known as temporary account IP-viewer (TAIV). The minimum criteria for editors (other than functionaries, 'crats, and admins) seeking the user right are:

minimum account age of 6 months and 300 edits;
specifically applying for access;
opting in for access via Special:Preferences; and
"[a]gree[ing] to use the IP addresses in accordance with these guidelines, solely for the investigation or prevention of vandalism, abuse, or other violations of Wikimedia Foundation or community policies, and understand[ing] the risks and responsibilities associated with this privilege".

Activation and use of the right will be logged.

Users who are site-blocked will lose the user right. Stewards may revoke the right upon request at meta:Steward requests/Permissions#Removal of access "if the user is determined to have misused the temporary account IP addresses or local community consensus dictates removal." The WMF has clarified below that admins, not just stewards, have the technical capability to remove the right. 20:51, 23 June 2025 (UTC)

Questions

Question 1: Should we adopt the minimum or heightened standards for TAIV? If the latter, please specify.

Question 2: Should we authorize any of the following actors to request removal of TAIV upon evidence of misuse of the right? -- mooted

Option A: the Arbitration Committee or its delegates
Option B: a consensus of (i) functionaries, (ii) 'crats, or (iii) admins
Option C: individual (i) functionaries, (ii) 'crats, or (iii) admins

Survey (Question 1)

Option 1A: (i) 500 edits/6 months and (ii) a demonstrated need for TAIV, as evidenced by counter-vandalism work, participation in NPP or AfC, sock hunting, etc. You should at least have extended confirmed to get this user right. The demonstrated need requirement is to ensure editors have a good track record and prevent abuse up front. I do not believe that we need to specify that editors should not be blocked or banned because I think that should usually be heavily weighed against an editor seeking any permission. voorts (talk/contributions) 17:01, 21 June 2025 (UTC)[reply]
Note: If consensus for option 1A does not develop, I think that we should default to the WMF minimum. voorts (talk/contributions) 21:27, 22 June 2025 (UTC)[reply]

I also think we can trust admins not to grant this right to editors who have had their extended confirmed revoked. voorts (talk/contributions) 22:12, 22 June 2025 (UTC)[reply]

I'm okay with WMF minimum if consensus goes that way, but I still think a "demonstrated need" criterion should be required. Admin discretion is insufficient because that could include "I think editor X is trustworthy so I am granting them this right". But, being trustworthy doesn't mean you do anti-vandalism work, etc., or have a need to look behind the temporary account curtain. voorts (talk/contributions) 22:44, 13 July 2025 (UTC)[reply]
Option 1A per voorts, but I think that logging every single instance of the usage of the right is overkill 𐩣𐩫𐩧𐩨 Abo Yemen (𓃵) 17:13, 21 June 2025 (UTC)[reply]
Option 1A, tho I would still prefer a explicit "not under any kind of sanctions for X months" rider attached, I think the current requirement are okay as a initial blueprint for the community to start with. Sohom (talk) 17:29, 21 June 2025 (UTC)[reply]
Option 1A Our Discussion already tells why. OPHYRIUS ^⚔ 17:48, 21 June 2025 (UTC)[reply]
Meh. One part of me wants to say "Of course we want this as strict as possible", but honestly, there's no practical difference between 6/300 and 6/500. The important thing is that you have to make a specific application; I think we can trust the folks at WP:PERM to exercise good judgement on who they give it to. RoySmith (talk) 18:24, 21 June 2025 (UTC)[reply]
What Voorts said. Seems like a good standard. Mrfoogles (talk) 22:32, 21 June 2025 (UTC)[reply]
What Voorts said but would tie it directly to EC. We already have set 6/500 as a standard here, and it makes sense to just say "must meet Extended Confirmed threshold" rather than create multiple standards. Dennis Brown - 2¢ 00:06, 22 June 2025 (UTC)[reply]
Extended confirmed is 30 days, not 6 months. voorts (talk/contributions) 00:17, 22 June 2025 (UTC)[reply]
I'd prefer the WMF minimum here, 300 edits/6 months. We're still going to have PERM admins reviewing each request and they can exercise their discretion. No need to tie their hands. This right is really no big deal. Toadspike [Talk] 06:57, 22 June 2025 (UTC)[reply]
Minimum. As with Toadspike, I trust that reviewing admins will grant the permission when appropriate. If they judge that an editor with 300 edits has need of, and can be trusted with, the permission then so be it. fifteen thousand two hundred twenty four (talk) 07:11, 22 June 2025 (UTC)[reply]
What Voorts said but with the replacement of "500 edits" with "must be extended-confirmed". For most editors this is equivalent but requiring EC automatically excludes editors who had EC revoked for gaming their edit count. Dan Leonard (talk • contribs) 20:21, 22 June 2025 (UTC)[reply]
EC can be granted early, so this would have to be an additional requirement rather than a replacement. Jruderman (talk) 22:08, 22 June 2025 (UTC)[reply]
I think it should still be a replacement. If an admin feels the need to grant EC early and the WMF minimums are met, then an editor should be eligible. Dan Leonard (talk • contribs) 22:06, 23 June 2025 (UTC)[reply]
WMF minimum plus demonstrated use case at the discretion of the grantor. — rsjaffe 🗣️ 20:29, 22 June 2025 (UTC): amended to include that the request must have a reasonable use case attached to it (such as, but not restricted to, being on NPP). Just like rollbacker requests, want a reason attached to the request. — rsjaffe 🗣️ 22:13, 22 June 2025 (UTC)[reply]
I agree with you here, but this is a basic part of the PERM process, so I'm not sure we need to specify it separately. For example, WP:PERM/R doesn't specifically say that users must explain why they want the right, even though they must. Toadspike [Talk] 09:08, 23 June 2025 (UTC)[reply]
We do need to clarify this. Those in favor of only the minimum are, some explicitly, saying that a request for the permission without any provided reason should still be granted. ~ ToBeFree (talk) 10:21, 14 July 2025 (UTC)[reply]
To expand on my !vote, I meant to say that a requestor should not be required by policy to list their potential use cases in their request. However, I agree there should be a reason to grant the permission, which would be within the administrator's discretion to decide on. For example, if someone says the following at PERM: "Hi, I'm an active at patrolling new pages and recent changes, and I would find this permission useful.", and an administrator verifies this is indeed the case, they should be able to grant the permission. This partially replies to Voorts's comment above. —TechnoSquirrel69 (sigh) 07:23, 19 July 2025 (UTC)[reply]
Minimum. WMF's move is rather absurd — it's hardly a privacy issue when you refuse to log into your own account, or when you refuse to create one — but we're stuck with it. We shouldn't make the situation worse by making users jump through additional hoops. Nyttend (talk) 04:01, 23 June 2025 (UTC)[reply]
Minimum: Whatever WMF sets as the minimum standard should be followed by us. Ofcourse, permission granting administrators can make the judgement of who demonstrates a need for the right, even if they have just 300 edits. In case of misuse, we will also have mechanisms to revoke the right. —CX Zoom[he/him] ^{(let's talk • {C•X})} 20:18, 23 June 2025 (UTC)[reply]
Mininum + demonstrated need – PharyngealImplosive7 (talk) 23:38, 23 June 2025 (UTC)[reply]
Minimum. This is no big deal and requirements should be kept low. Users already must "agree to use the IP addresses in accordance with these guidelines, solely for the investigation or prevention of vandalism, abuse, or other violations of Wikimedia Foundation or community policies", and, assuming their credibility and good faith generally, particular evidence to prove why they "need" to have access is not necessary. Regarding extended confirmed, generally guidelines for permissions are not tied to that, and this permission should not be either. Adumbrativus (talk) 08:36, 24 June 2025 (UTC)[reply]
Minimum. Right now it requires 0 standards, so even the minimum is a huge jump. --Ahecht (TALK
PAGE) 16:28, 24 June 2025 (UTC)[reply]
Minimum plus discretion of granting admin. RoySmith is correct that there is no significant difference between 300 and 500 edits. 300 edits is not a random number; there was research behind the WMF's choice. Let's stick with the research-backed levels, and raise them later if we find that we actually need to. WhatamIdoing (talk) 03:02, 26 June 2025 (UTC)[reply]
Minimum No additional formal/numeric requirement, just discretion of WP:PERM. Leijurv (talk) 22:31, 26 June 2025 (UTC)[reply]
Minimum – I trust the admins will use good judgment when deciding whether to grant TAIV to an editor, so I see no need to expand on the minimum requirement. — Jkudlick ⚓ (talk) 02:04, 29 June 2025 (UTC)[reply]
WMF minimum; what Ahecht said. Best, KevinL (aka L235 · t · c) 22:00, 29 June 2025 (UTC)[reply]
Minimum per Ahecht. An admin should have a reason not to grant, rather than requiring a demonstrated need to grant. Tazerdadog (talk) 01:15, 30 June 2025 (UTC)[reply]
I think the WMF minimum is all we need to have baked into policy. As with every other permission, granting or revoking it is up to the administrator's discretion. I'm neutral on whether the editor must demonstrate a need for the tool in their request. —TechnoSquirrel69 (sigh) 03:58, 30 June 2025 (UTC)[reply]
Minimum per Nyttend, Adumbrativus and Ahecht. Setting aside the debatable necessity of this change, there is no evidence that stricter requirements are called for. It ain't broke. James (^talk/_contribs) 16:02, 5 July 2025 (UTC)[reply]
Minimum will be more than sufficient. ✠ SunDawn ✠ Contact me! 02:09, 8 July 2025 (UTC)[reply]
Minimum plus demonstrated need. Per the WMF policy, the IPs should be accessed on an as-needed basis. To me, allowing access to IPs to users that don't expressly need them is too lax when going by that standard. Warudo (talk) 12:20, 12 July 2025 (UTC)[reply]
Current minimum + demonstrated need. Specifically, I'd like to see a permission request for each of these even if the WMF later decides to allow auto-granting on some wikis. Requiring a demonstrated need prevents the "specifically applying for access" criterion from becoming a joke in the moment one single administrator decides to automatically grant all requests because there is no policy basis for declining any. If IP addresses are hidden by default, unregistered users will likely underestimate the amount of people with access to their approximate physical location and possibly employer or school. Explaining the difference between temporary and registered accounts' privacy will be extremely hard. If you have created an account to hide your IP address, you have done it for a reason new users won't be aware of. It is extremely unusual and unintuitive for a website to allow other users to view your IP address. ~ ToBeFree (talk) 22:21, 13 July 2025 (UTC)[reply]
The declared minimum is overkill as it stands. This doesn't seem to be the place to complain about the WMF ruling, but to the extent that it affects my opinion for this survey, any replacement of IPs (a compulsory component of the internet) with browser cookies (an optional part of some web-interfacing applications) reads to me as a radical, system-breaking change to anonymity on Wikpedia, and the closest we are allowed to remain to the previous status quo, the better. Altoids0 (talk) 19:07, 14 July 2025 (UTC)[reply]
What Voorts said Nothing for me to add here. Ca ^{talk to me!} 15:47, 16 July 2025 (UTC)[reply]
Absolute minimum This isn't exactly sensitive stuff, in my opinion. It's just restoring functionality that all editors have now, and which will be removed without this user group at some point in the future. This should be granted as liberally as possible, given the system of having IP addresses exposed has already worked for decades without issue. EggRoll97 ^(talk) 18:33, 23 July 2025 (UTC)[reply]
The system does have issues, all oversight requests for the removal of IP addresses from revision histories included. ~ ToBeFree (talk) 19:58, 23 July 2025 (UTC)[reply]
Sure, though I wouldn't say that's an issue with the system itself, moreso an issue with people ignoring the big banner that goes You are not logged in. Your IP address will be publicly visible if you make any edits. Even for those who do not have an account (and thus can have edits of a small number oversighted), they could have easily made an account and hidden their IP address anyways. EggRoll97 ^(talk) 21:28, 23 July 2025 (UTC)[reply]
Which is my point above: Try explaining the visibility of IP addresses to users after the change. Especially if we grant this "as liberally as possible". Could you propose a replacement text for the one you quoted? ~ ToBeFree (talk) 08:55, 24 July 2025 (UTC)[reply]
Well, sure, and I think we should improve the messaging regardless, because the default is You are not logged in. Once you make an edit, a temporary account will be created for you. Learn more. Log in or create an account to continue receiving notifications after this account expires, and to access other features. Both that and the current text (the one about IP addresses being publicly visible) aren't ideal, since the current text won't be applicable after the rollout of temporary accounts, and the current temporary account text doesn't really expand on IP address access. I'd instead propose You are not logged in. Once you make an edit, your IP address will be hidden behind a temporary account, but can be viewed by other editors to prevent abuse. Log in or create an account to further secure the privacy of your IP address, continue receiving notifications after this account expires, and to access other features. I doubt that's ideal wording, but maybe a first step. EggRoll97 ^(talk) 18:29, 24 July 2025 (UTC)[reply]
I do like that proposed text! ~ ToBeFree (talk) 16:33, 30 July 2025 (UTC)[reply]
Thanks! I've submitted an edit request at the applicable MediaWiki interface page to change the wording, with some formatting added to keep the existing formatting intact. EggRoll97 ^(talk) 22:50, 30 July 2025 (UTC)[reply]

Discussion (Question 1)

Abo Yemen regarding logging every single instance of the usage of the right is overkill, every time a checkuser views a user's IP address, the access is logged. Surely the same should apply to TAIP. RoySmith (talk) 17:18, 21 June 2025 (UTC)[reply]
Moved from survey section. That is not something that we can change. I believe that the rationale behind logging is that, like CU, the user right provides access to private data. voorts (talk/contributions) 17:16, 21 June 2025 (UTC)[reply]
See wmf:Policy:Wikimedia Access to Temporary Account IP Addresses Policy#Use of temporary account IP addresses:

The following actions are logged:
When a user accepts the preference that enables or disables IP reveal for their account.

Revealing an IP address of a temporary account.

Listing the temporary accounts that are associated with an IP address.
voorts (talk/contributions) 17:24, 21 June 2025 (UTC)[reply]
so basically WP:XC users are going to be the new checkusers? Is there a way to oppose this temp acc proposal altogether? 𐩣𐩫𐩧𐩨 Abo Yemen (𓃵) 17:26, 21 June 2025 (UTC)[reply]
No and no. voorts (talk/contributions) 17:31, 21 June 2025 (UTC)[reply]
): 𐩣𐩫𐩧𐩨 Abo Yemen (𓃵) 17:35, 21 June 2025 (UTC)[reply]

Not by default, only on request at WP:PERM. Sohom (talk) 17:31, 21 June 2025 (UTC)[reply]

An RFC to disable editing without an account. ScottishFinnishRadish (talk) 19:47, 21 June 2025 (UTC)[reply]
I would totally support that. I don't see what value IP editing adds. It certainly doesn't give the editor any additional privacy. If anything, an IP editor has less privacy because their IP address leaks information. With TAIP, the ability to correlate multiple IP addresses leaks a lot more information. And on our side, what we get is a lot more work to manage it, not to mention all the effort that has gone into developing the feature. RoySmith (talk) 21:31, 21 June 2025 (UTC)[reply]
With TAIP, the ability to see multiple IP addresses is still only given to those with special permission, so TAIP users have much less exposure than IP editors do. Remember that checkusers can already see the IPs of people with accounts. With TAIP only checkusers will be able to see the IPs of those without accounts. And the value that IP editing adds is allowing people to edit the encyclopedia with less friction -- less friction means more people working on it, which makes it overall better, ideally. Mrfoogles (talk) 22:30, 21 June 2025 (UTC)[reply]
Re: With TAIP only checkusers will be able to see the IPs of those without accounts I suspect that's not what you intended to say. RoySmith (talk) 23:51, 21 June 2025 (UTC)[reply]

Only real checkusers can look at these logs. JJP_{Mas_ter} (she/they) 04:34, 23 June 2025 (UTC)[reply]
That's not true. The logs are publicly available, as with all logged actions. voorts (talk/contributions) 12:39, 23 June 2025 (UTC)[reply]
Special:Log/checkuser-temporary-account seems to be limited to CUs as of right now - will that change, or am I looking in the wrong place? WindTempos _they ^{(talk • contribs)} 13:02, 23 June 2025 (UTC)[reply]
Nevermind; I was confusing this with the log of blocked IP addresses, which will still be available. See, for example [1]. voorts (talk/contributions) 13:24, 23 June 2025 (UTC)[reply]

I think that most non-admins are going to find that they actually don't "need" this as much as they were thinking, as the more generic information will usually be sufficient.

Every single use will be logged. This is happening so that if an IP address (which is explicitly protected as private information by various countries' laws) turns up, e.g., on an "anonymous" social media post, the WMF should be able to figure out exactly which editor(s) accessed that information. I therefore suggest to editors that they use it when they need it, and not use it when they don't – and to make sure that you don't violate any of the confidentiality rules that you're signing up for. WhatamIdoing (talk) 03:09, 26 June 2025 (UTC)[reply]

Survey (Question 2)

Closing per the WMF's clarification that admins have the technical ability to remove this right and that we do not need to request removal from the stewards. We do not need to address whether these groups can unliaterally request revocation from the stewards, which was the sole point of this question. voorts (talk/contributions) 20:51, 23 June 2025 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

All of the above: Generally, admins can already revoke advanced permissions, and we trust them to do so without abusing that authority. But, since the WMF requires that stewards process removals of TAIV, we should make it our "local community consensus" that a good faith request from any of the above actors "dictates removal" of the user right. voorts (talk/contributions) 17:01, 21 June 2025 (UTC)[reply]
Hey, I wanted to clarify that admins can also remove TAIV: "users authorized to grant such access are also authorized to terminate access" (the third paragraph in the Removing access section). SGrabarczuk (WMF) (talk) 10:03, 23 June 2025 (UTC)[reply]
All of the above. Allowing somebody to view private data means they have the ability to abuse that data (post it publicly, for example). If somebody has gone rogue, the first person (admin, etc) to observe this should be able to prevent further harm by revoking the right quickly. If it turns out they over-reacted, it's easy enough to restore it after some discussion. This is similar to the "tool of first resort" philosophy used by oversighters. RoySmith (talk) 17:24, 21 June 2025 (UTC)[reply]
AotA, What folks above me have said, we should have a zero tolerance policy for mucking around with private data, particularly one that could be used to deanonymize users. Sohom (talk) 17:34, 21 June 2025 (UTC)[reply]
All of Above per RoySmith & Sohom. OPHYRIUS ^⚔ 17:48, 21 June 2025 (UTC)[reply]
All of the above -- it should be easy for anyone admin or above to request removal of permissions like this. Mrfoogles (talk) 22:31, 21 June 2025 (UTC)[reply]
All of the above per the above. Dennis Brown - 2¢ 00:07, 22 June 2025 (UTC)[reply]
All (aka Option C). Admins should be able to yoink TAIV on their own. But ArbCom may have more experience in assessing use/abuse of a tool like this. Toadspike [Talk] 07:01, 22 June 2025 (UTC)[reply]
All per voorts. fifteen thousand two hundred twenty four (talk) 07:17, 22 June 2025 (UTC)[reply]
All of course. Surprised there is a requirement for Stewards to process removals, but, as an optional advanced permission, quick removal is a good thing, so empowering all on that list is good. — rsjaffe 🗣️ 20:27, 22 June 2025 (UTC)[reply]
All of the above, plus the ability to be removed by community consensus at AN or AARV. JJP_{Mas_ter} (she/they) 04:36, 23 June 2025 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Discussion (Question 2)

For those supporting options B and C: if one admin, bureaucrat, or functionary requests removal, can their request be overridden by a consensus of a group of admins, bureaucrats, or functionaries? Do they need to find consensus against removing the privilege, or does a lack of consensus to remove the privilege suffice? isaacl (talk) 16:46, 22 June 2025 (UTC)[reply]
I assume that one could go to Wikipedia:Administrative action review. — rsjaffe 🗣️ 20:26, 22 June 2025 (UTC)[reply]
I agree. This would be the same as any other admin removing a right that they're authorized to. If reversal is necessary, it's easy enough to ask the stewards to give the right back. voorts (talk/contributions) 20:37, 22 June 2025 (UTC)[reply]
In this case, I think option B should be omitted from the actual written policy. The normal collaborative practice is that administrators can take an action on their own initiative, but if a consensus (in most cases, within the community) is determined, then it takes precedence. Option B only allows for a consensus to be established among administrators, bureaucrats, and functionaries. If review is to take place at the administrative action review venue, then the normal collaborative practice suffices. isaacl (talk) 21:43, 22 June 2025 (UTC)[reply]
I think a consensus of functionaries (e.g., on the CU/OS email group if someone reports TAIV abuse concerns to them) should be allowed to authorize revocation of the right. Likewise, a consensus of admins on a user talk page deciding on unblock conditions should be allowed to agree to revoke TAIV. The community shouldn't be overriding functionary determinations (that's for ArbCom and the Ombuds), and they could review a consensus of admins via AN as always. voorts (talk/contributions) 21:51, 22 June 2025 (UTC)[reply]
Sure, but that's a subset of option C, since any individual functionary or admin can implement the consensus from a group of functionaries or admins, just like a group of checkusers today can consult with each other to decide on implementing a block. I agree it make sense that functionary decisions to revoke the privilege, which could be based on private information, shouldn't be reviewable by the community. isaacl (talk) 02:12, 23 June 2025 (UTC)[reply]
Given @Szymon's comment above, I think this question is now a moot point. Any objections to closing it? voorts (talk/contributions) 12:37, 23 June 2025 (UTC)[reply]
Although any admin may be technically capable of removing the privilege, the community still needs to establish a process of how to decide when it should be removed: can an individual admin decide on removal, or does it have to be a community consensus? Can checkusers and oversighters act unilaterally (with any review to be performed by the arbitration committee)? (I'm not sure if bureaucrats should be in a different category than admins for this process.) isaacl (talk) 16:44, 23 June 2025 (UTC)[reply]
Well the question was framed as "who can ask the stewards to remove it", but now that we know we don't need the stewards, the question being presented here is incorrect/inapt. Additionally, why do we need to decide on if admins can remove the right? Admins are already the ones who will be granting the right and can remove it. Why should this user right be different than other ones? voorts (talk/contributions) 16:51, 23 June 2025 (UTC)[reply]
To me, who pushes the buttons is a distinct issue from the decision-making process. So I think the idea that the user right should be handled the same as the current ones still applies even if a request had to be made to the stewards to actually remove the privilege. Question 2 seemed to me to be examining other decision-making processes, but I agree a version of it is not needed if no one wants to consider other processes. isaacl (talk) 17:34, 23 June 2025 (UTC)[reply]
I really think we ought to handle this just like any other ordinary, sub-admin permission. That includes individual admins removing it when they deem that appropriate. And just like any other ordinary, sub-admin user right, if someone loses it and wants to complain, they can follow the same processes that we use now. Reinventing the wheel is unnecessary. Just make this be a normal user right, handled in the normal ways. WhatamIdoing (talk) 03:12, 26 June 2025 (UTC)[reply]
Sure; with the withdrawal of question 2, I don't think anyone is proposing a different process. isaacl (talk) 04:09, 26 June 2025 (UTC)[reply]

General discussion

Notified: Wikipedia:Administrators' noticeboard, Wikipedia talk:Requests for permissions, Wikipedia talk:User groups, Wikipedia:Village pump (policy), Wikipedia:Village pump (proposals), Wikipedia:Village pump (WMF), Template:Centralized discussion. voorts (talk/contributions) 17:06, 21 June 2025 (UTC)[reply]

It has been more than a month since the RFC started, but in the preceding discussion, I had asked about a separate page for requesting IP viewing. However, no one replied. I am asking about it again, as it's not long before TAs are implemented here in September.

For example, take User:MaplesyrupSushi(intentional ping for suggestions). They hunt socks of Jisshu, but they don't request any hat. If a TA is acting like Jisshu & they don't want TAIV, they'll have to request someone. Who'll they request & when it'll be done, no one knows. Instead if they request at such pages, the work can be faster. This is just like request check by CUs. Ophyrius (he/him
T • C • G) 17:08, 22 July 2025 (UTC)[reply]

Obviously a page at PERM to request the right will be created. voorts (talk/contributions) 18:09, 22 July 2025 (UTC)[reply]

Yeah, there's no reason to use a different place. Possible shortcuts could be WP:PERM/IP and WP:PERM/TAIV. ~ ToBeFree (talk) 18:22, 22 July 2025 (UTC)[reply]

@ToBeFree, WP:PERM/TA is already one! Ophyrius (he/him
T • C • G) 10:59, 23 July 2025 (UTC)[reply]

I misunderstood your comment. SPI will still exist. Admins and others with TAIV will be able to assist there. voorts (talk/contributions) 18:29, 22 July 2025 (UTC)[reply]

A dedicated requests page might be fine. But TAIV requests may just be made at the talk pages of individual admins or TAIV holders. —CX Zoom[he/him] ^{(let's talk • {C•X})} 18:48, 22 July 2025 (UTC)[reply]

That’s okay, but often a check needs to be performed for reasons other than sockpuppetry, so we may require a different page. That’s the question. Ophyrius (he/him
T • C • G) 10:51, 23 July 2025 (UTC)[reply]

@CX Zoom and Voorts: I don't see any concerns about its creation for now, so should we proceed with making it or not? Ophyrius (he/him
T • C • G) 13:27, 24 July 2025 (UTC)[reply]

Create what? voorts (talk/contributions) 15:09, 24 July 2025 (UTC)[reply]

a dedicated test page Isn't that, what we're discussing about? Ophyrius (he/him
T • C • G) 16:54, 24 July 2025 (UTC)[reply]

Why do we need a separate page to request use of TAIV? If someone suspects socking, they can go to SPI and anyone with the user right can use the tool. Creating a separate page would just lead to confusion and potentially duplicated efforts. voorts (talk/contributions) 17:42, 24 July 2025 (UTC)[reply]

Multiple people have said that suspected socking is not the only reason why someone may want to request TAIV. There are two ways we can deal with this.

Deal with all requests for TAIV at SPI. This runs the risk of at least two sorts of misunderstanding:
- TAIVs saying there isn't socking when nobody suspected there was any (a different question was being asked) and/or declining to run a check because there is no suspicion of socking.
- People incorrectly believing they are being accusing of socking/an editor is accusing someone else of socking when they are not.
Have two venues - one for suspected socking, one for other requests. This runs the risk of confusion and possibly duplicated effort (e.g. if socking is discovered while a different question is being asked).

My gut feeling is that option 2 is the better option, with less likelihood of confusion and lower consequences from misunderstandings, however I've never been active at SPI or AIV. Thryduulf (talk) 18:15, 24 July 2025 (UTC)[reply]

Why would anyone need to know if two TAs are linked to one IP unless they're thinking socking is occuring? TAIV users can't share IP addresses (except in limited circumstances) per the WMF policy. And, what would the person who lacks access to TAIV be able to do with the limited information that they can be provided other than file a report at SPI? Given those questions, I'm wondering why anyone who can't impose a block would need the user right at all. voorts (talk/contributions) 18:23, 24 July 2025 (UTC)[reply]

Is it not more proper to just ban anonymous editing? If Wikimedia is going to enforce this without our consent, we might as well do that.... --Rockstone^{Send me a message!} 20:49, 23 July 2025 (UTC)[reply]
There are fears of an increase of vandalism/sockpuppetry etc., and if – after the introduction of temporary accounts – these fears turn out to be true, then such measures would probably be discussed. The Wikimedia Foundation could also just ban logged-out editing without our consent, so I'm not sure if that aspect is a valid argument. ~ ToBeFree (talk) 09:05, 24 July 2025 (UTC)[reply]
There's already TAs on nl-wiki. We can ask them if they've seen any effect on socking etc. since the change. voorts (talk/contributions) 15:10, 24 July 2025 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.