In my software, some users deliberately disable certain security provisions or practice bad security practice (such as running the software as root/admin). In the former case there a couple of legitimate reasons for doing this (such as during development) but generally it's a bad idea. For the second there's no good reason.

In the case of security measures being disabled, I've taken deliberately annoy users with a popup that shows up in my software's notification area every time they log in with no option not to show again (some minor features are also disabled), and in the case of running it as admin it will deliberately delay startup by 5 seconds and present the user with a message saying that they shouldn't do so. Same goes for if the software isn't shut down properly.

Is there a better way of dealing with users doing things you really don't want them to (but for short periods of time and in limited circumstances they may need/want to) without deliberately annoying them?

  • 6
    I think the way you are tackling this problem at the moment is more than reasonable. Discouraging this type of behavior is a must, if users get annoyed by the delays and lack of features then if they really want your software, they'll continue to use it the way you intend. Just be sure not to push them too far that they stop altogether. Commented Nov 2, 2012 at 16:03
  • 3
    IMO a one time alert and after that a small visual queue is sufficient. It's the users server; if they want to be insecure after being properly warned, that's their choice Commented Nov 2, 2012 at 19:23
  • @Snuffleupagus: s/queue/cue/ Commented Nov 6, 2012 at 21:50
  • @ChrisMorgan Homophones, every time. Commented Nov 6, 2012 at 21:52

6 Answers 6


What about reseting to the safe behavior after an appropriate interval?

For example, cars have some features that you are allowed to leave 'on' across restarts, but others (e.g. cruise control, seat heaters) must be re-enabled every time you start the car.

In your system you could re-enable the security measures when they log out, if they're really that dangerous to leave off.

Or, you could prompt them for an interval when they ask to disable the measures. LastPass does this: "Don't prompt me for my password for (X) minutes" is an option available when you enter your password. sudo works this way too, only asking for your password if it hasn't been used in the past 5 minutes.


Annoying user experiences are broken user experiences, well intentioned or not.

Why the struggle in the workflow? Why do the users (think they need to) turn off security? Can they do something they aren't otherwise able to do?

Why shouldn't they do what they do? Should they be able to turn off the security? Is there a permissioning solution?

Understanding why your users do what they do is the root of solving this problem. Neither you, nor the user, want to constantly annoy/be annoyed. I am sure not to have the whole picture here, but I'd recommend resolving this experience with research to understand what's happening and reevaluate the interaction design.

  • 2
    My software is controlling another piece of software (specifically a game server), disabling the security (which in this case is centrally authenticating connected players to ensure they are real) allows developers to test their modifications more easily, but also makes it possible for users of pirated copies of the game to connect. So aside from during development (or the auth server is dead) disabling security is to be discouraged as heavily as possible.
    – PhonicUK
    Commented Nov 2, 2012 at 16:40
  • @PhonicUK Once it's on the client's machine, it's difficult to have complete control (reference: all the DRM schemes that have been broken). I suggest rethinking how authentication works...
    – Izkata
    Commented Nov 2, 2012 at 18:30
  • The authentication isn't anything to do with my software, just the other piece of software mine controls. And the piracy isn't a concern anyway. Having that check disabled makes the server vulnerable.
    – PhonicUK
    Commented Nov 2, 2012 at 18:45
  • +1 Annoying user experiences are broken user experiences. @PhonicUK If piracy isn't a concern, perhaps it's not a good idea to list it as a reason, and maybe the users of your software want this kind of behaviour?
    – SpellingD
    Commented Nov 2, 2012 at 21:07
  • 2
    Just because it's not a concern doesn't mean that discouraging is no longer desirable. (Although it's not my software being pirated, but rather the game for the game server) - the issue still remains that I need a way of discouraging certain behaviors or actions.
    – PhonicUK
    Commented Nov 2, 2012 at 22:09

Everything you've described is addressed by the principle of least privilege.

If there is no legitimate reason for your software to start as a privileged user, have it outright refuse to start (or) demand a configuration that permits it to drop privileges once started. This is courteous behavior, as it prevents your software from becoming an attack surface if configured or updated incorrectly.

However, you have to take time to think about why people would want the program to run with privileges. What would be easier for them if they did? Is the installation process incomplete or confusing?

For your second issue, you're dealing with separation of concerns. I'm making the following assumption:

  • Administrators typically don't do things developers would do
  • Developers need a subset of administrator functionality, and additional functionality for development operations

You should not be showing people buttons you do not want them to push. Would it make sense to have a separate kind of user, beyond administrator that could disable the central authentication for a predefined amount of time that would automatically reset? Perhaps a drop down of 15 minutes, 30 minutes, 1 hour? Could their UI be different enough that people would not just login as a developer just to be an admin that could change this setting?

If you could do this, your software would also be courteous, since it automatically reset to a safe configuration if an absent minded developer forgot to do it manually.

Even without more complex ACLs, if it was only possible for people to turn off central authentication for a limited amount of time, you would not need to show annoying warnings. Degrading other features while in this state might make sense, though - depending.

There are always going to be users that insist on doing dangerous things in the name of {apathy, ignorance, intoxication, etc}. You can't stop them, you can only slow them down as gracefully as the work flow permits.

I'd recommend separating devs from admins, but simply attaching a timer to central auth bypass would be a good immediate solution.


Leslie M said

Why do the users (think they need to) turn off security?

Users are lazy. Period. Setting up security right often is not a trivial task so users tend to avoid the hassle:

"Why should I get involved in how to set up my security right when the software runs just fine with security disabled?"

So, basically, there's a simple cost-benefit tradeoff done by the users:

Scenario 1: I run the software w/o security. Benefit: 1) Software runs, 2) no hassle with security settings, subjective goal achievement: 100% Cost: minimum.

Scenario 2: I run the software with proper security. Benefit: 1) Software runs, goal achievement: 100% Cost: 1) Need to learn about security settings and apply them correctly, 2) possibly issues with incorrect settings not showing up directly (like, "What was the password again?!")

Apparently, the subjective benefit for the user is the same in both scenarios. The question therefore is:

  1. Can you reduce the subjective cost for the user in your preferred scenario (#2)? And can you reduce it to or below the cost for scenario #1?

  2. Can you increase the subjective cost for the user in the discouraged scenario (#1)?

Subjective cost or benefit can be influenced in many ways: Big red statements in the documentation saying "YOU WILL PROBABLY BE HACKED IN NO TIME, IF YOU DON'T APPLY THE RECOMMENDED SECURITY MEASURES" may already move the perceived cost/benefit ratio into your preferred direction.

A better solution would of course be to reduce the subjective cost in scenario #2. Maybe some installation/configuration tool or the like can be provided to faciliate the adoption of the 'right' procedures for the user.

After all, I think its a somewhat childish but probably effective approach to go the annoyment way: "Ok, if you are trying to be lazy/smart and avoid the recommended procedures, I will deliberately bug you until you need to re-think your decision."

As was already stated, this is probably not the best solution as for the user experience and will probably actually have negative effects for you or your software on a certain percentage of users, but some trade-off needs to be made, it seems.


Enforcing something on users that they don't want is the most annoying thing a developer or a system can do. I will assume this is a hobby project and you feel you have been called to decide on behalf of your users. This usually comes from developers/admins with autocrative tendencies - I've met a lot of them in my professional career. Most of the time it all boils down to the people having in their minds that they need to enforce something, almost always I figured out that there was no real reasons for certain "security" measures.

Like a month ago, my bank introduced another set of security measures to log into their online banking system. It's annoying for me - the first row of security measures was enough for people that follow rules, have updated AV, don't surf the dodgy sites and are in general smart enough. But because there's a small percentage of retards and incompetent now everyone has to get along with the new annoying security measures. The bank does not offer to turn it off.

Another example - MailChimp just introduced new security measures too. They now require you to provide three (3!) security /password reset questions. I mean, seriously?

I have started to look for software that does not introduce these stupid security overkills and will do the same for the software that I develop.

Obviously, some security is important but we have to stay reasonable with it.

  • It always depends on who the users will be. E.g if the software is a mail server and the user of the administration interface is an administrator then security measures should be enforced on the users. Because if not then all the end users will complain pretty soon because the server got hacked and their email stolen. (e.g. because the admin password was very weak.) But I agree with you on consumer products and software for general usage. Commented Nov 6, 2012 at 23:31

In the context of most software, what you're doing sounds perfectly reasonable, certainly a good idea even. I do this exactly that with software I've written that needs to create mysql accounts, etc, principle of least privileged user as mentioned by someone else.

However, it sounds like you're talking about controlling minecraft servers

Personally, I own a copy of the game, however when I play with friends and someone is over who doesn't have a copy, I have a build altered to skip authentication, just for that instance of the game. I'd personally not use software to control a server that annoyed me constantly when I'm well aware of why I'm allowing cracked copies of the client connecting to my server.

You say "dealing with users doing things you really don't want them to [do]", however IMHO, the needs (and corner cases) of the use should be considered in addition to your views on the ethics of software cracking.

  • You would be right. In case you're familiar with it, it's McMyAdmin. It pops an entry in its left-hand notification area when you log in if the server is in offline mode.
    – PhonicUK
    Commented Nov 6, 2012 at 20:44
  • Nice! I have. That's a pretty nifty piece of software, I have to say. Arguably an entry in the notification area is not entirely obtrusive, but is certainly a fair level of notification to the server admin, the bootup/shutdown times are also a good idea for discouraging offline mode. You could also consider sending a server chat message every 2-5 minutes informing the users of the server that it's in offline mode. Also not so obtrusive but a mild nuisance. Cheers :)
    – EricR
    Commented Nov 6, 2012 at 23:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.