You spend numerous minutes filling out a multi-page “wizard” for your passport renewal application. You notice that when you click a checkbox somewhere, the whole page pointlessly reloads with the data in the same state. It’s annoying, but you carry on.
You notice an error in your input, but when you put your mouse cursor in the field to edit it, all the input disappears, so you have to start over.
By now you’d like to have a talk with the people who coded this application — even more so, with the people who tested it and declared it production-ready. But you sigh and carry on until the final page, and then…
Lovely, isn’t it? For you non-geeks out there, this type of verbose technical information is often useful to the developers of a program in the course of debugging — although usually only a couple lines of the strack trace are actually relevant to your problem (the function that dumps the stack trace doesn’t know that, so it gives you the whole thing). But you the end user do not know or understand any of this, nor should you. What you should see, if the application pukes, is a polite and vague error message apologizing for the inconvenience, while behind the scenes the technical stuff is saved in a log file or other storage. The geek-speak is just annoying and confusing mumbo-jumbo.
Displaying all the error output is not just bad form. It also leaks internal information that might be useful to a potential attacker. It should be none of our business that State is running
Microsoft .NET Framework Version:2.0.50727.832 and ASP.NET Version:2.0.50727.832 and that it bombs when it tries access an array element that does not exist.
Whether it’s a .NET issue, or an application-level bug, I gotta go. I have a paper passport renewal application to fill out.