OP is complaining, that the authorization is "all or nothing" and that the form looks quite similar to normal ordinary google sign-up window, and that the severity of the action is not proportional to the appearance. I guess.

And I agree with him. The fact that you are giving away a decade of correspondence should not be at the same size as "Yes, I agree with the server saving my cookies".

I think both parties are to blame here, that being Google and Fleep.

Google should make it much clearer in the OAuth flow that the scopes you are allowing could potentially allow the third party to download your entire history. Google aren't the only ones guilty of this. OAuth is built upon user trust and control of scopes. Don't hide them away in a "click for more information" dialog, make it clear right there that certain scopes are giving away much more information.

Fleep should not be importing my e-mail as part of the initial "signup with Google" flow. It should be a second step after i have got past the OAuth stage and they should make it clear that they will be importing my entire history from Google. A drive by import might be a "frictionless" user experience, but it can appear clandestine.

And for anyone else using OAuth, or clicking "signup with $foo" - always always always check the scopes you are allowing. Remove all but the essentials required for you to "sign in", that should only be your name/email address. If you can't limit the scopes then just signup the old fashioned way, your e-mail address and a unique password.

The third paragraph in your post describes the current flow of Fleep sign up, unless it was changed in the few hours between mborch's blog post and my running through the flow to see what happens. There is an OAuth request to use your Google identity, and a completely separate OAuth request to get access to your Gmail behind a "Now that you've joined Fleep, import your emails" dialog that Fleep generates.

> The third paragraph in your post describes the current flow of Fleep sign up

That's good. In that case either blog post is misleading or it has been changed in the hours since.

Edit: I see the original blog post has been updated with more information.

OP appears to have drawn an arbitrary line in the sand between authorizing an OAuth permissions request and being asked to provide a password, however. Which, unfortunately, indicates the OP's lack of understanding of why OAuth exists---why on Earth would it be better to give Fleep the password that unlocks one's entire Google account instead of just the relatively-narrow authorization to manipulate the user's email account?

I can sort of see the argument that email archives are an extra-special category that should require extra-special "Are you sure" confirmation. But I think that the OAuth question panel is intended to be that extra-special "Are you sure" confirmation in the first place. How many "Are you sure"s are necessary to prevent users from shooting themselves in the foot is a bit subjective.

I think OP is saying that Google's oauth2 screen should have asked him to provide a password, to confirm that this should happen.

I think I agree with OP. Remember click-jacking? Or cats jumping on keyboards?

I wouldn't want my entire gmail history[1] getting delivered to a third party because of one erroneous click.

1. My gmail history actually goes back further than ... what the hell. I imported 1999 era email into gmail years ago and now I can't find it. I am officially sidetracked! [UPDATE]: yeah, my email history goes back to BEFORE gmail launched, because I imported old emails. Early 2003, actually, not 1999... Dunno where those emails went.

How about just some bold red letters outlining permissions being given away without having to type "more info"? Specifically that you are giving access to all of your email, contacts, and the ability to delete your email.

I mean, why bother? People aren't going to read it anyway, regardless of font or size. ;)

That could be true of most people. I tend not to give permissions out and would read the whole thing. If I was feeling lazy though I can tell you I'd take notice of a red warning but, I can't speak for others.

I wonder if this is a good reason to NOT use your email provider as your authentication (OAuth) provider?

Yeah, I think a more meaningful critique here would be "Google should draw more visual attention to certain dangerous permissions like these, over less impactful ones."

Also, it's easy for users to click buttons and go "ohhhh, wait, no!" and there ideally should be something to account for this case too.

Yes, absolutely. I write a lot of stuff that uses Google OAuth in order to to interact with google apps on behalf of a user (generate calendar events from forum posts, etc). I ask for the auth scopes separately and my code makes it clear what it's asking for (and the extra auths are asked for outside of the login-authenticate stuff which is always super-basic).

Because of this, I'm extra attentive to what these scopes ask for and definitely don't sign up for anything that looks sketchy (especially the gmail stuff) - most recently TripIt asked for that permission (I suppose to scan my email in order to find travel documents). Even if I trust that TripIt isn't going to misuse that auth right now, there's no way I'm allowing that credential.

I kind of wish I could set universal auto-reject at the google account level of some auth scopes. Like, "I will never allow https://mail.google.com/ scope (or any of the https://www.googleapis.com/auth/* ones)".

Which is absolutely what the author asked for.

Ahh yes, the old tactic of "blame the user" when an interface problem is found. The author (who is a more adept user than average) wasn't aware that his email (the linchpin of his digital identity) was completely open and accessible to a third-party app. This is a pretty big deal, and very much a failure of interface design. How many other users have unwittingly opened themselves up to third parties without knowing it?

I see what you and the commenters below your post are getting at.

But, I'm glad I read this article today. Really glad! ...No reason... Just saying.

...OK, I'll admit it... I didn't know that any of these apps could possibly access anything of mine. I thought this whole 'oauth2' thing was about identity.

In case it is helpful: https://security.google.com/settings/security/permissions This page shows what permissions you've given various "apps". This analogous to per-app permissions on an android phone. You can switch between your various Google accounts and GAFYD accounts on this page.

The author is complaining that "manage your mail" apparently means "We'll copy all your contacts and mail history of all times into our database". The permission dialog only tells you what Google will allow the requesting app to do, not what that app will do with that.

I can't imagine a scenario that would make a "What the app will do with this permission" signal useful against malicious actors, which is the only scenario that matters. In this case, Fleep did exactly what it said it was going to do two dialogs ago anyway (I didn't take the time to copy that down when I tested the flow, but it's something equivalent to "We'll get your recent email correspondence"); the user either didn't understand what was being asked or didn't bother to read every word in the dialog box.

There's only so much defending against users not bothering to read or understand protocols that you can do before you encroach on actual usability. Chrome has already gone as far as to deny access to websites when end-to-end security cannot be guaranteed unless you happen to know the secret pattern of typing "b a d i d e a" at the blocking screen with no UI interaction to indicate anything is happening. This author expressed surprise that it's possible to grant access to their Gmail contents at all, to which the response is "Of course it's possible! That's a really useful capability for extending Gmail beyond the base set of functionality Google enables."

Authorizing an IMAP client to an email account gives the client that much power. What the client does with it is another matter.

The author makes a point about the European Data Protection Directive. He has the right, in the EU, to make Fleep delete that data. It's his, not theirs.

It's more than that: EU companies mustn't collect data they don't need in the first place.

FTA:

> It's just too easy to give away your personal information on the internet and this needs to be fixed.

More faux-outrage nonsense. Nothing needs to be fixed, the author just needs to read and actually understand what they're doing before blindly clicking "OK" to any dialog box that pops up with Google's logo.

I think the point is legit: Even for a technically sophisticated audience, it was not 100% clear that "manage my email" would give away their entire address book..

It's pretty poor behavior on the apps part - but this is an area where OAuth consent dialogs could be more meaningful.

"manage my email" is a thoroughly scary permission to my eyes.

Can you please, for one moment, imagine a world where computer users aren't as intelligent as you are?

"Manage my email" is vague, and while it's entirely the OP's fault, it is also a relatively easy mistake to make. I could easily see myself making this same mistake, and it could have permanent consequences.

I'm having a very hard time conceiving of what definition of "manage" a user could come up with that would have made them realize the possible consequences of granting this permission, given that the text also includes the phrase "and permanently delete your mail in Gmail." If the user shouldn't trust the requester with delete permission, what possible definition of "manage" could somehow have convinced them this was an unsafe operation?

At some point, you have to either trust users to bother to read what you put in front of them and think about the ramificaitons, or you have to assume they don't and categorically disallow that functionality. And I, for one, am not in favor of categorically denying API access to Gmail.

Indeed.

Why would anyone approve an app that could "permanently delete your mail in Gmail"? I wouldn't.

The bottom line: yes, you really do need to read those pesky dialogs.

Maybe because the app could be a mail client? If I downloaded a mail client and it wasn't able to delete my email I'd think it was a pretty crap piece of software. The same as I'd expect if I wanted a fully featured mail client to connect via IMAP.

I'd also feel a bit annoyed if a Twitter client I was using was unable to delete tweets, and I had to go back to the Twitter website to do that.

The thing about making APIs to let other people interface with your product is that you have to expose all the functionality of that product, or there's not really any point.

There are some fair comments in this thread saying that the "manage" permission is significant enough that it should be flagged a bit (or a lot) more strongly than the common "identify" permission, but personally I don't think the point of the API is something that needs questioning.

There's a very common case for exposing only a subset and that's granting read-only access.

That seems to be just what OP expected - he says "I exported my recent e-mail history to Fleep, a collaboration platform used by a new client, and let their software synchronize future e-mails".

So why, based on this, would he feel good about granting permission for something to delete his email? (even ignoring possible confusion over the meaning of "manage"). Delete != read-only.

His first thought should have been "is this too much access"? A quick Google search would have led him to https://developers.google.com/identity/protocols/googlescope..., where he could have seen that indeed there is a read-only scope for access to gmail (https://www.googleapis.com/auth/gmail.readonly).

Obvious conclusions he should have drawn - either: 1) Fleep is poorly or maliciously written, and requires overly dangerous OAuth scopes 2) His understanding of Fleep is wrong, and Fleep intends to do more than just read his emails

I don't know which is true, but he should have investigated before hitting the Internets with his tail of woe.

But at the end of the day, everything worked as it should, and we can probably assume that Fleep does what it says - its simply that he rushed past a warning dialogue.

No, there is plenty that could be done.