For example, when I was in college, there was an application which allowed the faculty and administration to log in, review student's schedules and see their picture. Since many students posted their schedule on their dormrooms, this was hardly “sensitive information”. At one point, while working for one of the VP's, I discovered that you could log in by giving the name of one of the campus printers. Yes, the printers had no password and some combination of “read-only” admin access. The risk of this vulnerability was quite low and within a year or two, everyone knew about it.
On a related note, during an email exchange with Chris a couple weeks ago, I noted my SQL injection tests and sent a bit of sample code which attacked a user's password. It didn't do anything that special, it simply allowed be to authenticate as a random user. Not elegant but still effective. Chris made the point that in these scenarios attacking a username is just as easy but allows you to choose a specific user… preferably an administrator.
So what strategies do I use for reporting vulnerabilities? I don't.
If the owner of the application or site is a potential customer whom I am *actively* speaking with about performing work, transitioning to a better system, etc, I am very careful. I never provide a proof of concept, but I talk about the concept of a BadGuy(tm) inserting malicious code and redirecting users, stealing info, etc. I don't provide any code, I don't identify specific form fields or pages, and I definitely don't demonstrate it for them.
For everyone else, I keep my mouth shut for the reasons outlined in the above article. There are organizations like CERT who can take submissions and handle things from there.