Page MenuHomePhabricator

Make LoginNotify features be global only
Closed, DeclinedPublic

Description

Hi. Now, when decided to make all the features default, there can be a problem. Let's think about a scenario: Some small (or not) wiki decides to remove this from defaults list. It's possible, exactly as our wiki decided to add it to defaults. At this moment, all the users in the world have it as default in the rest wikis, but it doesn't help: each of them can be hacked from this one wiki that removed the defaults, using centralauth. These features work only when they are global. So, I suggest to think about a possibility to make these features global only, when global preferences will be here, so every user can decide if they want it once, on global preferences, and no wiki can't decide for all users. Maybe there is another solution to this problem, but I can't see it now. Thank you.

Event Timeline

Or we just decline the removal of default per wiki per security reasons?

Or we just decline the removal of default per wiki per security reasons?

It will work, but is it "legal"?

IKhitron updated the task description. (Show Details)Sep 12 2017, 8:51 PM

And now we reach a point where we get problems if we treat all Notification settings as one in global contect… You could solve this by using the proposed globalonly feature,but I don't know if it can be assigned to single notifcation points with the current approach.

@IKhitron I'm sorry, I'm not sure that I understand the problem.

The product team should be in charge of changing the defaults; I don't think an individual wiki would be able to turn off a feature without talking to us.

"Global preferences" only involves the individual user making their preference global, for themselves. It doesn't involve a wiki making that choice for all of its members.

I'm glad that you brought up your concern about turning email on by default, and that change is now going to happen. I think that you can relax about this now. It seems to me that you're worrying about things that haven't happened and are unlikely to happen.

Please let me know if I'm misunderstanding something.

@IKhitron I'm sorry, I'm not sure that I understand the problem.

The product team should be in charge of changing the defaults; I don't think an individual wiki would be able to turn off a feature without talking to us.

Please let me know if I'm misunderstanding something.

I think you really are. Of course it will be with talking to you. And if they ask, and you'll do what they ask here is a problem. Because as I understand, you allways execute site requests decided by concensus. If you have a way to decide "all requests for this will be declined ever", as Luke081515 suggested - great, but I have no idea if you have. If undeed you do, I can just rename the task to "Forever decline site requests ...", because if you just remember to declinebdo this - it's fine, but what will be in a hundred years from now? There should be some mechanism to insure that it will never happen, and global preferences is such a possible mechanism. It could be also everything else. Thank you.

@IKhitron A ticket is not a binding contract, and there's no mechanism that will help you to personally overrule community consensus for the next hundred years. Any mechanism put in place right now could be undone later, there's no way to double-lock this decision for all time.

I think that the best thing to do right now is to be happy that we're making the change that you suggested, and to go and work on something else.

@DannyH, is the a way to get some kind of notification: "Some wiki changed it, it doesn't work yet?" I can't read all the tickets in the projectc every week.

@IKhitron What you're suggesting is not a common practice. Wikis don't commonly decide to remove preferences. And even if they change the default, individual users can turn them back on if they like. I don't understand why you think everyone would like receiving notifications about login attempts all the time. For popular accounts this can mean over 50 notifications (or more) per day. It's noise for them. As long as users have a strong password, they don't need to keep getting the notifications.

At this moment, all the users in the world have it as default in the rest wikis, but it doesn't help: each of them can be hacked from this one wiki that removed the defaults, using centralauth.

  1. LoginNotify does NOT stop a user's account from being hacked. It's merely a tool to give them an email about their account was logged into or tried to be logged into.
  2. Until 2 weeks ago, LoginNotify didn't exist. Any account could be hacked from anywhere so even if this hypothetical scenario you are presenting happens, it's no worse than what it was.

@IKhitron What you're suggesting is not a common practice. Wikis don't commonly decide to remove preferences. And even if they change the default, individual users can turn them back on if they like. I don't understand why you think everyone would like receiving notifications about login attempts all the time. For popular accounts this can mean over 50 notifications (or more) per day. It's noise for them. As long as users have a strong password, they don't need to keep getting the notifications.

I don't talk that every user should have it. Not at all. Each one will decide what is better to her. But if there will be at least one user in the world, that want these features, it will be destroyed by this possible desicion of some wiki, because it will work for all the users in the world.

At this moment, all the users in the world have it as default in the rest wikis, but it doesn't help: each of them can be hacked from this one wiki that removed the defaults, using centralauth.

  1. LoginNotify does NOT stop a user's account from being hacked. It's merely a tool to give them an email about their account was logged into or tried to be logged into.

Sure. It helps us to know if the account was hacked.

  1. Until 2 weeks ago, LoginNotify didn't exist. Any account could be hacked from anywhere so even if this hypothetical scenario you are presenting happens, it's no worse than what it was.

Of course. But what is the point to have some new feature if there is a promiss it will stop working one day without any notification.

@IKhitron I don't think you read my comment thoroughly.

What you're suggesting is not a common practice. Wikis don't commonly decide to remove preferences. And even if they change the default, individual users can turn them back on if they like.

I think the hypothetical situation you're presenting here is kinda far-fetched.

In any case, this ticket is a duplicate of T174521: Figure out how to handle preferences that should only have a global scope.

@IKhitron I don't think you read my comment thoroughly.

What you're suggesting is not a common practice. Wikis don't commonly decide to remove preferences. And even if they change the default, individual users can turn them back on if they like.

I think the hypothetical situation you're presenting here is kinda far-fetched.

In any case, this ticket is a duplicate of T174521: Figure out how to handle preferences that should only have a global scope.

I believe my poor English is a problem. I see I can't explain you what am I talking about. I just can assure you that "individual users can turn them back on if they like" is wrong, they can't, because (1) they don't know when it will happen, (2) the problem may happen between the change and the next time they will be online (3) we can't allow one wiki to decide to remove this feature for all other wikis. And also, T174521 has nothing to do with the issue I'm talking about. And I did read you comments, it's just relevant to the issue I'm not talking about.
I belive I can't explain my point, because I'll not talk English much better tomorrow, so the problem will remain. Really sorry for that.

DannyH closed this task as Declined.Sep 13 2017, 6:35 PM

We understand the problem that you're describing. We think the scenario that you describe is unlikely, and that it wouldn't have much impact if it did. We're not going to work on a special notification for this.

I'm going to close this ticket. I think that further discussion about this is not going to be productive; let's go do other things.

Restricted Application removed a subscriber: Liuxinyu970226. · View Herald TranscriptSep 13 2017, 6:35 PM
Dcljr added a comment.Sep 13 2017, 6:35 PM

If I may comment as a largely ignorant "ordinary user": It seems the fundamental issue being argued here is that future configuration changes may "undo" a user's preference choice without their knowledge. So, we should establish (and state explicitly) whether:

  1. configuration changes (of the sort that could be approved) could undo a user's preference choices regarding LoginNotify
  2. such changes could go unnoticed by the user (if yes to #1)
  3. something can be done to make them not go unnoticed by the user (if yes to #2)
  4. something can be done to prevent/discourage such configuration changes in the future (if yes to #1 and #2, and no to #3)

Can we get an explicit "yes" or "no" to each of these?

It seems to me that the answers are: 1. yes, 2. yes, 3. not without new code, and 4. maybe just a well-placed comment in a configuration file? But, of course, I could be very wrong...

A pity, @DannyH. You are very wrong, by I give up.
Thank you very much, @Dcljr, I see you understood exactly what I was talking about. But seems to be too late.

@Dcljr: It's possible but unlikely that #1 could happen. If that is the case, then the person who's making that change can figure out the best way to notify people about that change. There is nothing that we can currently do to constrain that hypothetical future person's actions. Have faith in the future.

Dcljr added a comment.Sep 14 2017, 6:15 PM

OK, that's one of the 4 items. Can someone who knows for sure please respond to #2, #3, and #4?

When we get GlobalPreferences, why don't we define a preference that does only makes sense globaly als global only? I really don't understand at all what's goinf on here.

When we get GlobalPreferences, why don't we define a preference that does only makes sense globaly als global only? I really don't understand at all what's goinf on here.

We haven't yet come across a real use case for a global-only feature.

When we get GlobalPreferences, why don't we define a preference that does only makes sense globaly als global only? I really don't understand at all what's goinf on here.

We haven't yet come across a real use case for a global-only feature.

Well, in my opinion this task seems to provide an actual real use case, doesn't it?

People need to be able to turn off these email notifications if they don't want to receive them. We've turned the email notifications on by default, but people can still turn them off if they want to.

Most users will not use GlobalPreferences, because those users only visit one wiki. In many cases, they don't even know that other wikis exist. Preferences needs to be able to function locally, without forcing people to choose a global preference.

As we have global single user login it is nonsense and irritating if you are allowed to be notified about logins on some wikis, but not on other wikis. Technically, it even kind of is a security flaw.

As we have global single user login it is nonsense and irritating if you are allowed to be notified about logins on some wikis, but not on other wikis. Technically, it even kind of is a security flaw.

  1. It's going to be a global preference when global preferences is launched. You can choose to have it global or not, whatever you like. It's not global only and there is not a real use case for that.
  2. Sometimes automated bots try to hack into accounts. This is much more common on enwiki than say, enwikisource. It's likely I want to block notifications about logins on enwiki since I know my password is pretty good. I would be more curious if a login attempt happened on enwikisource. We know this is a real use case.
  3. It's not a security flaw. The extension is not helping an attacker get into your account. It's notifying you if someone tried to login. That's all. Until this extension was deployed a month ago, there was no way to know about such attempts.