I build federated IAM infrastructure at work, and one of the hardest problems we have is informed consent around attribute release. Users don't necessarily understand what they're releasing, developers don't necessarily understand what they're asking for, and there isn't a way to fake attribute release under the user's control (for those cases where you might still want to use a web app but not give it the carte blanche access it's asking for). It gets even more complicated when using social networks as identity providers of last resort. I---along with my employer---am very privacy conscious, so I really, really don't want to ask for any information I don't absolutely have to have.
I try to mitigate this personally by creating multiple Google Accounts, but it isn't foolproof---plus, not every social network lets you do that.
I would tend to agree. In this whole episode I don't think either Google or the user are "at fault." I think its an unfortunate misunderstanding. A powerful tool accidentally misused.
It does make me think that perhaps authentication (OAuth) would be better provided by an independent organization that didn't house so much personal data (that is, not an email provider nor a social network). An independent provider that didn't have much, if any, personal info would prevent this accidental release of information and control. That way if someone _really_ wanted to give a third party access to and control of their email at Google they would have to actually take the extra step of logging into Google and deliberately providing the access. In this case introducing friction into the process may save the user from shooting himself in the foot.
> It does make me think that perhaps authentication (OAuth) would be better provided by an independent organization that didn't house so much personal data (that is, not an email provider nor a social network).
OAuth is an authorization system, not a mere authentication system, and it makes sense to have an authorization provider that is the locus of data or services for which authorization is required.
Separate authentication-only systems haven't been particularly successful.
> OAuth is an authorization system, not a mere authentication system
You're right. Sorry for my sloppy use of AuthN and AuthZ. My point is that for day to day authentication into 3rd party sites which is what I think most people use "Sign in with Google" and the like for might be better served by a 3rd party with less or no data. Less chance of accidents like the subject of this HN thread.
Of course as others have suggested Google could implement a more serious authorization system for elevated or unusual privileges in order to get users, such as this one, to pay attention.
> My point is that for day to day authentication into 3rd party sites which is what I think most people use "Sign in with Google" and the like for might be better served by a 3rd party with less or no data.
I try to mitigate this personally by creating multiple Google Accounts, but it isn't foolproof---plus, not every social network lets you do that.