Page MenuHomePhabricator

Design an auto-reveal mode for temporary account IPs
Closed, ResolvedPublic

Description

User story

As an Admin patrolling vandalism from temp accounts on the wikis, I want to enable an "auto-reveal IP mode", so that I can quickly identify IPs that belong to the same range/area and determine the best way to block bad actors.

Requirements

  • Users can enable/disable an "auto-reveal IP mode" that will display all IP addresses associated with temp accounts for a limited time.
  • The permission to "auto-reveal IPs" will be temporary and the 'session time' set by the user.
  • The UI will make it clear to the user when they are in this mode.
  • Users will be informed when the permission is about to expire and can choose to extend it if needed.

Design specs

  • User clicks link in tools menu to enable and dialog displays
  • Session duration can be set to 30 minutes or 1 hour
  • Once enabled, a persistent icon button will display in the bottom-right of the screen.
  • Clicking the icon button launches a panel with the following components:
    • Countdown timer
    • Button to extend session duration
    • Button to disable the mode
  • A reminder message displays in the panel 20 seconds before the duration is due to end.
  • User can disable the feature by clicking the "turn off" button that displays in the bottom-right panel, or by clicking the link in tools menu.

Design (Figma)

auto-reveal-final-flow-17Mar.png (3×8 px, 2 MB)

Questions

See competitor review

  • How long should auto-reveal IP mode last once enabled?
  • What length of time can users set when enabling the mode, and is there a limit?
  • Will auto-reveal IP mode automatically end after a certain period of inactivity?
  • Where and how should users be reminded when their session is about to expire?
  • How do we ensure we comply with WCAG standards (see WCAG 2.2.1 / timing adjustable)?

Checklist

  • Competitor review
  • Design exploration
  • Review with team
  • Test and refine
  • Finalise design

Related Objects

Event Timeline

@Urbanecm I'd love to get your thoughts on this idea for enabling IP Auto-reveal mode:

auto-reveal-7nov.png (2×4 px, 813 KB)

It's similar to the popup widget that appears for Watchlist. Icon is placeholder for now!

I'm not sure if we can place an icon in the top bar (is this something to ask Web team about?), perhaps we could consider placing an icon next to Watchlist instead. I explored having the setting in Preferences but my concern is that it won't be immediately accessible. If a dialog reminder is too intrusive then we could use a toast message instead.

KColeman-WMF changed the task status from Open to In Progress.Nov 7 2024, 11:35 PM

Thanks for the ping @KColeman-WMF! I like this. Several questions popped to my mind

  • Duration: The default is 10 minutes. What are the other choices? This would be useful when you are in a patrolling session, which rarely takes 10 minutes.
  • Persistence: What happens if I enable this at English Wikipedia and then go to Czech Wikipedia? Would autoreveal be still enabled, or not? I'd expect it to be a single mode across all Wikimedia sites (at least, make that an option for users with global access).
  • Logging: How would we log access in this case? Would we be logging every single reveal? Or would we log the start and end of the autoreveal session? Latter would be my preference.

Having this in the top bar seems OK to me. I'm also thinking about the Tools menu, but that has page-specific tools, so probably not too appropriate for this case. Same for next to watchlist. Maybe in the left menu? But anyway: where it is right now looks good to me, if Web agrees :).

  • Duration: The default is 10 minutes. What are the other choices? This would be useful when you are in a patrolling session, which rarely takes 10 minutes.

I'm interested to know what time limits you would suggest?

  • Persistence: What happens if I enable this at English Wikipedia and then go to Czech Wikipedia? Would autoreveal be still enabled, or not? I'd expect it to be a single mode across all Wikimedia sites (at least, make that an option for users with global access).

Yes I agree, my understanding is that autoreveal should persist across wikis for those who have global access.

  • Logging: How would we log access in this case? Would we be logging every single reveal? Or would we log the start and end of the autoreveal session? Latter would be my preference.

Your proposal to log at the start and end makes sense to me.

Having this in the top bar seems OK to me. I'm also thinking about the Tools menu, but that has page-specific tools, so probably not too appropriate for this case. Same for next to watchlist. Maybe in the left menu? But anyway: where it is right now looks good to me, if Web agrees :).

I will speak to Web about the best location for an icon, thanks for the feedback and questions!

  • Duration: The default is 10 minutes. What are the other choices? This would be useful when you are in a patrolling session, which rarely takes 10 minutes.

How about 15 minutes as a default and 30, 45 and 60 minutes as other choices?

  • Persistence: What happens if I enable this at English Wikipedia and then go to Czech Wikipedia? Would autoreveal be still enabled, or not? I'd expect it to be a single mode across all Wikimedia sites (at least, make that an option for users with global access).

+1 to what @KColeman-WMF said. I will run this by Legal just to be sure.

  • Logging: How would we log access in this case? Would we be logging every single reveal? Or would we log the start and end of the autoreveal session? Latter would be my preference.

We discussed this a bit in T358853: Temporary accounts: Automatically resolve temporary account names to IP addresses on displaying (auto reveal feature) and recall settling on logging every instance to begin with. We can explore our options if we see the logs getting too many too quickly.

@Niharika and @Urbanecm - with regards how long the session should last, I have also explored using a persistent toast message with buttons to add time and extend a session. If we set a longer duration for the initial selection, I wonder how many minutes would make sense for extending a session?

Toast mockup:

auto-reveal-toast.png (394×1 px, 137 KB)

Imho, as a patroller and admin, default duration should at least 30 minutes, to avoid unnecessary clicks. There are two use cases: if we only need the reveal for a short amount of time, we don't need auto-reveal; if we are in a patroll session, we need auto-reveal for more than 15 minutes.

Imho, as a patroller and admin, default duration should at least 30 minutes, to avoid unnecessary clicks. There are two use cases: if we only need the reveal for a short amount of time, we don't need auto-reveal; if we are in a patroll session, we need auto-reveal for more than 15 minutes.

Thanks for the feedback, that's very useful to know. What do you think would be the maximum time needed? If 30 minutes is the default minimum.

@KColeman-WMF I was somehow embarrassed to answer that question, you will understand why. But for patrol sessions, I think 1 hour is enough as a maximum. (If you want I can ask other fr-wp patrollers.)

But thinking about this (the maximum needed) make me wonder: why not letting this access permanently?

Let me explain myself: years ago, as a patroller and sysop, I was doing real patrol sessions on recent changes, with a start and a finish. That's one use case. I still do sometimes, but now, most of the time, I don't do real patrol sessions on RC: every day, along the day, I check manual vandalism reports, automatic reports of reverted editors, and edits blocked by AF. (And as we often need to block IP ranges and open proxies, I will always need to check IP behind the temp account.) That's another use case. Maybe more common for sysops or stewards?

For the first use case, the auto-reveal mode, with a limited time, is perfectly fine. But for the second use case, it makes no sense, as we would still have to enable it again and again the same day, so 24 hours auto-reveal tool would be more suitable. But if there is a 24-hours auto-reveal mode, why not make it permanent? Maybe it wouldn't be OK for Legal? (Even if I don't see a real difference with a 1 hour auto-reveal session. Maybe, then, more strict criterias should be considered.)

I know my reply goes beyond the scope of this ticket, sorry; I hope it still helps.

@Jules78120 Thanks for sharing your experiences - that helps a lot. For the second type of work, would a typical day involve just doing some sessions of anti-abuse work, or would you also be doing other things on the wiki, not related to anti-abuse work?

I think our concerns about keeping it on permanently were to help ensure that IPs are only revealed for anti-abuse purposes. If we make it easy to leave it on by accident then we could have situations where a user is doing something else on the site but still revealing IPs. I think we had concerns about:

  • Violating the policy by revealing IPs while not doing anti-abuse work
  • Making lots of log entries (each reveal is logged per temp account, per 24 hours: T325658) which has technical difficulties (T358853#10109273) and could make oversighting use of the tool more difficult
  • Violating the privacy of the user using auto-reveal, since their activity would be logged

@Tchanders: Most of the time, I would be doing other things on the wiki, unrelated to anti-abuse work.

And I understand your point: that would lead to see IPs when it's not needed nor wanted, and to create log entries each time IPs are displayed. But to be fair, the same will be true for the first use case: when on a patrol session, it often happens that we (or at least I, but I guess it's the same for other patrollers) do other things on the wiki, like reading the village pump, replying to a message on our talkpage, etc. This would also lead to show IPs (and log it) when it's not needed nor wanted.

But I guess the shorter the auto-reveal duration is, the smallest the number of unwanted IPs showed will be.

Thank you for sharing your thoughts @Jules78120, it's much appreciated and very useful.

You may be interested to see some of the current ideas (all feedback welcome!):

Design route (click to see prototype)MockupProsCons
A. New icon in personal bar
A. Icon in personal bar.png (3×4 px, 1 MB)
Feature can be enabled/disabled in the same place. Status can be indicated (i.e. coloured icon).Some users have lots going on in the personal bar (with gadgets etc), would adding another icon be distracting?
B. Link in tools menu
B. Link in tools menu.png (3×4 px, 1 MB)
Can easily add a link to Tools and this area could be extended in the future to contain more Admin tools.Quite hidden (which could also be a pro as this is a sensitive feature). Where should it appear on mobile (e.g. settings, advanced mode)? Status cannot be visually indicated unless clicking the link again.
C. Enable in appearance menu
C. Appearance menu.png (3×4 px, 1 MB)
This new feature arguably affects content appearing and it would mean we don’t add another icon to the personal bar (which can get quite busy for users with gadgets etc).It makes the menu quite long on desktop view. Not sure everyone will know to look here. Status cannot be visually indicated unless clicking the menu again.

Hello @KColeman-WMF Design A seems the best (the more convenient) to me.

In my experience, it's the tools section (B) which is crowded (moreover with gadgets, and I do have some showing in this section); the personal bar is free of any gadget in my (heavily customized) account.

I get the logic of C (pros), but I second the fact it's not convenient (cons). And beyond the specific area dedicated to Auto-reveal feture, this whole menu is not "easy to read" because it displays over the main content (article area). It's OK as it's not a menu we should go often, but it does'nt seem appropriate for the Auto-reveal feature that should be "within reach".

Note that I'm on desktop.

Option A in T374869#10399269 adds an icon to the personal bar. One concern that was raised about this idea was where this would go on mobile, and also how well an extra icon would fit on narrow screens even on a desktop skin.

Does anyone have a feel for how likely it is someone would be using this feature on mobile? My instinct is that it would mostly be used on desktop, but this may be wrong.

In my experience, it's the tools section (B) which is crowded (moreover with gadgets, and I do have some showing in this section); the personal bar is free of any gadget in my (heavily customized) account.

Thank you for taking the time to feedback @Jules78120. :) It's interesting that you mention Tools being more crowded than personal bar. I wonder how many others have a similarly busy Tools menu. If you would like to ask fr-wp patrollers for their preference on the design options, please do.

Note that I'm on desktop.

That's useful to know. Our assumption is that most patrollers with this permission will be using IP Auto-Reveal on desktop (we have heard a preference for desktop over mobile in the past).

Hello, I agree with @Jules78120. The option A seems to me the best one as status would be visible on the same as enabling/disable with ease of access for those who are authorized to use it.

Regards

Thank you for your feedback on this. There is some concern about the icon being so prominent in the personal bar and how it will display across all skins.

With that in mind, there is one further option (D) that combines options A and B:

Option D (Figma prototype):

  • Users enable the feature in Tools menu
  • Status icon then appears in personal bar as a persistent reminder that the mode is enabled
  • Clicking status icon would launch a small dialog so users can see time remaining and extend/disable the feature
  • Clicking link in Tools menu would launch a full screen dialog to extend/disable the feature

D. Link in tools and icon.png (3×6 px, 1 MB)

We can also provide a reminder when the time remaining is nearly finished. A full dialog reminder might be too intrusive so we could use notifications or a smaller dialog.

Interested to hear any thoughts on this approach. Thanks!

@KColeman-WMF FYI I left a message on the fr-wp BULPAT.

If option A is not possible, then option D seems OK to me.

We spoke to @Jdlrobson-WMF from the Web Team about the most popular proposals - personal bar and tools menu in the sidebar. Below is a summary.

Personal bar is problematic:

  • Adding more into the personal bar is problematic. It is not intended to be arbitrarily extensible. There is already a lot of clutter, and the Web Team is making an effort to clear it. TSP would need help from the Web Team now, and it may need moving to somewhere else in the future.
  • Much testing is built around anon vs registered. We may need to add test cases for users with particular privileges.

Tools side bar is a good place to put this:

  • There are plans to extend this in the future. Users already use it for tools.
  • Main challenge is figuring out how we would indicate status.

Other areas that are recommended to extend:

  • Bottom right (e.g. Growth suggested edits) - making this extensible is WIP, e.g. how would multiple tools interact? But it is intended to be extended and Web Team can offer help.
  • Banner area at top (e.g. Collection extension)
  • Subtitle

Given the constraints outlined previously, there are two new proposals. Both options ensure that:

  • The feature works across skins
  • It is added to UI that is intended to accommodate additional features in the future

Our preference is towards option 2 as the Web team has indicated that the bottom right is intended as an extensible area. The help panel, works in a similar way.

Option 1 (Figma prototype)
  • Users enable the feature by clicking link in Tools menu
  • Top bar (not sticky) appears with status icon and buttons as a persistent reminder that the mode is enabled
  • Clicking buttons in top bar would extend/disable the feature
  • Clicking link in Tools menu would launch a full screen dialog to extend/disable the feature

Design option 1.png (3×7 px, 1 MB)

Option 2 (Figma prototype)
  • Users enable the feature by clicking link in Tools menu
  • Sticky button and panel appears bottom-right as a persistent reminder that the mode is enabled
  • Panel can be collapsed easily by clicking button
  • Users can extend/disable the feature using buttons in the panel
  • Clicking link in Tools menu would launch a full screen dialog to extend/disable the feature

Design option 2.png (3×7 px, 1 MB)

We are keen to hear any preferences / feedback on these two final options?

The second option uses an icon on the button. The icon should convey:

  • Location/IP addresses
  • On/enabled state

Here are some ideas:

image.png (418×1 px, 43 KB)

Update:

We have made the decision to go with option 2: adding a link in tools menu to enable/disable auto-reveal mode, and showing a status indicator in bottom right tools area.

This is because:

  • The tools menu and bottom right area are intended to be extensible
  • The tools menu works reliably across skins
  • User feedback found that a persistent status indicator, ease of access and reliability across skins were important.

I shared the icons with Stewards and the favourite is F (temp user icon with pin).

For mobile, I've created T384733: Minerva should officially support #p-dock-bottom in prep for that so you don't have any issues updating on mobile. Here's a patch minus unit tests.

@Tchanders if you need a PHP hook as well, that should also be straightforward to add with a few modifications to Vector and Minerva.
We can also add to other skins via similar patches if needed.

I'm closing this design task as we have a separate task for finalising the remaining product specs: T385823: IP Auto-reveal: finalise remaining product specs