>> definitely seems like it's in a different category than table contents.
>
> You're not visualizing this with the appropriate amount of paranoia: just
> because the database thinks that something is a table or column name
> doesn't mean that that's what it actually is. A screw-up in query syntax
> could lead to reporting back something that was really a data value.
> Admittedly, that's not very likely given a well-debugged application
> issuing the queries, but it's not something to ignore either.
Good point, thanks. I guess the main thing I'm trying to say is that in the standard, "default" scenario we should consider doing our best to avoid data leaks, rather than approaching this as a 100% all-or-nothing problem..
>> 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.
>
> Well, that's just bad webapp design ...
True, but as this is a potentially critical security/privacy concern it seems reasonable to do what we can to prevent these leaks, even if ultimately they are the app developer's fault/responsibility.
Basically at the moment there's a "pit of failure" where an inexperienced dev doing a standard application has a high chance of encountering this issue, and unfortunately most of the Internet is made up of this scenario. I'm only proposing to protect against the obvious/easy data leak scenarios via an opt-in.
