Branko Čibej wrote on Thu, 13 Dec 2018 17:00 +0100: > On 13.12.2018 16:53, Michael Pilato wrote: > > On 12/13/18 10:45 AM, Branko Čibej wrote: > >> Uh. I forgot about the malfunction handler. However this doesn't really > >> help, other than putting possibly sensitive paths into the crash handler > >> info? We really shouldn't do it this way, users *will* just copy and > >> paste the output tot he 'net. > > Ahem. What Grandpa *meant* to say was: > > > > "Oh, cool! So there _is_ a way to report the non-canonical path. > > Thanks for figuring this out, Julian! Unfortunately, it comes at a > > cost, namely that of revealing potentially sensitive paths in the output > > which I strongly suspect will get copied and paste to the 'net. If we > > could mitigate that part of it, this might turn out to be truly beneficial." > > > Well, no, I meant to say exactly what I said. But if I were in a > politically correct fame of mind, then I might have said something like > what you wrote. > > Re FUD: it's not just paths, it's also URLs, and people do consider one > or the other sensitive. Of course ... in the end that's no worse than > printing paths or URLs in error messages. >
The error message should include all information relevant to the problem. (As a rule of thumb, if an error message doesn't have a printf "%s" expando, it's probably incomplete.) If users consider some part of it sensitive, they shouldn't intentionally post that part to the Internet. The rub lies at "intentionally". It's conceivable that a user might not realize that the support forum they're posting the error message to is public. So, I'd say, have the error message include all relevant information, and if a user tries to seek help about it, make it *crystal* clear that users@ is publicly archived. Cheers, Daniel
