Wikipedia talk:Oversight
| This is the talk page for discussing improvements to the Oversight page. |
|
| Archives: 1, 2, 3, 4, 5, 6, 7Auto-archiving period: 6 months |
| For the fastest way to request oversight, send an email to oversight-en-wp |
| To help centralize discussions and keep related topics together, Wikipedia talk:Requests for oversight redirects here. |
| The project page associated with this talk page documents an English Wikipedia policy. It describes a widely accepted standard that all editors should normally follow. Before making a substantial edit to the page, review the policy editing recommendations. |
- Revision history for m:Hiding revisions, which this page borrows heavily from.
Hiding of TA information on request
edit
- 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 436 users with TAIV and the 814 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)
- 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) - 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
Discussion at Wikipedia:Edit filter noticeboard § New option for oversight-level filters introduced to some, if not most wikis
edit
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)
Is it even possible to Oversight a RevisionDeleted (but not suppressed revision)
editIs 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)
- 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)
- 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)
OSPOL 4 and 5
editThe 4th and 5th reasons for requesting Oversight, "Hiding of blatant attack usernames on automated lists and logs" and "Removal of vandalism", have a footnote stating Since tools have since been developed so that administrators can apply deletion norms to all public logs and data fields on the wiki, these criteria might be considered for removal.
A similar note has been there since September 2009 and was updated in September 2010 to reflect the creation of revdel . I think it is time to remove these two reasons, but wanted to gather feedback from active Oversighters first. Toadspike [Talk] 11:14, 25 March 2026 (UTC)
- 4 has been there since
the very beginning of the Oversight page in June 2006October 2009 with the edit summary "this is reality". 5 was added in August 2009 with the edit summary "this is already happening". The history of RevDel and Oversight is a bit messy. As I understand it there was a period when only "Oversighters" had access to revdel, so it's not clear whether 5 was intended to be a reason for oversight or just for revdel (now covered by RD2 and RD3). "Suppression" referred to both tools at the time. Toadspike [Talk] 12:00, 25 March 2026 (UTC)- Perhaps the answer lies in the middle: Sometimes ordinary RevDel is enough, and other times it's not. WhatamIdoing (talk) 15:32, 25 March 2026 (UTC)
- 4 probably refers to use of hideuser, which causes suppression-level removal of a username from automated lists and logs as part of a block, and is separate from revision deleting or individually suppressing usernames on a per-revision basis. -- Ajraddatz (talk) 16:16, 25 March 2026 (UTC)
- Indeed. @Toadspike Oversighters and stewards can block a user with an extra option which removes the username from all logs and page histories in one fell swoop, including Special:ListUsers (which can't be done by admins). HJ Mitchell | Penny for your thoughts? 16:52, 25 March 2026 (UTC)
- Thanks for the explanation. Forgive my ignorance – if a username needs suppression in that way, how often is it sufficient to do that on a local level, as opposed to having a Steward do it globally? Anyhow, if it is clear to OSers that #4 is still needed, then perhaps the outcome here should be to remove the incorrect footnote from that item. Toadspike [Talk] 17:17, 25 March 2026 (UTC)
- @Toadspike there are edge cases but we almost always need a steward because all accounts are global, but our steward friends aren't always available so we often suppress locally while waiting for a steward, especially if the first admin on the scene is an enwiki oversighter. (I say "often", it's not a frequent occurrence thankfully but when it's needed, it's needed.) HJ Mitchell | Penny for your thoughts? 20:19, 25 March 2026 (UTC)
- That makes sense. I've accordingly removed the footnote from criterion 4, as it seems it was not an "interim solution", nor should the criterion be removed. Toadspike [Talk] 22:42, 25 March 2026 (UTC)
- @Toadspike there are edge cases but we almost always need a steward because all accounts are global, but our steward friends aren't always available so we often suppress locally while waiting for a steward, especially if the first admin on the scene is an enwiki oversighter. (I say "often", it's not a frequent occurrence thankfully but when it's needed, it's needed.) HJ Mitchell | Penny for your thoughts? 20:19, 25 March 2026 (UTC)
- Thanks for the explanation. Forgive my ignorance – if a username needs suppression in that way, how often is it sufficient to do that on a local level, as opposed to having a Steward do it globally? Anyhow, if it is clear to OSers that #4 is still needed, then perhaps the outcome here should be to remove the incorrect footnote from that item. Toadspike [Talk] 17:17, 25 March 2026 (UTC)
- Indeed. @Toadspike Oversighters and stewards can block a user with an extra option which removes the username from all logs and page histories in one fell swoop, including Special:ListUsers (which can't be done by admins). HJ Mitchell | Penny for your thoughts? 16:52, 25 March 2026 (UTC)
Edit request (17th April 2026)
editThis edit request to Wikipedia:Requests for oversight has been answered. Set the |answered= parameter to no to reactivate your request. |
In the 'Using IRC', add at the end: 'To use IRC, turn off any open proxy that you are using. Otherwise, you will not be able to connect to the channels. If you must use an open proxy, you will need to use one of the other methods listed on this page'.
This may help open proxy users communicate faster by reducing the chance of them staring at the IRC login wondering why they can't join. QwertyForest (talk) 14:57, 17 April 2026 (UTC)
Not done for now: I'm not sure that's strictly true, as there are multiple web-based options which likely have a way of bypassing the proxy issue. I also don't see anything at Wikipedia:IRC/Tutorial which would indicate this step is necessary. Primefac (talk) 17:15, 17 April 2026 (UTC)
Possible contradiction in Nomenclature section
editThe second para of the section currently reads Page revisions removed with the old Oversight extension did not leave a placeholder in the page history and could not be restored...; Oversight, however, was superseded by RevisionDelete with the new version and deployment of the MediaWiki software in 2009. ... All visibility changes that were made on Wikipedia using the old Oversight extension were migrated over to the updated workflow and hence are visible and reversible
, which seems to contradict itself on the matter of whether or not old Oversight could be reversed. XAM2175 (T) 23:40, 11 May 2026 (UTC)
- The old OS could not be reversed. From my read of that paragraph, when the new OS workflow was introduced the old OS'd revisions were reintroduced and re-suppressed. I could be wrong in my history though. Primefac (talk) 15:49, 12 May 2026 (UTC)
- That's my read as well, but @Risker is not unlikely to know the actual answer. Thryduulf (talk) 19:59, 14 May 2026 (UTC)
- Heh, yes, I know the history. The old oversight software could theoretically be reversed, but only by a developer with the very highest level of access. In practice, it was never done, and we were instructed that it would not ever be done, hence "could not be restored". Edits that were oversighted using the old system were literally moved into another revision table. As the final point in the transition to the revision/deletion/suppression software (which started in February 2009), the edits that had previously been oversighted were reinserted into the usual table as fully suppressed edits (username, edit summary and content), with the normal strikethrough. This conversion happened in 2014. As a result, oversighters can now manage the (old-process) oversighted edits in the same way as we manage any suppressed material. I wrote about the history of oversight in more detail a while ago, and posted details about the conversion in Archive 5 of this page. Risker (talk) 20:30, 14 May 2026 (UTC)
- That's my read as well, but @Risker is not unlikely to know the actual answer. Thryduulf (talk) 19:59, 14 May 2026 (UTC)
Edit Request
editChange to
- Suppress and unsuppress elements of individual page revisions (revision text, username, or edit summary) using an extended option on the RevisionDelete function page.
- Suppress and unsuppress elements of log entries (action / target user or page, log summary, or the username / IP of the user that performed the action) using an extended option on the RevisionDelete function page.
- Suppress and unsuppress individual edit filter logs.
- Suppress a target account's username from all edits and log entries when applying a block to it using the block function page.
- Suppress all edits to a page when deleting it.
- Review the suppression log containing a list of actions taken by all other oversighters involving suppression, as well as the material that was suppressed by that other user.
- Change the visibility of a abuse filter to to 'supresssion' mode
- View all suppressed edits, log entries and abuse filters.
Also change in logging section to include a detail about setting a abuse filter to 'supresssion' mode — Preceding unsigned comment added by ~2026-32881-65 (talk) 11:41, 3 June 2026 (UTC)
- Isn't point 7 (the only addition/change to the list) the same as point 3? Primefac (talk) 21:34, 4 June 2026 (UTC)
What's this on simplewiki oversight policy?
editThe contents may be reviewed by those with oversight rights, though the originally stated intention was that this will only be available for a limited time period.
What's the original intention? suppressed data getting permanently deleted after some time? -- Least Action (talk) 14:33, 14 June 2026 (UTC)
- Sounds like a discussion to have on that page's talk page. Primefac (talk) 17:04, 14 June 2026 (UTC)
- I suspect that this comment about the 2009–2014 history might be relevant. Their policy was written at the start of a major software change. WhatamIdoing (talk) 23:19, 14 June 2026 (UTC)