[uxp]

But that ends up sending an email to the account you extend the sharing request to. It might raise a red flag to some people.

This 'vulnerability' doesn't contact the victim, so it can be done in combination with, like the report said, a phishing scheme to gain the real names of the users of an email list.

I'm not saying that this is some massive privacy issue. It opens up a vector to make other attacks, specifically email based attacks, seem more legitimate, which is a bad thing.

[marte]

There is an option to not send an email. And it's not a request - once you share it, the recipient doesn't need to accept. The users can see them in their GDocs list though. But if you quickly unshare them and they're not currently viewing their list, they'll be unaware of it.

[uxp]

I didn't think that it was an option, but I did check. You are right. Of the three checkbox options, notifying the recipient of a share invitation is the only one checked by default.

Either way, my main point stands. This isn't a major privacy issue. Though, I've always been taught that when developing an authentication mechanism, one should not distinguish between a bad password or bad email address/user name in the error message provided to the user. Specifically the latter, since a "Invalid password supplied for John Doe" gives confirmation that the username provided is valid, and a bruteforce or dictionary attack on the name will probably successful.