This could very well include complete SQL statements, "secret" parameter names, file paths, and lots of other potentially harmful things.

Could you explain to me how SQL statements can help a cracker if your program is well written? After all, you do use quote methods or placeholders, and you check data before using it -- or don't you?

The same goes for file paths. I see no problem in telling that my home page is located at /vhost/juerd/juerd.nl/index.plp. Does knowing the path enable you to use files that can't be read by my apache daemon? If my code was written badly, you could guess the number of times you need "../" to get to the root directory, but my code doesn't use paths without checking (or even parsing) them first, so that information is completely useless.

Secret parameter names in your code are often a sign of bad programming too. Do you put your SQL passwords in your code, or somewhere safe, with nice 403 error messages if anyone tries to get it through http?

To avoid being cracked, it's better to conceal version numbers than source code. After all, Apache's entire source code is open, MySQL's source is completely disclosed, and so is Perl's. Why hide parts of your own source if those parts can help debug?

Not to the user - the user should get a friendly "Sorry" screen, with instructions to try again

Yes, the user should get a "try again" and a "sorry". But some users, like me, hate to not know what's going on. If I'm going to report a bug, I'm going to report it in great detail. If there's no information, I never report it - I assume some automatic e-mail is being sent, because if the author wanted me to report the bug and does not send error e-mails automatically, he'd have included the information he needs to fix it.

I don't like using Microsoft Windows. Why? Because since the very first General Protection Fault I ever saw, to the recent blue screens and Fatal Exceptions, I have absolutely no idea about what goes wrong when something goes wrong.

Not all users are Teletubbies saying "uh oh" and "again" when something goes wrong. There should be a friendly message for those who are, but there should be detailed information for those who like to know more.

This site uses error IDs, which apparently are mapped to some place in a log. I have seen quite a few after the server move, and it was annoying. The only thing I could do was paste the message, while I would have liked to be able to suggest a fix, or at least have a clue about what error I had triggered.

When I get an e-mail message with a bug report from one of the sites I maintain, and the user was smart enough to supply all information, I can often fix it within a few minutes. If I get an error-ID (I tried several methods of reporting bugs), I have no idea if the bug is going to be huge or tiny, and I'm not motivated at all to fix it.

U28geW91IGNhbiBhbGwgcm90MTMgY
W5kIHBhY2soKS4gQnV0IGRvIHlvdS
ByZWNvZ25pc2UgQmFzZTY0IHdoZW4
geW91IHNlZSBpdD8gIC0tIEp1ZXJk

Could you explain to me how SQL statements can help a cracker if your program is well written? After all, you do use quote methods or placeholders, and you check data before using it -- or don't you?

I do. But I don't assume that my checking, my quoting and my security is perfect, no matter how "good" I think I am. I can always have missed something, or if we are several on the project, someone else might have. Or maybe some unknown bug in perl or apache suddenly decides to let data through in some way when this cracker exploits something I didn't know about.

I'm pretty sure that all those exploits that has happened, like buffer overflows and other stuff in open source and closed source projects was not due to someone just saying "Ah darn it. We just skip checking this part here, let's go grab a beer instead." - I am pretty sure it was a mistake (for the most parts at least) and the guys doing it thought they quoted and checked all the data. Turns out they were wrong. (It is a strange comparison perhaps, but you used it first :) ).

Maybe you feel confident enough to know you have checked everything possible. I don't. And even if I did, someone else might muck my safe stuff up.

Secret parameter names in your code are often a sign of bad programming too.

Haven't done that yet. But I've heard about displaytype=hack.

Do you put your SQL passwords in your code, or somewhere safe, with nice 403 error messages if anyone tries to get it through http?

Usually in a module somewhere inaccessible. At least via HTTP. :)

After all, Apache's entire source code is open, MySQL's source is completely disclosed, and so is Perl's. Why hide parts of your own source if those parts can help debug?

No reason at all, if all the users are "white hats". All the reason in the world if just one of them wears the black, because my code has not been reviewed, refined and bug tested by thousands of volunteers, of which many are also excellent programmers. It has been tested possibly only by me, of which none is an excellent programmer. :) And that code you mention has also been known to break at times. What makes it good to use is rather the speed with which things are discovered and fixed, not the out-of-the-box safety... although that is pretty darn impressive too.

Not all users are Teletubbies saying "uh oh" and "again" when something goes wrong. There should be a friendly message for those who are, but there should be detailed information for those who like to know more.

That is totally ok by me. If you want to, you can provide the user with whatever you think is friendly - of course. :) And I agree it isn't all that bad an idea. But. I'd still probably craft something directed to "the knowledgable user", I'd still not dump whatever to someone I don't know what his/her intentions are.

I have no idea if the bug is going to be huge or tiny, and I'm not motivated at all to fix it.

We are all different, thank heavens. If I'd give you one piece of advice on how to run your sites, it would be "do what works for you". Of course. :)

---

You have moved into a dark place.
It is pitch black. You are likely to be eaten by a grue.

I think it depends on the application. If you are offering a free service, you can probably get away with this. If you are offering a service where you have customers that are paying for the usage of your page, you'll need to have more than just this.

Otherwise, you'll end up with a support department always trying to figgure out what to tell a customer whenever they write in and ask what went wrong.

In my experience, the best system is short descriptive error messages. These give clueful users enough info that they don't need to request support. It also gives your support department enough info to go on that they don't have to spend so much time helping the less-cluefull users (or bugging the programmers).

Your results may vary.