Community Wishlist Survey 2021/Archive/Mirror contents of previous IPv6 talk page when a new address is assigned

From Meta, a Wikimedia project coordination wiki

Mirror contents of previous IPv6 talk page when a new address is assigned

NoN Conflicts with IP Editing: Privacy Enhancement and Abuse Mitigation project

  • Problem: A single IP editor using an IPv6 connection can have multiple IP addresses on the /64 range, which can change daily, usually without them knowing (as explained in this closely-related proposal). Warnings and messages left for one IPv6 address on the /64 range are not readily visible, either to the IP user themselves, or to other editors once a new IP address gets automatically reassigned. Without looking at the entire contributions made by one person on the /64 range, and then accessing individual talk pages to check for past warnings on each page, it is not possible to determine the level of good or bad faith editing by that user.
  • Who would benefit: All admins, anti-vandalism patrollers and any editor interested in understanding the range of editing contributions and warnings left for IPv6 users operating on one /64 range, but who have innumerable (and frequently shifting) IPv6 addresses within that range. The IP editor themselves would also benefit from better communication from other editors should they look at their currently assigned IPv6 talk page and see messages left for them at the talk page of the previously active address.
  • Proposed solution: The contents of the most recently-assigned IPv6 talk page should be automatically mirrored (copied) to the talk page of the next, newly assigned IPv6 address operated by that same user within the single /64 range. This mirroring process would be repeated with the next, newly assigned IPv6 addresses used by that single user, so that warnings and notices (unless intentionally deleted) would be carried forward, just one step at a time, to the next active address. :
(If technically possible, the editing histories of each of the previously allocated IP addresses within that range would be made to accumulate, so that the current IPv6 address contains the edit histories of all the past addresses operated by that user within the single /64 range. But this inability to easily view all edits made across a user's /64 range has been partly addressed by this closely-related proposal to add a clearly visible 'Display full range of IP edits by this user button at Special:Contributions. In this way, each new IPv6 address, operated on a single user's /64 range, would contain an accumulation of any warnings and messages on its talk page, built up from carrying forward past messages from the previously active address, plus an accumulation of all that range's IP contributions)

Discussion

I would only comment that one does not need to know the specific address of an editor, but one does need to be able to readily see all the warnings and messages left for one user across their multiple, changing IPv6 addresses, whether anonymised or not. Nick Moyes (talk) 15:33, 17 November 2020 (UTC)[reply]
  • I am adding phab:T112325 as I believe that's basically what you're asking for. However I echo Matěj Suchánek's concerns about conflicts with the Privacy Enhancement project. Following the aforementioned task, you end up at the TechCom-RFC for IPv6 talk pages which got merged into RFC: Create temporary accounts for anonymous editors. Considering the whole concept of IPs is in question, so are the talk pages, hence this proposal may not be appropriate for this year's survey. MusikAnimal (WMF) (talk) 22:56, 17 November 2020 (UTC)[reply]
  • Perhaps what we really need is a single User_talk: page for each /64, just as every logged-out device in my home will see the same page for our shared IPv4 address. That can still work with anonymity if a prefix-preserving IP mangler such as en:Crypto-PAn is deployed. Certes (talk) 00:09, 23 November 2020 (UTC)[reply]
  • Note that there are also hosters assigning IPv6 addresses within the same net to different customers. --Shoeper (talk) 14:50, 23 November 2020 (UTC)[reply]
  • Even if just visible to admins, knowing that IPs in a certain range (especially on /64 blocks of IPv6) would be immensely helpful. Or a link we could click (similar to the notification of previous blocks) that alert is to warnings in that range. I've encountered IPv6 users who've received nearly a dozen level-1 warnings across as many IPs. A similar feature for previous individual IP blocks within the range would be helpful too. EvergreenFir (talk) 06:06, 27 November 2020 (UTC)[reply]
  • 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:48, 1 December 2020 (UTC)[reply]
  • After discussing with the team, we believe the level of effort involved to solve this won't be worth the while given the future of IPs is uncertain. As we understand it, the plan for privacy enhancement will basically solve this wish through session-based temporary accounts. Don't quote me on that, though! All we know is we can't devote significant time to IP-related things right now. Improve display of multiple IPv6 contributions by a single editor on the other hand is a very simple wish to solve and we are happy to work on that. Sorry we can't help, and thanks for participating in the survey, MusikAnimal (WMF) (talk) 01:13, 3 December 2020 (UTC)[reply]
    • @MusikAnimal (WMF): "we believe the level of effort involved to solve this won't be worth the while given the future of IPs is uncertain": However, having a community opinion on whether this should be taken into consideration by the developers of the current effort. I again urge you to quickly consider the option of having a full wishlist where afterwards you make a top ## for problems for the wishlist team to work on, and a top ## that developers/WMF should prioritize (and there is then nothing wrong with pre-sorting these as 'this should be thrown in the general direction of WMF/developers', and 'this can be done by this team'). --Dirk Beetstra T C (en: U, T) 06:02, 3 December 2020 (UTC)[reply]
      They are aware :) The manager of the Anti-Harassment Tools team and the director of engineering was present in our meeting and they recommended archiving this as it would basically have to be done anyway as part of the privacy enhancement project. There's no need to keep reiterating the concept of a "full wishlist"; we agree and plan to broaden the scope next year, as I've said repeatedly. It has been a pretty stressful survey this year, so I really appreciate your cooperation. Thank you! MusikAnimal (WMF) (talk) 16:59, 3 December 2020 (UTC)[reply]