2 ms·

> Showing the error itself only opens the provider to information disclosure No offence but as an end user I really despise this attitude. Sure there might be

> Showing the error itself only opens the provider to information disclosure No offence but as an end user I really despise this attitude. Sure there might be automatic monitoring at a place like fastly, but even they can use help in tracking down the problem. Also, if the error is distinct people can put it into Google and call on the vast power on the Internet to help figure out how to fix it or work around it, especially on smaller services where a fix may or may not be forthcoming anytime soon. A good error message leads to a Stackexchange page leads to a solution. A vague error leads to a support call with a bewildered frontline tech and a lot of work for some sorry engineer who has to dig through log files.

cerved 5y ago
It's a matter of information security. Error messages potentially disclose sensitive information on the internal workings of the service. Disclosing that information is a potential security vulnerability. Also note that SE went down yesterday
- jandrese 5y ago
  I would counter that your service is not as special as your security guys think it is. The paranoia over "Oh no! Those dastardly hackers will discover that we use PostgreSQL on our backend! Our secret sauce will be spread all across the Internet!" is usually overblown. Obviously this does require your developers not to be complete idiots by putting their passwords in the error messages or something, but this is an extremely easy bar to hurdle. At the very least you can put an error code up. Just make sure it is a reasonably long string so you don't have collisions. If you are big enough people will work out what the codes mean and what they can do. For example, I know 0x80D02017 on Windows means Microsoft has broken their IPv6 service endpoint for the Windows Store again, and you can temporary disable IPv6 support to work around it. Even though the error message is the monumentally unhelpful "Unknown", the Internet can come to the rescue. Of course if the error message had been something like "Windows Store update connection to address 2603:1061::9f4d failed: Service responded with protocol version 4, this client only supports version 5" it would have been even better. Would it disclose data about how Microsoft internals? Maybe a little, but most of that was observable anyway and maybe if you had error messages like this maybe it wouldn't take them 8 goddamn months to find and fix the problem?

cerved 5y ago

It's a matter of information security. Error messages potentially disclose sensitive information on the internal workings of the service. Disclosing that information is a potential security vulnerability. Also note that SE went down yesterday

jandrese 5y ago
I would counter that your service is not as special as your security guys think it is. The paranoia over "Oh no! Those dastardly hackers will discover that we use PostgreSQL on our backend! Our secret sauce will be spread all across the Internet!" is usually overblown. Obviously this does require your developers not to be complete idiots by putting their passwords in the error messages or something, but this is an extremely easy bar to hurdle. At the very least you can put an error code up. Just make sure it is a reasonably long string so you don't have collisions. If you are big enough people will work out what the codes mean and what they can do. For example, I know 0x80D02017 on Windows means Microsoft has broken their IPv6 service endpoint for the Windows Store again, and you can temporary disable IPv6 support to work around it. Even though the error message is the monumentally unhelpful "Unknown", the Internet can come to the rescue. Of course if the error message had been something like "Windows Store update connection to address 2603:1061::9f4d failed: Service responded with protocol version 4, this client only supports version 5" it would have been even better. Would it disclose data about how Microsoft internals? Maybe a little, but most of that was observable anyway and maybe if you had error messages like this maybe it wouldn't take them 8 goddamn months to find and fix the problem?