@Huji: Echo notifications are meant to be transient, not permanent, and I think with LN notifications especially, there is no reason they should be retained indefinitely. It seems like the easiest solution would be to purge all LN notifications after 90 days (the entire notification, not just the event_extra column), possibly with the same clean-up mechanism that purges all notifications after 2000 (per user).

I'm happy to quickly modify my patch to put the IP in event_extra as soon as a 90-day purging script is made for Echo and enabled on WMF.

This task would probably need to be added to includes/jobs/NotificationDeleteJob.php.

@kaldari no. That job is only run when a notification is sent. Even though you might think it is safe to assume that there are so many notifications that the job will be called many times a minute, that is only correct for big projects (such as English Wikipedia). Smalller WMF projects (such as newly created wikis, the Ombudsmen Wiki, etc.) may not have even a single notification for several weeks, and this makes is theoretically possible for us to retain data beyond the retention period.

Therefore, we should do it the right way, which is create a new maintenance script in Notifications (Echo) similar to https://phabricator.wikimedia.org/diffusion/ECHU/browse/master/maintenance/purgeOldData.php and schedule it to be run a regular basis (e.g. daily).

@Huji: Right you are.

if we schedule and require something to run daily, we should probably have an internal error/whistleblower (possibly in NotificationDeleteJob.php) when we detect that such a cleanup script is NOT running.

Hmm, can we just pass cu_changes.cuc_id and load from Checkuser data, thus keeping all the private information in one place?

@MaxSem please see T174388#4048541 in which I explained why that is not possible. Can I ask you to confirm my analysis is correct?

I don't think there would be major privacy concerns

This assumes that all login attempts to the wrong username are malicious. I imagine a lot can be attributed to typos.

This could also be used to extract target users' IP addresses by deliberately registering multiple accounts which are common typos of a target usernames. The chance of success for single user might not be that high, but used against a large list of users it could be successful.

In T174388#4180165, @Esanders wrote:

I don't think there would be major privacy concerns

This assumes that all login attempts to the wrong username are malicious. I imagine a lot can be attributed to typos.

This could also be used to extract target users' IP addresses by deliberately registering multiple accounts which are common typos of a target usernames. The chance of success for single user might not be that high, but used against a large list of users it could be successful.

But we already have a safeguard for that (through AntiSpoof): we don't allow one to create accounts with usernames too similar to an existing account.

AntiSpoof isn't foolproof though, e.g. it disallows Тhryduulf (the first letter is Cyrillic) but probably not Thryduuulf (too many 'u's) or Awkwrad42 (typo for my alt Awkward42).

That is fair.

I wonder how other service providers (such as Facebook or Google) approach this, as we know they have had a similar feature for years.

I would definitely support this. We see it everywhere else, on edits, password resets and so on. So login attempts would be a natural progression. What about 2 Factor authentication for all Wikipedia users also?

In T174388#4181178, @DaneGeld wrote:

I would definitely support this. We see it everywhere else, on edits, password resets and so on. So login attempts would be a natural progression. What about 2 Factor authentication for all Wikipedia users also?

Unfortunately there are scalability issues we need to iron out before we can do something like this. (e.g. when someone forgets their 2FA codes or loses their phone, there is no easy way to get them back without asking a developer to alter the database.)

I'm personally of the opinion that we should have 2FA for all users, but at present there is no failsafe if things go wrong with it.

@Huji any updates? Are you still working on this?

This is still a major issue that needs attention.

@Piotrus: Please feel free to improve the proposed patch if you'd like to see progress. Thanks.

In T174388#6764402, @Aklapper wrote:

@Piotrus: Please feel free to improve the proposed patch if you'd like to see progress. Thanks.

I am all for BOLD I am not a coder. I write Wikipedia articles and I expect coders to make the software so I can continue my work.

@Piotrus: See https://www.mediawiki.org/wiki/Bug_management/Development_prioritization for some background - basically, there is no box full of coders with too much time who could fix all and any incoming bug reports, unfortunately.

Change #419088 abandoned by Thiemo Kreuz (WMDE):

[mediawiki/extensions/LoginNotify@master] Show the IP address of the login attempt in the Echo notification

Reason:

7 years with no further response. Can still be found via the ticket if needed.

https://gerrit.wikimedia.org/r/419088

I think cases like T413747: User reports of ~ 500 failed logins make this necessary.