Policy talk:Wikimedia Access to Temporary Account IP Addresses Policy

Archives

1

mw:Talk:Trust and Safety Product/Temporary Accounts
This page is a soft redirect.

Usage template "int string" in the headers

IMHO, selective usage template "int string" in the headers - bad idea.
This about next two:
== {{int string|Background}} ==
== {{int string|Purpose}} ==

As result, these is displayed in UI language anywhere, in conflict with the language of the current page.

I'm propose replace this to a regular texts. Kaganer (talk) 13:56, 7 July 2025 (UTC)

Hi Kaganer. These strings should display in the page's language if they've been translated at the centralized location. E.g. Policy:Wikimedia Access to Temporary Account IP Addresses Policy/ru shows "Предыстория" instead of "Background" for me. -- I tested both logged-in (with my UI-Preferences set to "English") and in a private-window. -- Is it showing "Background" for you? If so, what exact URL is doing so, and which user-preference options are you using that might be affecting it?

The strings are documented and the locations-to-translate-at are linked at m:Template:Int string#Navigation related (with a soft-redirect to there, from the local docs page). There is additional background detail at Wikimedia:Translations guidelines#Translation templates.

The goal of the setup is to reduce duplicate-efforts across dozens of pages, and multiple wikis.

I hope that info helps; I'll tentatively remove the edit-request, for now. Quiddity (WMF) (talk) 21:38, 7 July 2025 (UTC)

I'm knew purpose and benefits of this template. This is useful in lists, table headers and navigation templates. Generally, this is useful in "autotranslated" pages, with contents that depends from UI language.
In this case, please switch UI to any non-english language and open base page Policy:Wikimedia Access to Temporary Account IP Addresses Policy (example for Russian). You will seen these headers in your current UI language, not in English. This is not good. Kaganer (talk) 13:17, 10 July 2025 (UTC)

Also, excluding some headers from the translatable text is makes it more difficult than easier for translators to work.
In turn, all existing translations are already available to translators through the "translation memory" in the form of "translation suggestions".

Usage of {{int string}} is justified where it can be used without the involvement of an translator at all. Kaganer (talk) 13:30, 10 July 2025 (UTC)

Finally, the translation of even one word may depend on the context.
In Russian, in different contexts, short header "Background" may be translated as "История вопроса" (Issue history), "Предпосылки" (Prerequisites), "Общие сведения" (General information), "Контекст проблемы" (Problem context), etc. Usage {{int string}} is prevents the translator from considering the context. Kaganer (talk) 13:38, 10 July 2025 (UTC)

Just a quick "sorry for the ongoing delay" note. You raise some very good points, but it isn't easy to 'fix', and the people that I'd usually turn to for assistance or decision-making are super-busy with Wikimania preparation, new-fiscal-year paperwork, and a bunch of other work... TLDR: It's on my list to get back to. Hope that helps, and thanks again, Quiddity (WMF) (talk) 18:25, 1 August 2025 (UTC)

No problem. This is wiki ;) Some responses may be received after many years...
Over many years of translations in various projects, a lot of experience has been accumulated, including in using the {{int string}} template.
The best practice, in my opinion, is that this template is appropriate...
... in lists (when the entire list consists of such strings)
... in table headers
... to display text elements of the site interface. Kaganer (talk) 11:20, 22 August 2025 (UTC)

Hello @Kaganer - thank you for raising this issue. I think you have brought up some good points. As I suspect you can imagine, this - like the {{int string}} template itself - was an experiment to try and ease translation efforts. However, your point that this could both lead to bad translations and make it harder for translators are compelling. I will ponder how to roll some of these back, and consider this as we roll out more translations in the future. Thank you, @Kaganer for raising this and @Quiddity (WMF) for exploring it and pinging me about it. --Gregory Varnum (Wikimedia Foundation) [he/him] (talk) 17:22, 20 October 2025 (UTC)

The following actions are logged [clarification]

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 or CIDR range.

The first item is a little difficult to understand in the context of the later two. "IP reveal for their account" may be interpreted that people want to reveal their own IP. If possible, this first item may be removed entirely or elaborated further, for example,

• When a user with extended rights (including temporary account IP viewer) configures their account preference to enable or disable IP viewing functionality.

It may also be helpful to clarify if the log is publicly accessible. This helps contrast (or draw a similarity of) the log for Temporary account IP viewer log and CheckUser log.

--Taweetham (talk) 01:51, 6 September 2025 (UTC)

@SGrabarczuk (WMF): I’m not sure if you addressed this clarification question in the section below. If possible, we would appreciate a clearer message in English. Translators do their best, but they may not fully understand what is happening, as they haven't tried TAIV themselves. @Azoma and Tvcccp: I will help with the Thai translation later after the English version is updated. --Taweetham (talk) 00:51, 11 September 2025 (UTC)

Oh, sorry @Taweetham, here's a direct answer:

"When a user accepts the preference that enables or disables IP reveal for their account." - admins and other users with access to temp account IP addresses have a preference on Special:Preferences. I mentioned it in my answer below. Accepting and unaccepting this preference (technically = checking and unchecking a checkbox) enables and disables the "Show IP" button (= "IP reveal" feature). You can read more about the button here.

I will let my colleagues know about your suggestion to reword this. Thank you! SGrabarczuk (WMF) (talk) 22:17, 12 September 2025 (UTC)

Thank you for the clarification. We will update the translation when the materials are ready. --Taweetham (talk) 00:30, 13 September 2025 (UTC)

Removing access [clarification]

Other users who have been given access manually may voluntarily give up their access at any time by visiting Special:Preferences.

I can safely assume from this sentence that the process is immediate and will be logged publicly. However, it is not clear that the removal of access for Temporary account IP viewer (and others?) is permanent via just preference setting. A clarification on this point will be highly appreciated. --Taweetham (talk) 02:31, 6 September 2025 (UTC)

Hey @Taweetham! We need to distinguish between the right and access itself.

• In the case of these users (and not, for example, stewards), access is given to those who go to preferences and check the checkbox. They may at any moment go to preferences again and uncheck it. These actions are logged, but this log is not public.
• Meanwhile, these users have the right all the time. I believe they can't give it up themselves; they need to ask an admin (or a steward) to remove it.

I will check on this with my colleagues. SGrabarczuk (WMF) (talk) 12:01, 9 September 2025 (UTC)

Thank you for your clarification, SGrabarczuk (WMF). I hope that the document could be improved to convey a clear message. --Taweetham (talk) 15:18, 10 September 2025 (UTC)

Proposing another user

Is it permissible to propose another user as a Temporary account IP viewer with their permission? Luurankosoturi (talk) 16:10, 10 September 2025 (UTC)

Hey @Luurankosoturi, thanks for the question. Just to be sure - are you asking if user A can ask for permissions for user B? Well, the policy assumes that the user is active and involved enough to be able to make this request themselves because they need this access. In usual circumstances it wouldn't make much sense to nominate somebody else. Do you know of any case where it'd be needed? SGrabarczuk (WMF) (talk) 22:22, 12 September 2025 (UTC)

Yeah, that's exactly what I asked. The question is based on the idea that a request for access made by another user would be more valuable than one made by the user themselves. So a candidate would look like a better candidate if another user requested them on their behalf, meaning that the requester would also think that the candidate would be a good candidate for access. Luurankosoturi (talk) 14:23, 13 September 2025 (UTC)

Another question: Apparently, only CheckUsers can view the log showing the use of the Temporary account IP viewer rights, so is it their job to monitor the use of the rights? Luurankosoturi (talk) 21:55, 10 September 2025 (UTC)

@Luurankosoturi, they technically can, but they don't have to - it's a matter of practice rather than obligation. Does this answer make sense? SGrabarczuk (WMF) (talk) 22:25, 12 September 2025 (UTC)

I guess I understood it somehow. But why do only CheckUsers see that log? Luurankosoturi (talk) 14:23, 13 September 2025 (UTC)

About this new user right

We have been discussing this new user right a bit in our technical village pump on fiwiki and the following problems have come up. I don't know if any of them have been fixed yet:

• If a temporary account only has deleted edits, then their IP cannot be viewed.
• The background of temporary accounts is only half gray and they are already crossed out, even though it should be after the IP data is deleted after 90 days. This apparently only happens on mobile.

Finally, a problem related to policy and not technology: The policy says to avoid using the tool until the last moment, even if the temporary account violates the rules. The tool is not allowed to be used, even if the IP is not intended to be shared with anyone. IPs have been visible for about 2.5 decades. Why is it suddenly so exact and if it has to be, then shouldn't the IPs of old IP edits also be hidden somehow? The strictness of the policy also contradicts the fact that apparently some functions are such that IPs are automatically visible (e.g. administrators reportedly have an IP auto-detection function in use) and the fact that the minimum requirements are relatively low. I would suggest that the minimum requirements be raised if this would allow the policy to be circumvented. Or is there something here that I don't understand? Luurankosoturi (talk) 15:00, 13 September 2025 (UTC)

If a temporary account only has deleted edits, then their IP cannot be viewed.

Special:Log/newusers and Special:Log/create should contain the IP, even if you don't have access to the deleted page history. TenWhile6 (talk) 15:08, 13 September 2025 (UTC)

Logged actions

@Quiddity (WMF): (cc @MMoss (WMF)) For total clarity, in the "Use of temporary account IP addresses" paragraph, under "The following actions are logged:", imho it should albo be added something like "When a user enables or disables automatically revealing IP addresses of temporary accounts (IP auto-reveal)", since this is actually logged. Thanks! --Superpes15 (talk) 22:39, 18 October 2025 (UTC)

Why should this right be available to non-admins?

IP address access is necessary when making decisions about which IP's to ban which is done by admins who have this right anyway. What's the motivation for giving it to people who aren't admin?

The primary motivation for this right seems to be about protecting privacy. The harder it is to access this right, the less likely is it that an attacker who wants to understand who made edits to retaliate against the user making an edit being able to access the IP address data.

Currently, I don't see any analysis of the tradeoffs and I think it would be good if WMF (@Quiddity (WMF)) analyses what it believes the tradeoffs to be and why it arrived at the current position laid out in this document.

The disclosure section currently speaks about disclosure of the IP address themselves but not about disclosing information related to that an IP address belongs to a certain company or certain geography (and other information the the IP address tool shows). ChristianKl (talk) 16:56, 1 November 2025 (UTC)

Hello @ChristianKl! The main reason is that on a not ignorable number of wikis, non-admins help admins with patrolling. They take the burden of looking for abuse, analyzing behavioral patterns, comparing IPs, and identifying known LTAs, while admins only judge whether the report about the spotted abuse looks correct and hit the button. We don't want to make it more difficult to perform anti-abuse tasks; that's why we made this decision. SGrabarczuk (WMF) (talk) 23:06, 3 November 2025 (UTC)

It is easy to accidentally reveal an IP

I have the TAIV right on en.wiki and I accidentally revealed an IP address. Given that there is strict criteria on looking at an IP and that all usage of such is logged would a confirmation not be a good requirement before showing an IP address, or limiting the button to the account's contribution page? Currently the 'show ip' button is right next to the username. Traumnovelle (talk) 18:50, 5 November 2025 (UTC)

Hello @Traumnovelle! Thanks for your message. Don't worry too much about it - misclicks happen (:t-hanks:)

And more seriously: this is a tradeoff. We prefer to make it easy for patrollers to perform their actions efficiently, quickly and with ease, so requiring additional steps seems to be out of the question. At least for now. We are monitoring the statistics of IP reveal and auto-reveal, though, and at some point we may decide on some changes. Thanks! SGrabarczuk (WMF) (talk) 00:14, 15 November 2025 (UTC)

Two reasons for misclicks that I have experienced are that the 'show ip' button loads later than the rest of the page and that there is a 'box' to click surrounding the text, meaning you may not have your mouse hovered over the 'show ip' text but you can still reveal the IP. I guess the latter relates to making it efficient/easy to perform. Traumnovelle (talk) 01:03, 15 November 2025 (UTC)

Yes, and another reason is that clicking this triggers an action. So it's not a link, so it has the standard design of a button, and these are quite big :) SGrabarczuk (WMF) (talk) 01:26, 15 November 2025 (UTC)

age restrictions

Most other privacy-sensitive privileges come with age restrictions. This one does not seem to. Is this correctly understood, or is it implied somewhere? Effeietsanders 14:49, 2 December 2025 (UTC)

Hey @Effeietsanders. There are no age restrictions for TAIVs. I'll ask my colleagues from Legal if they have considered this, although I'm guessing that because there's no age restriction for the admin rights either, this is an acceptable tradeoff. SGrabarczuk (WMF) (talk) 22:09, 4 December 2025 (UTC)

No reason for age restrictions in any case. Wargo (talk) 14:33, 7 January 2026 (UTC)

Conflict in agreements

Various meta tools are insisting that I must sign the Access to Temporary Account IP Addresses Policy, even though I am a signatory to the ANPDP as an enwiki checkuser and should not need to (nor I think can I) sign the redundant policy. Is there something else I need to do to fix this? Ivanvector (talk) 21:27, 4 December 2025 (UTC)

Never mind, I misclicked. Ivanvector (talk) 21:32, 4 December 2025 (UTC)

Question on acceptable circumstances for checking TA IP

I am considering requesting TAIV rights on EN, but I wanted to be sure on the acceptability of checking IPs under certain circumstances. Mainly, if a TA is showing editing patterns often associated with long-term abuse, but not necessarily a particular LTA case. The main one that comes to mind is an account with only a short editing history making disruptive edits while demonstrating knowledge of Wikipedia policies and procedures that would not be expected from a new editor. TornadoLGS (talk) 04:39, 10 December 2025 (UTC)

If the account does bad things and you suspect there are more I think you can use this feature. In case you suggested these may be also named accounts so it may require to consult CUs if you know who it is and was blocked. Wargo (talk) 14:40, 7 January 2026 (UTC)

Contributions

To minimise display of IP there could be idea to modify IPContribtions to take Temporary User name without knowing or displaying (URL) IP itself.

Displaying contributions of releated TAs without displaying IP and IP infos is under this policy? Wargo (talk) 14:38, 7 January 2026 (UTC)