Wikipedia talk:Oversight

Warning
This page is not the proper place to request suppression from the oversight team!
Never make such a request by editing a Wikipedia page or by creating a discussion on an Oversighter's public user talk page. You must contact an Oversighter through private channels to report an edit that should be suppressed. Please review the proper instructions at Wikipedia:Requests for oversight for more information.
Warning

Phone numbers/email: really oversightable?

I want to revisit this discussion on people voluntarily disclosing their phone numbers/email addresses.

I have been doing a lot of talk page cleanup lately. Some of it involves cleaning up revdel/oversightable posts, many including personal information. (To be clear, I am referring here to edits on active talk pages, not on talk page archives. PII is not really common in archives for whatever reason.)

Recently I reviewed the list of criteria, and noticed that phone numbers are included in the list of oversightable material. This feels like a lower bar than current practice, although obviously I don't know all of it. More importantly, I don't think people realize the extent of the issue. I have not been requesting oversight on any comments containing phone numbers unless there's something else going on (e.g. a personal threat), because there are literally thousands of them.

For context, I'd say that 90% of these instances are adults who voluntarily post their phone number, who definitely don't understand the nature of the project, but who may or may not realize their phone number is publicly and permanently online. (There's often a language barrier.) How high-profile these talk pages are varies, but seems to skew toward the lower end, with some exceptions e.g., pages for politicians and celebrities.

Personally, I think this should be removed from the list of criteria, or at least have some kind of "case-by-case basis" language added, but I can see both sides of the issue, so I wanted to bring it up again. (To be clear, I am not asking for permission to start emailing about this; I would strongly prefer to not send thousands of requests and I'm sure everyone would prefer not to receive them.) Gnomingstuff (talk) 16:47, 17 April 2025 (UTC)[reply]

Absolutely suppressible/oversightable. In fact, under the current policies, it's really the only correct way to do it; PII isn't a criterion for revision deletion. Realistically, these numbers and email addresses are very, very easily abused. People are notoriously bad at realizing how public (and scrape-able) Wikipedia pages really are, and there are a lot of people who really have a poor concept of personal information security.

On the other hand, in the majority of cases, revision-deletion should probably be adequate to clean up that information; I don't really imagine any administrators worth their salt would be handing out those details, or even bothering to look at them in most cases. Perhaps it is worth advocating to make it a revision-deletion criterion. It is certainly acceptable to revdelete when identified as a first step to requesting suppression. Risker (talk) 23:06, 17 April 2025 (UTC)[reply]

+1 here, I'm in support of adding a revdel criteria for single identifiers (e.g. only an email, only a phone number, etc) - with of course always allowing for OS when appropriate. FWIW, globally that is the general response you will get from stewards when "an email" or "a phone number" is found on a small project. It can certainly become disruptive to someone for those to be live published, even if it is "your own" identifier. — xaosflux Talk 13:59, 18 April 2025 (UTC)[reply]
Yeah revision deletion seems more appropriate, the vast majority of this stuff is very mundane and I would hope most admins meet the bar of "does not do identity theft."
My other concern, which I forgot to mention earlier, is that a lot of these edits are very old -- like, as far back as 2004-2005 old -- and as I understand it sometimes you'd have to revision delete everything in between, which might end up being the whole talk page. This would make any subtle undetected vandalism or blanked comments almost impossible to find. I don't know if there's a solution for this and I can see the argument that abusing people's IRL personal info is more important. Gnomingstuff (talk) 19:18, 18 April 2025 (UTC)[reply]
Edits from 2004 have been mirrored and forked across the web. And the spammer's harvester bots will have found the information long ago, anyway. After a certain point, suppression just draws attention. Suffusion of Yellow (talk) 20:28, 18 April 2025 (UTC)[reply]
Yes, you're correct on that point Suffusion of Yellow. We look at situations individually, bearing this in mind. The real objective would be to catch these things within days or weeks, rather than months or years. Any suggestions on how to improve editor/admin education on this point would be really helpful. Risker (talk) 22:06, 18 April 2025 (UTC)[reply]
Unfortunately the answer is probably "more people doing it."
For newer talk page edits, the search query insource:"11 april 2025" returns all the edits from that day with an amount of text in the preview that's usually enough to tell whether an edit is questionable (the insource does that to the preview). It isn't perfect but it's better than nothing. I work through that backlog continuously although I'm about a week behind at the moment. But I think I might literally be the only person who is. Gnomingstuff (talk) 23:01, 18 April 2025 (UTC)[reply]
Just to be clear I agree, I personally don't think that someone's email address from that long ago is worth the nuclear option. But it's probably worth revising the policy text to add some kind of "on a case by case basis" language to reflect actual practice. Gnomingstuff (talk) 00:03, 19 April 2025 (UTC)[reply]
As a comment on the age thing, I agree with Risker that OS or RD is probably going to shine a light on it, but absolutely by all means it should be removed from the live page (with a neutral edit summary), even if it's a decade old. Primefac (talk) 21:51, 19 April 2025 (UTC)[reply]
I have a question about "neutral edit summaries."
Recently I have been scolded about removing comments. I really, really, really do not want to be scolded by people. Thus, I now feel the need to defend my reasoning in the edit summary, in order to make a case that it is indeed reasoning made in good faith. However, these edits sometimes contain personal information, and leaving a more detailed and non-generic summary seems at odds with not drawing attention to them. How should I handle this? The only alternative I can think of is to keep an offline running list with said reasoning that I can refer to if people yell at me again. An example (made up, not real): someone has an old edit with their email address, asking a lawyer for his fees and telling the lawyer to contact them, and I need to explain that this is not someone suggesting that the lawyer's fees be added to the article. Gnomingstuff (talk) 06:15, 27 April 2025 (UTC)[reply]
No procedure handles all situations. If removing personal identifying information (or it may be malicious, if someone else's phone number has been given), I recommend using a bland edit summary such as "off-topic" or "inappropriate", or even "fix". As you know, editing archives is controversial and people are going to occasionally complain whatever is done. Don't worry about it. If someone complains about removal of a phone number with a misleading edit summary, point them to this discussion. Johnuniq (talk) 08:22, 27 April 2025 (UTC)[reply]
If someone is scolding you (or anyone) for making a neutral edit summary and it's fairly fecking obvious why you made the edit, then they are in the wrong and need to be more careful about their vitriol about vague edit summaries. Primefac (talk) 13:27, 27 April 2025 (UTC)[reply]
In addition to what Risker says, pretty much the only phone numbers and email addresses we don't suppress are those that are very clearly intended to be public points of contact, almost always for organisations. Thryduulf (talk) 23:11, 17 April 2025 (UTC)[reply]
I see quite a few phone numbers (and the occasional e-mail or other PII) in edit summaries. These could be deleted (or oversighted if really bad), even if old, without affecting other revisions. Certes (talk) 13:14, 27 April 2025 (UTC)[reply]

How are oversighters audited

Oversighters during their free time can view suppressed content without other stewards or wikimedia foundation knowing. Some may be software serial keys so do oversighters get them for free because they have worked hard in Wikipedia? 23.162.200.141 (talk) 08:21, 16 July 2025 (UTC)[reply]

Eg: oversighters view suppressed revisions because they are curious. Unlike checkusers, they are not audited for viewing it. 23.162.200.141 (talk) 08:22, 16 July 2025 (UTC)[reply]
There are about 500 revisions suppressed each month. Almost none of those are software serial keys. I'm not even sure why you think people are posting that sort of thing. No one is going to riffle through 500+ suppressed revisions just on the off chance that they can get a free copy of Microsoft Excel. If they really wanted to, sure, they could do it, but we (the Oversight Team) have much better things to do with our time. Our monthly audit of the numbers doesn't even look at the why, just the quantity. Primefac (talk) 23:03, 16 July 2025 (UTC)[reply]

Hiding of TA information on request

 

  • IP data of editors who accidentally logged out and thus inadvertently revealed their own IP addresses.
  • IP data of editors without an account on request, provided that the edits were made recently and are relatively small in number.

Hello all, with the implementation of temporary accounts the Oversight Team has determined that we need to update our policies, specifically the latter points of OSPOL #1 (quoted above). At current we are mostly in agreement that simply changing "IP data" to "TA account information" (or similar) for the first bullet point (i.e. accidental logged-out editing) is an easy update, but we wanted to ask the Community on how best to deal with users who have never had an account who do not want their TA shown (the second bullet). The entire point of TAs are to provide a first-level defence against showing an IP address, though obviously the 377 users with TAIV and the 822 administrators can still view it. Is this safeguard, combined with the various notices when editing while logged out, enough to remove this second bullet point? Should the criteria be modified/updated? Thanks! Primefac (talk) 01:23, 17 December 2025 (UTC)[reply]

Personally speaking, I don't think the second bullet point is necessary any more; people concerned with their IP addresses being shown no longer have them shown. Administrators and TAIV are very unlikely to be the individuals that are performing political persecution ...[or] denial-of-service attacks against editors, and if there really are legitimate reasons for someone to have their TA hidden we can always make that exception at the time following an internal discussion among the OSers. Primefac (talk) 01:23, 17 December 2025 (UTC)[reply]
I think we might benefit from getting some data under our belts before making a final decision. It's been a long while since I went through and tried to classify the types of requests we get through the VRT queue; my impression has been that the number of requests from unregistered users to have their IP hidden was slowly but steadily rising until we started the TA experiment. I haven't looked closely enough at tickets that have come in the last 6-8 weeks to see how much they've dropped off, but my impression is that they're down. This is something I can work on over the year-end period; we should have about 8-10 weeks of data by then, which should give us a reasonable sense of impact. My gut sense is that the unregistered user has to be pretty savvy about Wikipedia to be aware that there are a group of around 1100 users who are still able to see their underlying IP despite it being masked publicly, and to be seriously concerned about info that will no longer be available after that 90 days; there aren't going to be many people who fall into that category. Good idea to start this discussion. Risker (talk) 02:44, 17 December 2025 (UTC)[reply]
Waiting before spending much time thinking about it seems desirable to me. I can see that the spirit of the first point might be retained for someone able to provide a plausible reason why their privacy is so critical that they have to have their TA removed (if privacy is that important, why are they editing with a method that could fail so easily?). I would favor not removing TA information in general because it is just unproductive work. If WMF Legal want it done, forward requests to them. Johnuniq (talk) 03:34, 17 December 2025 (UTC)[reply]
We should absolutely keep the first bullet and update it to say TA. The second bullet feels really unnecessary to me. I suppose we can wait for data, but I don't think the benefits outweigh the potential for abuse. Toadspike [Talk] 19:27, 20 December 2025 (UTC)[reply]
I'm not sure that a simple substitution is the right call.
  • For the first ("Oops, I posted while logged out"), I wouldn't expect people to be too concerned about suppressing the "User:~2025-12345-67" part. I'd expect them to be concerned about the "TAIV folks can see my IP address and might realize that IP address 233.252.0.18 could be used to trace User:Alice!" part rather than the "User:~2025-12345-67 is User:Alice!" part. In that case, keeping the TA username visible, but hiding the IP information from TAIVs might be sufficient (if possible, and if not possible, maybe it should be), or maybe some way to suppress the TA username only for the ~90 days until the IP information expires. Also: Is suppressing the TA username sufficient? Could a TAIV look up IP information from a self-chosen/random TA username? Are there tools that show edits from nearby-ish IPs? If so, then suppressing the TA username might not meet the goal.
  • For the second, I wonder what an unregistered user would be trying to hide, and from whom. I doubt that people want to hide the TA username itself. And I doubt that they know enough about internal structures to make an informed decision about hiding their IP address from TAIVs when it will still be visible to CUs and devs.
WhatamIdoing (talk) 01:29, 24 December 2025 (UTC)[reply]
If the TA is hidden, the IP is hidden. As far as I can tell there is no way to suppress/hide the IP without hiding the associated TA. I have no issue with showing the TA (since the whole point is to keep the IP information hidden to almost everyone) but since they're directly linked there's really not much we can do other than all/nothing. As far as "temporary suppression", I have zero interest in attempting to keep track of which TAs were suppressed so we can go back three months later and un-suppress them purely because the IP information is no longer attached. Primefac (talk) 18:52, 24 December 2025 (UTC)[reply]
I'm not familiar with the interface. If a username is hidden (e.g., grayed out lines at ANI), I can still type Special:Contributions/Username and look up information about the editor. I have to know the editor's username/IP address/TA name, but I can still do this. Is that true for suppressed TAs? WhatamIdoing (talk) 03:04, 25 December 2025 (UTC)[reply]
If a username has been suppressed, it will not show up in a user's contributions for anyone other than an OSer. To choose a random example, Special:Contribs/2601:84:8100:BAE0:91E9:ED72:F24E:7213 shows no edits, but they do have hidden contributions. Similarly, there should be no way for you to know who made this edit, and even if you did somehow manage to guess the TA and/or IP of the user who made it it would not show up on their contribution page. Primefac (talk) 12:45, 25 December 2025 (UTC)[reply]
It sounds like suppressing the TA username is sufficient. I wish we could suppress the IP address without suppressing the TA name. WhatamIdoing (talk) 01:56, 26 December 2025 (UTC)[reply]
  • As promised above, I did a bit of quick-and-dirty data review, specifically comparing VRT tickets sent to the Oversight queue in December 2024 as compared with December 2025, to get an early sense of how TAs have affected oversighter workload.

Some qualification on the data: This is a small sample. The number of tickets generated each month is highly variable, as is the nature of those requests. VRT is only one route by which oversight requests are received. The number of actionable requests is not directly related to the number of suppressions carried out; many actionable tickets will require multiple suppressions across several pages. Many tickets resulted in other non-oversight actions such as revision-deletion, page deletion, or account blocking; these actions are NOT included in the table below. The Oversight queue, like most other VRT queues, gets a non-negligible amount of spam. It also receives a fair number of tickets that are out-of-scope or refer to another project, and the oversighters do their best to redirect those tickets to the right place.

Type of request December 2024 December 2025
TOTAL REQUESTS 198 185
Actionable with OS 131 120
Related to minor 35% 26%
Other personal info 24% 67%
Other (see below) 17% 18%
IP address 24% N/A
Temp Acct request (number) 3 (see below)
Other (see below): includes suppressible-level harassment, suppressible-level BLP violations, outing, threats of harm, and a few other unclassifiable but actionable requests.
Temporary account requests: Three (3) requests received, two from never-registered users which were not actioned and one from a registered user who accidentally edited logged-out and was actioned.

Based on this comparative snapshot, we are simply not getting that many requests for suppressing TA data to spend too much time looking for a reason to not suppress the few requests we receive. On the other hand, good arguments have been made above for differentiating between never-registered editors and registered editors. I am not sure it really matters. What is notable is that IP address suppression made up nearly a quarter of the oversighter workload in the past, and I think most oversighters would agree this change in pattern was immediately noticeable and appreciated. Risker (talk) 06:46, 7 January 2026 (UTC)[reply]

Thanks for this analysis. Also, congrats to the OS folks on having a quarter of their workload relieved. WhatamIdoing (talk) 22:31, 7 January 2026 (UTC)[reply]
Well, technically, things mostly shifted around. There's actually only a 7% difference in number of tickets between these months a year apart. Most of the reduction from the removal of the IP address suppression requests was balanced out by significant increase in the number of "personal information" requests. Risker (talk) 00:33, 9 January 2026 (UTC)[reply]
Thanks, Risker. Now that we have the data, I am even more strongly in favor of removing "IP data of editors without an account on request, provided that the edits were made recently and are relatively small in number." Toadspike [Talk] 09:36, 8 January 2026 (UTC)[reply]
We could replace it with an explanation saying that "the IP data of editors without a registered account will automatically be removed 90 days after the most recent logged action" (though we should double check the technical details). WhatamIdoing (talk) 22:03, 8 January 2026 (UTC)[reply]

 You are invited to join the discussion at Wikipedia:Edit filter noticeboard § New option for oversight-level filters introduced to some, if not most wikis. Codename Noreste (chat) 02:12, 9 January 2026 (UTC)[reply]

Is it even possible to Oversight a RevisionDeleted (but not suppressed revision)

Is it even possible to Oversight a RevisionDeleted (but not suppressed revision). That means a revision that both ADMINS and OVERSIGHTERS can see but not the public. ~2026-88624-2 (talk) 10:24, 9 February 2026 (UTC)[reply]

That would just be revision deleted without suppression; suppression is only needed to also restrict from administrators. — xaosflux Talk 11:26, 9 February 2026 (UTC)[reply]
The table at WP:Oversight#Nomenclature clearly shows who can view what when each tool has been used. Thryduulf (talk) 12:11, 9 February 2026 (UTC)[reply]