I've got a bit of an argument at my workplace and I'm trying to figure out who is right, and what is the right thing to do.
Context: an intranet web application that our customers use for accounting and other ERP stuff.
I'm of the opinion that an error message presented to the user (when things crash) should include as much information as possible, including the stack trace. Of course, it has to start with a nice "An Error has occurred, please submit the below information to the developers" in large, friendly letters.
My reasoning is that a screenshot of the crashed application will often be the only easily available source of information. Sure, you can try to get a hold of the client's systems administrator(s), attempt to explain where your log files are, etc, but that will probably be slow and painful (talking to the client representatives mostly is).
Also, having an immediate and full information is extremely useful in development, where you don't have to go hunting through the log files to find what you need on every exception. (But that could be solved with a configuration switch.)
Unfortunately there has been some kind of "Security audit" (no idea how they did that without the sources… but whatever), and they complained about the full exception messages citing them as a security threat. Naturally, the clients (at least one that I know of) has taken this at face value and now demands that the messages be cleaned.
I fail to see how a potential attacker could use a stack trace to figure anything out he couldn't have figured out before. Are there any examples, any documented proof of anyone ever doing that? I think that we should fight this foolish idea, but perhaps I'm the fool here, so…
Who's right?
Best Answer
I tend to build an application log, either in DB or in file, and log all such information to that. You can then give the user an error number, which identifies which log item the error is related to, so you can get it back. This pattern is also useful as you can follow errors even if the users don't bother raising them with you, so you can get a better idea of where the problems are.
If your site is installed in a client's environment and you can't reach it, you can get the on-site IT dept to send you some extract based on the error no.
The other thing you could consider is having the system email details of errors to a mailbox that you have sight of, so you know when things are going wrong.
Fundamentally having a system that spills its guts when something isn't right doesn't inspire confidence in non-technical users - it tends to scare them into thinking something is very wrong (eg how much of a BSOD do you understand, and how do you feel when one comes up)?
On stacktrace:
In .Net the stack trace will show the full trace right into the core MS sourced assemblies, and will reveal details about what technologies you're using, and possible versions as well. This gives intruders valuable info on possible weaknesses that could be exploited.