Deliberately annoying users to discourage certain behaviour. Is this a bad idea?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.