>> A specifig knob for "sensitive data" cannot be supplied by
>> PostgreSQL because it cannot know beforehand what information
>> will be considered sensitive under a given, future, usage
>> scenario.
> Yeah, it's fairly hard to see how we could respond to this complaint
> without lobotomizing our error messages to the point of near uselessness.
> Almost any non-constant text in an error report could possibly be seen
> as hazardous.
I don't think that's true - schema information (table, column names) definitely seems like it's in a different category than table contents.
> More generally: I find this complaint a little confusing. We did not
> consider reporting the "show row contents" DETAIL to the client to be a
> security hazard when it was added, because one would think that that's
> just data that the client already knows anyway. I'd be interested to see
> a plausible use-case in which the message would reflect PII that had not
> been supplied by or available to the client.
I'm imagining two main scenarios here.
First, there are many lazily-written applications out there which simply show exception/error messages to users. So user A could interact with a website in a way that triggers a unique constraint violation, and thereby get access to the data in the row which caused the violation.
Second, such exceptions and errors frequently get logged (e.g. to disk). Logs in general aren't kept as secure as database data itself (who knows where they end up and who handles them).
In this day and age of increased attention to personal information it seems quite risky to be sending row contents via error messages without an opt-in...