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
Received on 2018-12-13 17:15:20 CET