- View and manage your mail
(click the "info" icon)
View, manage, and permanently delete your mail in Gmail
Create, update, and delete labels
Compose and send new email
View your settings (e.g., filters and labels)
- - -
Okay. So the author is saying that the user cannot be trusted to read dialog boxes or click "more info" on a process they don't understand. Which, if that's the case, I guess the user can't be trusted to connect Gmail to anything. That's an unfortunately wide swath of usability that would have to be categorically disallowed if the problem is that Google allows this "At all."
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".
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.
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.
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 I agree with OP. Remember click-jacking? Or cats jumping on keyboards?
I wouldn't want my entire gmail history 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.
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.
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)".
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.
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."
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 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.
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 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.
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.
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.
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.
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.