Community Wishlist Survey 2021/Admins and patrollers/Improve display of multiple IPv6 contributions by a single editor

Improve display of multiple IPv6 contributions by a single editor

  • Problem: A single IP editor using an IPv6 connection can have multiple IP addresses, which can change daily, usually without them knowing. However, all those assigned IP addresses fall within "the /64 range", and so all of these contributions belong to just that one user. Unfortunately, Special:Contributions will only display edits from just one of those IP addresses, unless specifically commanded to show them all. The full picture of an editor's contributions is therefore often missing. Without knowing that one can simply add /64 to the end of an IPv6 url at Special:Contributions, it is obvious that admins, vandalism patrollers and any editor interested in the full range of a user's edits are unable to see them, and probably unaware they can be found. The picture of editing is therefore often seriously incomplete. Warnings for bad faith edits can easily be scattered across multiple IP address, and remain hidden from view unless one knows the /64 trick. Even if one IPv6 address gets blocked by an admin, the user can still edit on a more recently assigned address unless the fully range of addresses is blocked (explained in plain English here).
A further problem arises when admins or patrollers work from a mobile phone. From a PC one has to click and manually add '/64' to the end of an IPv6 url in a browser window every time one needs to check an IPv6 editor's full contributions. But on a mobile phone in Desktop View (which most serious editors use) it is not feasible on at least some phones. On an iPhone (and probably many others), even in landscape mode, the url runs off the screen, making insertion of '/64' onto the end of that url quite impossible). Anti-vandalism patrolling of IPv6 users on a mobile phone is therefore severely restricted or impossible to fully achieve because there is no way to display the full contributions of an IPv6 user across the whole /64 range.
Even if IP anonymisation is implemented, there will still be a need to view all of one user's past contributions and talk page warnings related to multiple, changing IPv6 addresses. Knowing their actual IP addresses is not essential to this proposal; it's about seeing them all. Nick Moyes (talk) 15:33, 17 November 2020 (UTC)
  • Who would benefit: All admins, anti-vandalism patrollers, and any editor interested in understanding the range of editing contributions made by the huge number of users who have changing IPv6 addresses.
  • Proposed solution: Provide a clear and very visible button on the Special:Contributions page to permit the easy displaying of all IPv6 edits on the /64 range by that one IP user. e.g. a big, easy-to-click button labelled: Display full range of IP edits by this user which appears whenever IPv6 contributions are shown.
  • More comments: Related to this issue is the inability to see any previous warnings or discussion messages left for a user at an active IPv6 talk page address within the /64 range because it is no longer currently in use. A lot of separate IPv6 talk pages need to be individually opened up to see all those messages. Equally, the IPv6 editor won't be able to see earlier warnings or notices left for them. This closely-related proposal attempts to address that issue.
  • Phabricator tickets:
  • Proposer: Nick Moyes (talk) 12:08, 17 November 2020 (UTC)

Discussion

  • I will add is there a possibility that when I am at an ipV6 address, I can click on the block log to see not only the single ipv6 is blocked or not, but had the range be blocked before. In addition, I will like to be able to block a /64 without the need to remove the last few octets (i.e. a block the range /64) in special block. One more is that it will be ideal if there can be a page created to leave messages for a whole /64 range. These might be beyond the scope of this proposal but worth looking. Thanks much. Camouflaged Mirage (talk) 17:21, 17 November 2020 (UTC)
    @Camouflaged Mirage: Regarding your last point, I did attempt to address that very important need with a separate proposal on this page to 'mirror' talk page contents in some way (See here). Regards, Nick Moyes (talk) 17:31, 17 November 2020 (UTC)
    @Nick Moyes Sure, after I made this comment I read the other page, I agree there is a need to mirror those pages. Camouflaged Mirage (talk) 17:32, 17 November 2020 (UTC)
  • I agree with the gist, but I think Twinkle could probably add this pretty easily. --Izno (talk) 01:03, 21 November 2020 (UTC)
  • I think this should be handed over to the IP Editing: Privacy Enhancement and Abuse Mitigation team. They are actively working on upgrades for these tools. Alsee (talk) 03:48, 21 November 2020 (UTC)
  • As also noted above: Some hosters assign IPv6 addresses within the same net to different customers. --Shoeper (talk) 14:57, 23 November 2020 (UTC)
  • I was going to ask for something similar, but my suggestion is add common CIDR range (/16, /24, /32, /48, /64) links in Special:Contributions EvergreenFir (talk) 06:00, 27 November 2020 (UTC)
  • I support this wholly. As an English Wikipedia checkuser and admin, I am consistently shocked by the behavior of MediaWiki when it comes to IPv6 editing, especially within the same /64 block. In my opinion, /64 ranges should be treated by default for most purposes as a single IP address with a single talk page and a single block setting by default; dealing with /64 ranges within poor technical infrastructure wastes a lot of valuable volunteer administrator time that could be spent elsewhere. Best, KevinL (aka L235 · t) 06:49, 1 December 2020 (UTC)
  • This is useful but care should be taken to avoid giving the impression that /64 blocks equal users; this is not always the case. --Tgr (talk) 03:22, 13 December 2020 (UTC)
    • You're correct that "/64 = one end user" may not be true for all cases, but also note that individual IPv4 addresses do not always equal individual users either. An IPv6 /64 matches closely with the scope of an individual IPv4 address (a /32). Best, KevinL (aka L235 · t) 08:35, 17 December 2020 (UTC)

Voting

  •   Support --Teukros (talk) 17:50, 11 December 2020 (UTC)
  •   Support Camouflaged Mirage (talk) 18:14, 8 December 2020 (UTC)
  •   Support Stryn (talk) 18:22, 8 December 2020 (UTC)
  •   Support Sgd. —Hasley 18:36, 8 December 2020 (UTC)
  •   Support Strong support. It is currently next to impossible for administrators to keep troublesome IPv6 users under control. Furthermore, bad faith unregistered editors have long been a problem from both dynamic IPv4 and IPv6 addresses. It is high time that Wikipedia found a way to determne when the same device was being used on different IPs so that they can be treated as a single user. SpinningSpark 18:48, 8 December 2020 (UTC)
  •   Support ToBeFree (talk) 20:26, 8 December 2020 (UTC)
  •   Support , although it requires that any future IP obfuscation use en:Crypto-PAn or similar. Certes (talk) 20:41, 8 December 2020 (UTC)
  •   Support Absolutely agree with that idea. MarioSuperstar77 (talk) 20:58, 8 December 2020 (UTC)
  •   Support YFdyh000 (talk) 23:15, 8 December 2020 (UTC)
  •   Support BugWarp (talk) 01:25, 9 December 2020 (UTC)
  •   Support Mahir256 (talk) 01:39, 9 December 2020 (UTC)
  •   Support * Pppery * it has begun 01:50, 9 December 2020 (UTC)
  •   Support Thomas Kinz (talk) 09:11, 9 December 2020 (UTC)
  •   Support DEFO support this! Situation is already bad, and only likely to get worse. DoubleGrazing (talk) 09:36, 9 December 2020 (UTC)
  •   Support MisterSynergy (talk) 09:37, 9 December 2020 (UTC)
  •   Support ‐‐1997kB (talk) 12:40, 9 December 2020 (UTC)
  •   Support Monozigote (talk) 17:11, 9 December 2020 (UTC)
  •   Support Cabayi (talk) 20:15, 9 December 2020 (UTC)
  •   Support GeneralNotability (talk) 23:37, 9 December 2020 (UTC)
  •   Support Bonus points for providing a box so that admins can automatically check "Block the /64" for IPv6 contributions CaptainEek Edits Ho Cap'n! 03:36, 10 December 2020 (UTC)
  •   Support - yona B. (D) 07:03, 10 December 2020 (UTC)
  •   Support. Meiræ 15:12, 10 December 2020 (UTC)
  •   Support Hiàn (talk) 18:58, 10 December 2020 (UTC)
  •   Support per my comment above. KevinL (aka L235 · t) 00:58, 11 December 2020 (UTC)
  •   Support Wutsje (talk) 04:25, 11 December 2020 (UTC)
  •   Support Encycloon (talk) 15:13, 11 December 2020 (UTC)
  •   Support Asartea Talk (Enwiki Talk (preferred)) 15:57, 11 December 2020 (UTC)
  •   Support Dreamy Jazz talk to me | enwiki 16:22, 11 December 2020 (UTC)
  •   Support Csigabi (talk) 16:40, 11 December 2020 (UTC)
  •   Support OosWesThoesBes (talk) 17:05, 11 December 2020 (UTC)
  •   Support James Martindale (talk) 17:24, 11 December 2020 (UTC)
  •   Support FabianHorst (talk) 17:42, 11 December 2020 (UTC)
  •   Support ONUnicorn (talk) 18:02, 11 December 2020 (UTC)
  •   Support SD0001 (talk) 20:28, 11 December 2020 (UTC)
  •   Support Xnet1234 (talk) 21:47, 11 December 2020 (UTC)
  •   Support Tgr (talk) 03:22, 13 December 2020 (UTC)
  •   Support, though this may already be taken care off. --Dirk Beetstra T C (en: U, T) 06:01, 13 December 2020 (UTC)
  •   Support ~ Amory (utc) 19:43, 13 December 2020 (UTC)
  •   Support Izno (talk) 20:18, 13 December 2020 (UTC)
  •   Strong support and please make also deleted contribs viewable. --Achim (talk) 09:15, 14 December 2020 (UTC)
  •   Support Novak Watchmen (talk) 17:25, 14 December 2020 (UTC)
  •   SupportThanks for the fish! talkcontribs 22:22, 14 December 2020 (UTC)
  •   Support It will be one good step forward. -Всевидяче Око (talk) 09:01, 15 December 2020 (UTC)
  •   Support Jthekid15 (talk) 09:47, 15 December 2020 (UTC)
  •   Support — Draceane talkcontrib. 12:43, 15 December 2020 (UTC)
  •   Support Bebiezaza (talk) 02:11, 16 December 2020 (UTC)
  •   SupportTeratix 05:52, 16 December 2020 (UTC)
  •   Support Lt2818 (talk) 14:07, 16 December 2020 (UTC)
  •   Support EvergreenFir (talk) 17:31, 16 December 2020 (UTC)
  •   Support Udo T. (talk) 19:52, 16 December 2020 (UTC)
  •   Support Keepcalmandchill (talk) 00:56, 17 December 2020 (UTC)
  •   Support Shenme (talk) 04:40, 17 December 2020 (UTC)
  •   Support - absolutely! Atsme📞📧 11:38, 17 December 2020 (UTC)
  •   Support Quedel (talk) 21:35, 18 December 2020 (UTC)
  •   Support MinervaAustral (talk) 15:28, 19 December 2020 (UTC)
  •   Support Whisperjanes (talk) 04:55, 20 December 2020 (UTC)
  •   Support Geonuch (talk) 13:02, 20 December 2020 (UTC)
  •   Oppose I think investing precious community directed development time before we know how IP masking is going to work is not a good choice. Additionally, I would hope that the team implementing IP masking could build this into that tool again saving us time now. Best, Barkeep49 (talk) 15:52, 20 December 2020 (UTC)
  •   Support Julián L. Páez 01:05, 21 December 2020 (UTC)
  •   Support Juan90264 (talk) 07:58, 21 December 2020 (UTC)
  •   Support NicoScribe (talk) 16:36, 21 December 2020 (UTC)
  •   Support Thibaut (talk) 16:52, 21 December 2020 (UTC)