Ethics & Impersonation: Alternatives?

Question

Have you ever troubleshoot for your customer and ask (or really want to) their credentials to check their settings if the fault is there? Our solution to this is to implement impersonation feature to login as any users and have access to everything users do. In this case, a mail application. Although we don't need the password to impersonate, I however feel concerned about user's privacy. Mainly 2 things: Their mails and POP3/IMAP settings (which impersonator can get user's gmail/yahoo/etc user and password.

What are other good alternatives/suggestions around this?

Edit:

Some suggested logs. Of course, it's essential component but you can't possibly log everything. Especially because there are so many things to log already not related to user's settings.

Answer 1

You need to have a method for the customer to be able to collect and send their settings to you with their knowlege and consent. Similarly for logs.

There should be no reason to essentially break into a customer's system to 'support' them.

Answer 2

1. The best solution is Michael's above (have a way to dump/report the settings for the user)

2. Another great solution is ablity to CLONE settings of an account into a brand new account. Then you can experiment on clone.

3. Alternately, make sure that the user is actively aware that you have such impersonation capability, signs off on being OK with it, AND signs off explicitly on every usage of it,

Answer 3

I agree with #3 in DVK's answer, but I think he's also missing an essential component: auditing. You should require that your system records your real user name, the person you're impersonating, the time, and an explanation as to why. This data needs to be stored in a place that the users who have the impersonation permission cannot change, so the records can't be falsified. It is much less likely to be abused if people know they can be tracked. You can further decrease the likelihood of abuse by showing this log to the end user who you're impersonating through the app. For instance, if it's a webapp, you could have a section under their profile (private profile) for them to view when and why their account was accessed (perhaps don't expose who, leave that for the investigators on your side). If they see something suspicious in there, they can report it to the appropriate higher-ups at your company and the offending person will be disciplined. Transparency keeps people honest.

Answer 4

Ultimately this comes down to trust. Do you trust your (fellow) employees and yourself?

You can (and should) set up audit trails, and make sure the user knows you have logged on as them, but in any small company (I'm assuming you don't work for Google), it's probable that most of the devs will ultimately have access to the database, and could remove or modify these audits if they really wanted to.

One small way of dealing with this aspect is to take daily backups and send them offsite - then at least you can compare databases if you think someone has been fiddling the books.

Answer 5

Ethics and Impersonation

My take is that a feature that allows you to impersonate someone else is not ... of itself ... unethical. A piece of software is ethically neutral, in the same way that (IMO) a rock is ethically neutral ... even if someone throws it at you!

Ethics comes into the equation in two places:

Q: Is it actually ethical to use the software to impersonate someone else?
A: It depends. If this is done with the full knowledge and permission of everyone concerned, and to achieve an end that is ethical, then it would be hard to argue that the act of impersonation is unethical. But for anything else, the ethics is at the very least debatable.

Q: Is it ethical to write a piece of software that allows you to impersonate someone else? A: If creation of the feature is duly authorised and you have put adequate safeguards in place, then it is arguably ethical. But it is hard to know what constitutes "adequate". But some people would might argue that ethics do not come into the creation of the feature.

These questions are always difficult, and will be debated for ever. But at least you are thinking about the issue ... and looking for a less troublesome alternative.

Answer 6

Read the discussion of the verbose mode in fetchmail in Raymond's "The Art of UNIX Programming". It deals with email settings etc, and explicitly masks out passwords in the trace so that the traces can be sent without compromising the user's security.