This is not related to loginwiki specifically but looks like a good place to re-raise it: as long as it's possible to disable the notification, nothing stops the attacker from doing that immediately after login. Echo notifications are put in a queue and notification settings only apply when processing queue items so this would allow circumvention of the notfication if processing time is more than a few hundred milliseconds.
(Of course this is only relevant for warnings about successful logins, not failed ones.)

That's a good point. I'm not sure what a good solution would be other than not allowing disabling the notification, which doesn't seem realistic. People who often log in from different computers will want to disable it. We may just have to live with the fact that it isn't foolproof.

@Reedy, @Bawolff: Would either of you be able to give this the thumbs up from security?

Other sites (Google, Facebook etc) typically do not allow you to disable it. That might require splitting successful and failed login warnings though; as someone pointed out recently, failed logins can be used to spam people with notifications.

The notifications are split into two options:

• Failed login attempts - on by default
• Login from new computer - off by default

As more and more issues come up related to which wiki the notification is generated on (also things like the user would have to alter their pref on every wiki to be effective) I wonder if the design decision of where to generate the notice should be revisited. Maybe it should be jobqueued away to the user's home wiki.

I have no security objections to allowing that right on loginwiki, but kind of worry about the slippery slope.

The idea of generating the notification at the user's home wiki was suggested a while back, but someone pointed out that a lot of people's "home" wiki isn't really their home wiki, so it might not work so well in practice.

In T158871#3052095, @kaldari wrote:

The idea of generating the notification at the user's home wiki was suggested a while back, but someone pointed out that a lot of people's "home" wiki isn't really their home wiki, so it might not work so well in practice.

Aren't crosswiki notifications the default now though? So even if their home wiki isn't the actual wiki they are most active on it would at least be a wiki other than loginwiki and they would be able to go there and change the notification settings.

(This functionality is actually begging for cross-wiki preferences, but that's a different bug.)

(This functionality is actually begging for cross-wiki preferences, but that's a different bug.)

there is toollabs:globalprefs. it could surely expanded to set some or all of the notification prefs?

But this raises another question: If someone tries (and fails) to login on a wiki, where you have not been before and therefore do not yet have a local account, what will happen? no notification, because no account? account gets created, because it exists globally, now triggering a notification, because you haven't set prefs? no notification and no creation, allowing a hacker to circumvent the warning and try until he succeeds?

What if we issued the notification on meta? It sort of makes sense as a "central" wiki. So if my home wiki was dewiki, but I spend 99% most of my time on Commons, and I got pinged on dewiki about unsuccessful login attempts, I might be a little confused (I forgot that's where I originally signed up). But if I got pinged on meta, even though I had never been there, I should be able find out that what it is and why the ping happened there, maybe... Just a thought.

What if we issued the notification on meta?

That makes it likely that people who have disabled global notifications will miss the notification.

But this raises another question: If someone tries (and fails) to login on a wiki, where you have not been before and therefore do not yet have a local account, what will happen?

Hopefully we can answer that question via T158878.

Would it be an option to add a new category of "global" notifications in addition to the local wiki specific ones?

Makes me wonder if Echo really should be used for this. This is more of a system notification, like the one you get when your email address changes.

We can't rely on using a system email notification for this since not all accounts have email addresses. The only on-wiki notification system we have is Echo, so I think it's a reasonable choice. It also has the advantage of easily being configurable (without introducing a new configuration UI). The two main concerns with using Echo seem to be:

1. Spamming - This doesn't seem like an effective way to spam someone. The user can just turn off their failed login notifications, and even if they don't, failed login attempts are heavily throttled. It's much easier to spam someone with Mention or Thanks notifications.
2. Missing the notifications if you have global notifications turned off - Global notifications are on by default and most hacking attempts are likely to happen on the user's home wiki, so this seems like an edge case rather than a blocker.

The string "editmyoptions" doesn't appear anywhere in the mediawiki-config repo. What the heck? How are the preferences disabled on loginwiki?

In T158871#3059747, @kaldari wrote:

The string "editmyoptions" doesn't appear anywhere in the mediawiki-config repo. What the heck? How are the preferences disabled on loginwiki?

https://github.com/wikimedia/operations-mediawiki-config/blob/master/wmf-config/CommonSettings.php#L1195-L1218

Because we just override the lot :)

Change 340258 had a related patch set uploaded (by Kaldari; owner: Kaldari):
Enable editmyoptions right for all users on loginwiki

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

Change 340258 merged by jenkins-bot:
Enable editmyoptions right for all users on loginwiki

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