OAuth (Google Sign In / Facebook Login) is a pretty good technology in order to manage and share your information. What's nice about OAuth is that it allows the end user to control access to information and revoke access as needed.
What is truly scary is that the banks and financial institutions have not implemented OAuth. Currently, financial data is provided to third party apps via aggregators, like Plaid and Yodlee.
Unlike OAuth, once you log into your bank with a third party app, they get an access token that allows access to your account indefinitely. There is no mechanism to monitor which apps have access to your account and ability to revoke the access to individual apps.
"What's nice about OAuth is that it allows the end user to control access to information and revoke access as needed."
Really? This has NEVER been my experience with OAuth or similar protocols. It's always all or nothing, and I can never:
- limit the scope of any given type of permission
- find out which data was actually accessed
- limit the number of permissions given (it's all or nothing)
I realize this takes much more work than simple protocol, but it's the same as on Android: either an app takes EVERYTHING they ask for, and noone tells you how exactly they used those capabilities (no api log, no nothing), or you can't use the app.
I would much prefer a solution which lets me:
- understand full scope of data access (what does it mean that a web-app can "manage my contacts" in Google account? Manage as in... delete? Change their details arbitrarily? What?!)
- see full list, by app, what was actually accessed, and when
- be able to pick which things I want the app to do, and which I don't
- define (with groups, individual item selection or similar) which specific items I want the app to access
If the app breaks because it doesn't support partial access, so be it. But not designing this ability into the UI is basically forcing users to forever become oblivious of how technology works.
OAuth is a framework to allow access. It supports the idea of scopes, which would for example allow Google to grant an app "read rights for the last 30 days" or "read rights on contact list" but not "update contact list" etc. The scopes are entirely up to the discretion of the resource manager. In the case of Gmail, that RM is Google.
OAuth does not prescribe any feedback loop. There's nothing in the OAuth framework that says "RM must keep a record of what accesses have been made, and when; and must disclose that record to the data owner (you) upon demand, via a reasonable web UI".
It would be a good idea to have that, but it's not required, or precluded, by OAuth.
OAuth ALSO does not require that the RM give you, the data owner, the ability to review and revoke your prior granted consent. But most RMs do this.
Marshmallow is much better about this. You can actually control what apps can read, what they can write, etc. I wish it prompted you during the installation of the app, but it's getting better.
Yeah, for those that don't know, you can go into Settings -> Apps -> pick an app -> Permissions and disable them at will. I believe only apps compiled against a Marshmallow SDK version will prompt you at runtime, and there's little (or even negative) incentive for app developers to do that yet.
There's a great incentive on automatic updates. If you updated an app pre marshmallow with an extra permission it required the user to approve the update and that ultimately creates a problem with a large user base stuck on older versions.
Maybe for new apps there's less incentive to reduce access, I can't think about any other than compliance and user scrutinity. It's easy to spot bad reviews complaining about excessive permissions for some apps.
Does this mean they brought back PrivacyGuard? That was the main reason I switched to Cyanogen - to be able to use apps without giving in to their often ridiculous demands for access to my personal information.
> "What's nice about OAuth is that it allows the end user to control access to information and revoke access as needed." Really? This has NEVER been my experience with OAuth or similar protocols
You point out one of my HUGEST frustrations, "either an app takes EVERYTHING they ask for, and noone tells you how exactly they used those capabilities (no api log, no nothing), or you can't use the app". I hate this aspect of OAuth and am so desperate for a simple solution. But I sincerely doubt one is coming-- at least not for a while...
The solution you're looking for is OAuth. It's in fact never been "all or nothing", its' always been a choice by each app and service. The reason most apps ask for everything is because 99% of users don't understand or care, and if you try to explain it to them, they'll get confused, bored, or nervous, and not use your app.
"What's nice about OAuth is that it allows the end user to control access to information and revoke access as needed."
Users are free to revoke their their permissions at any time, but they won't be able to use an app without the permissions. You could very easily build a UI with user-variable permission scopes on account creation/management with OAuth, but no one bothers, because it would be a pain to manage on the backend for zero economic gain.
It goes beyond access to your data. With an account and routing number and access to ACH protocols anyone has essentially unrestricted access to your money.
I ran into an issue last year where I was unable to get an insurance company to stop pulling money, unauthorized and automatically, from my account. Since the amounts were different each time, my bank said I had no recourse other than to continue disputing the charges or change my account number.
So in that way it's a bit like oAuth, except you only have one key and when you revoke it, everybody loses access.
This is the CRAZIEST part of the banking system. The information to withdraw money from your account is on the bottom of the paper checks that you freely give out. Anyone with the routing number and account number can drain the entire account.
ACH fraud in the US is in the ballpark of $100M / year.
This is why I think we're only in the opening days of the FinTech shift. There's a lot to be done and a lot to fix.
"paper checks"... wow. You guys still have those? I found a book of them when I moved house recently, unused, from 10 years ago. Don't miss them even slightly.
Paper checks are the only free and universally accepted way to move an arbitrary amount of money in the US.
Most consumer spending runs through Visa/MasterCard credit or debit cards; the interchange fee is baked into the prices of consumer products. Most people have something that processes as MC/Visa (whether it is backed by a traditional bank account, line of credit, or non-check-writing account) but most people cannot accept such payments, and no one can accept them for free.
Tech-savvy consumers can pay each other small amounts of money through Venmo and Square Cash, and that is typically how smartphone-native millennials settle restaurant bills and alcohol purchases among each other. They are free, but you can't move more than a few grand. Very large organizations usually have a web portal where you can type your checking account and routing number to pull money from your bank account with 3-5 day latency through ACH. Perversely, many of them will charge a "convenience fee" for this service that is not applied to payments by check. This is also strictly less secure than payment by check, because it's at least a little bit difficult to get authentic-looking checks for account numbers that are not mine. I can type whatever I want into the box on your website.
Most consumer bank accounts have an Online Bill Pay feature with the ability to push money to organizations of this kind of size. Sometimes they work by transferring your money to a service provider who physically prints and mails a check on your behalf. Usually they're just the Push (rather than Pull) variant of ACH.
Only some banks have the ability to push ACH transfers by account and routing number, letting you pay smaller-time recipients (as long as they trust you with their account number). Sometimes you can also input an email address, and the bank emails them asking for the account details to push the payment to (because that's not reminiscent of a phishing scam at all).
There are plenty of uses cases not served by any of these options. The car dealership. The family member you're supporting. Your small-time landlord, or the friend you're subletting from. Small town governments, suburban school districts, etc. I'd guess most adults don't use checks frequently, but we still need them every once in a while.
Free (gratis) to the consumer only presumably, we have to pay at work (an SME) to deposit cash, cheques, and pay a third party for DD and CC processing.
Pretty much only get cheques from charities/clubs now, haven't written one in maybe 10 years.
What do you use to pay rent? That's the only use I still have for them, but landlords don't tend to take credit cards, and a check is easier than an envelope of cash.
Direct Deposit and/or BillPay is what I used in Australia before moving to the US.
I also miss things like BPay where I can pay all my bills via my Internet Banking portal. Moving to the US felt like a 10+ year regression in money related systems.
Yep, I moved to the US two years ago from Australia having never written a check in my life. The banking system here was probably the biggest culture shock for me.
Agreed; also in .au, the last time I presented a cheque (in 2011) the poor newbie teenage bank teller strained to recall his training. He processed it ok, but panicked so badly he accidentally handed it back. The branch manager drove out to my workplace to retrieve it from me in person...
Tell me about it, I'm trying to get an expense reimbursement from the NL to my personal bank account in the US. No IBAN, only SWIFT - nobody seems to know how to function with out antiquated system of very expensive wire transfers.
One way or another your bank has an IBAN you can use, but if it's a smaller bank, they may go through one of the larger ones. You just need to find the right person to talk to at the bank.
Even if US accounts had an IBAN (they don't, US banks don't participate in that standard) that wouldn't help. The Dutch bank can either process payments via SEPA (Single Euro Payments Area) or international wire transfer (which doesn't need IBAN but is expensive).
Maybe GP can make them use Transferwise, Currencyfair or the like?
Yeah, thats my current plan of attack, but getting the sender to use the service has been a trial. They're not too keen on non-traditional money transfers.
Also, because my wife and I use different banks but pay bills jointly, I just have her write me a check every month for her part of the bills. I then accept it using my bank's mobile check deposit feature.
While we could do ACH transfers, it's way easier to just write a check.
It amazes me the kinds of workarounds we have to do just to move money.
I am a member of two credit unions, both of which participate in the Co-Op Shared ATM network so I can use most credit union ATMs to make withdrawals and deposits. One credit union holds my regular checking account. The other has my mortgage.
Until the automatic payment gets set up, I pay my mortgage by going to a third-credit-union ATM (owned by a CU that is also on the shared ATM network) and withdrawing a pile of cash with one CU's card. I then stick that cash back into the ATM as a deposit with the other CU's card. The payment can thus be made as a "transfer" on the mortgage CU's online banking platform.
It takes minutes to do that versus approximately 3 days to do an account-to-account transfer.
3 days to do a bank transfer, ouch, that's a blast from the past. Sounds like you desperately need the Faster Payments system we have in the UK - allows you to transfer money between accounts (at different banks) instantly. Other than collections at church and the occasional business that doesn't take card, I hardly ever use cash these days.
> The Rule includes a “Same Day Fee” on each Same Day ACH transaction so that RDFIs would recover, on average, their costs for enabling and supporting Same Day ACH.
Never doubt the American banking system's capacity to gouge the customer.
It would be easier to transfer electronically if the systems existed.
I'd open the banking app or website, put in the other persons mobile phone number. Their name would be shown as confirmation. Enter the amount, press send. It's in their account in minutes, an hour at most.
If I transfer the same amount regularly, I'd click to make it a regular transfer.
If I don't know their phone number I'd use their account number. Either way, they're saved as a contact for next time.
Right; I'm not saying that using mobile check deposit is the easiest possible method for this (it definitely is not), but it is the easiest method that my major US bank supports.
You were still using them that recently? Must be fifteen since I used a cheque here in Norway. My sister still uses them in the UK though, you even see people writing them at supermarket checkouts (but not often).
I ran into this recently when my girlfriend paid her ~$5,000 credit card bill just by typing in my account/routing number. No authorization was required from me. I'm still confused and slightly outraged that this is possible.
> It goes beyond access to your data. With an account and routing number and access to ACH protocols anyone has essentially unrestricted access to your money.
Fortunately Intuit has really, really poor coverage for this. Comically poor. Plaid only supports a few FIs. Never sign up for a service with Yodlee and you're statistically covered here.
> Since the amounts were different each time, my bank said I had no recourse other than to continue disputing the charges or change my account number.
For future reference, your bank should have offered to migrate you to a new ACH number for free. It's really quite illegal for them to allow ongoing fraud to occur once you've informed them of it.
It's no different than if someone loads your Chase Debit number into an Apple Pay device and then adds biometrics (which btw: true tragedy and incredibly stupid. Chase needs to implement yellow path. I closed my accounts due to waves of fraud via this method). You're still not liable for damage, it's just scary and frustrating and time wasted.
The good news is that for personal accounts you should have 60 days to recover. Although if someone drained your account and you have to wait to pay rent, that might not be so comforting.
Businesses I believe only get one day. This ACH fraud is crazy that it exist. My landlord gives me his account number to pay rent. The routing number is trivial to google but, lucky for him, I'm not a thief.
Doesn't the bank require previous written authorisation? I've used banks in several European countries, and on all cases I had to tell my bank explicitly who could send bills to be debited to my account. Moreover, all the authorisations were revokable at any time (although charge backs were not possible).
> What is truly scary is that the banks and financial institutions have not implemented OAuth. Currently, financial data is provided to third party apps via aggregators, like Plaid and Yodlee.
Hi. I was the CTO of Level Money, that ultimately had a meta-aggregation platform on top of all the major aggregators. We were acquired by Capital One. Disclosures: complete.
Can I just put out there: every major FI has talked about OAuth2. We all know about OAuth2. It's entirely within our technical capabilities to make an API and then allow OAuth2 access. We could even make said access public. The "can they" is answered: yes we could. Yes, we have prototypes.
And yes, there are non-technical obstacles. Pardon me while I Nod Dance & Amble.
But there is a larger question about the aggregation problem. Banks are rightly concerned that if they do open these up, they'll be consumed wholesale by the major tech companies. You could imagine a world where Google partners with your bank to make a pretty amazing experience, but in the process it's almost certain that Google would have a significant upper hand. Most banks (even C1360, which I and many other people are working constantly on modernizing) simply aren't ready to work with giants like Microsoft, Google or Facebook as equals. That, sadly, will take years as these organizations realize they have to do this.
We're all in sort of a slow motion race towards this goal. Slow motion compared to the outside world (as I am all to keenly aware), that is. Internally, the process by which we do this is hugely complicated by US law and regulation. There is this wonderful thing where "regulatory capture" backfires and then you're imprisoned. For every thing that a bank charter enables, it closes off another 2-3 things that never mattered until things started being judged by their slickness in a mobile app context.
As for disconnecting from aggregators, let me tell you as an insider what you can do. Change your password. No really, change your bank password. EVERY major aggregator has a flow that requires they respect this at a technical level. If that fails, it's on your bank and you should shout at them VERY loudly.
But before you do, make sure you are ready to prove yourself as a banker. What will happen with most aggregators is that they'll have to decide, "is this person actually gone or is this stupid web scraper just having a bit of a problem?" They'll try and log in again, at least once in most cases. If you have hooked up multiple services (or the same service multiple times), these will trigger account lockouts just like any failed web login would.
> What's nice about OAuth is that it allows the end user to control access to information and revoke access as needed.
One thing to know is that this is entirely up to the implementer. As others have noted, some sites do this, some don't. The concept of an access token having some "scope" of authorization is not limited to OAuth – there's no reason this can't be done with any other sort of authorization protocol. Bank security procedures are bad and they should feel bad but I'm not sure OAuth is the right solution.
As someone who has recently developed an app with Google OAuth I'd like to second this. Google lets you register which servers the auth tokens can be used from, which means that even if the application database gets hacked your data is safe. Tokens are also rate limited at both the user and application level, which means that even if there is a zero-day attack targeting your web servers, you can set up monitoring software to automatically revoke your tokens so that no more than a tiny percentage of data is at risk of getting exposed.
Although it can be dangerous to implement your own OAuth as a provider due to the complexity of the protocol, if you're merely granting an app access to your Facebook or Google account then as a user the security story is quite good.
> Google lets you register which servers the auth tokens can be used from, which means that even if the application database gets hacked your data is safe.
This works when there are places of origin it can track but if you're handling tokens via a mobile device it's not as easy.
Regardless I wouldn't say your data is "safe". If someone broke into your system and you cached Google's data (which you probably did; federated queries suck) then your data isn't safe at all. Even the token can be re-used (I mean if someone broke in I don't see why they couldn't run stuff on the same server or even looking like it came from the same server).
UK in particular has the worst bankins systems and services I've yet seen in my life. Many European countries, including these from eastern Europe, have a banking industry that's 100 years ahead of UK (on example is where you can't just walk in to a bank and have your thing done - you have to schedule a visit, often weeks in advance. And opening an account - real nightmare, good luck with that, if you're not born&breed brit). However, said that, I do understand that this is the result of UK banks being actually oldest ones and the usual inertia of 'working' things made the changes way slower than the rest of the world.
A while back, I heard about a scam where individuals were targeted by someone at one of the mobile phone providers. They logged in with their bank details, rerouted the authentication messages to their phone, and proceeded to do as they pleased. The "victim" had no idea it was happening as all the auth and notification SMS's being sent to their mobile number were being routed to someone else entirely.
How should the bank handle that. Sounds like one needs to send a crypto signed ACK before the bank enable access with the reauth code. Good companies at least send an ack email after the fact.
Not much seems to have been done about verifying the receiving end of communications - when I call a company on the phone there's no default protocol to confirm their credentials (like per user passwords for the business).
I don't see how OAuth could mitigate the problem stated in the article. Once you allow some malucious app to your secret zone, it's done. Your data is now theirs. Doesn't matter if it was OAuth authorisation or you gave them your password (although the second one is probably worse).
Yes, but if they're already downloaded the last decade of your email history... well, I'm not sure how much it helps that you're blocking them from further access. What if they start emailing "helpful" links, invitations, whatever to everyone in your contact list? What if they are rather less strict about how they secure their (your) data, and they're employees spend lunch breaks poking around for public figures who might have interesting histories?
These sharing mistakes are hugely easy to make, and sometimes have unpleasant consequences even with no malice intended on the app company's side.
Someone in our company tried out do.com several months ago, and granted it access to our company directory in Google along the way. We didn't end up using the service; but unfortunately after a while of inactivity they started sending "invitation" emails to not just users on our own domain, but also Google Groups we have set up... some of which include customers of ours who were not at all amused to see that (it appeared) we had exposed their addresses to some random 3rd party without permission.
Apologies all around, of course, but these days it's simply hard to be paranoid enough about this sort of thing. Gmail & Google Apps have tons of useful apps you can add with a few clicks; but what are you actually risking, using them?
If you consider Coinbase a "bank" for Bitcoin, then they have implemented OAuth, quite nicely. Users can review permissions and revoke access in their Coinbase account. The link shortener I run relies on it to transact with my users (https://credhot.com). I also use it for logging in, but that will go away soon in favor of social logins.
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."
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.
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.
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.
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.
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 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.
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.
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.
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.
Fleep is a European (Estonian) company. Just mail them (https://fleep.io/privacy, §9) and they should be decent enough to terminate your account altogether. I had quite a good experience with them, their CEO responded to my Fleep messages (nice example of dogfooding), though haven't used it for a while now.
Having worked on an email client app before, that would definitely be effective. Retrieving and processing a decade worth of email is a huge pain in the ass that takes quite a long time (just retrieving the message bodies from GMail took at least an hour).
Says who? If they were pissed off about this, then I'd assume they're capable of a simple search for "remove app permissions google" which brings up several help articles on how to do it. Considering that Google uses that terminology in the sign in screen anyway, it's not like the terms are incredibly unfamiliar.
I think you're underestimating. An app is a common term for a mobile or web app, should be known by most people using the app in the first place. Permissions is a common term to signify what you just gave the new app you approved, also nothing really crazy. You want to remove or revoke what you just gave the app, so that term is obvious. And the service you approved it with is Google, so add that in.
It's not like this is using any real technical terms that a common 21st century computer/phone user might not know, and the only real difficult one is probably "permissions" which you can probably either guess or eventually get to with synonyms; totally possible given it's a common English word.
No, you're drastically overestimating. Try working in a Best Buy. Everything you just put together with logic is not a safe assumption to make about the average user.
Its not whether the average user would understand it if you asked them (although even that's a stretch.) its whether its going to occur to them that they need to search for that particular string of words, or one similar enough to find the correct result. that is a fairly technical task and presumes a lot of knowledge.
I really can't see how it presumes a lot of knowledge. Half the words are common English words to indicate what is happening, you don't need to know the technicalities of what's going on to know you gave permissions to an app and want to take them away.
Hell, I even checked, "permissions google" still has the account management link as the first one there. So even just knowing the word permission, which is a common English term to describe what you just gave the app, and the wording Google uses (see below) to refer to it, is enough to get to that page. You don't need to be a CS major to figure that out.
The problem I see most often with non-technical users attempting to search for non-trivial queries is not that they don't know those words, but they don't know which words are most important.
e.g. One might formulate searches like:
"How to stop an app from downloading my emails?"
"Take back permission from fleep"
Neither of which provide helpful results. Non-technical users could have a hard time differentiating between "gmail" and "email", or associating "Connect with gmail" with "permissions Google". (Or even "gmail" and "Google" - "Why would my email be related to search?")
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.
> the bigger problem here lies with how Google makes this possible: At all
Sorry but it is MY information and I should be able to do with it as I please. If Google removes the ability to extract it all to a third party then you're locked into Google forever. Removing the ability because some people aren't responsible isn't a good argument.
It's possible to allow for extraction of user data (Google actually support this quite well) and not for sleezy third-party services to fool ... gifted and talented developers, let alone the semi-literate, technically-phobic, Alzheimers-addled, visually disabled, or others, for whom this sort of crap is a very real and constant source of frustration.
I support a group of such users. While they can frustrate me with their lack of understanding, the crap interfaces, requests, and systems they're presented with frustrate me far, far, far, far more.
This is truly a big deal, and also effects Android. The system of "privacy checking" doesn't work when the consumer has almost zero information about how they will actually use the information. Its a binary "give access to everything" or "you can't use this app" which creates an arms race. App updates can then ask for more and more permissions. More importantly, even a misclick can easily give access rights away to your entire email inbox, phone contacts, call history or any other information you might consider private.
The way to fix it is for Google to let you change what data appears to an app after the fact. The app asking for permission will never get denied. They'd get fake data if the user didn't give permission.
I can't agree with this author - at least their argument that "the bigger problem here lies with how Google makes this possible: 1) At all..."
If this wasn't possible at all, this product couldn't exist in it's current form. And clearly, at some point, the author saw value in this product enough to give it a shot.
Do I agree Google should make it extra clear when you are signing over permission for unusually liberal access to your data? Absolutely.
If the 1) the product couldn't exist in its (not "it's") current form, and 2) perceptions of value were based on what was a false understanding of the product and how it worked, then that perception of reality is false, and the product simply shouldn't exist.
The mistake was not "all yours", and Fleep (and Google) are failing to disclose how, when, where, and most importantly, why data are being used.
Quite arguably, Fleep gained access to data you held which was not yours to provide -- email content and contact information for those with whom you've corresponded.
This is among the reasons I'm increasingly limiting my use of electronic communications at all. The risks, reality, frequency, control, and disclosure of such cases is simply too high a negative to utilise them.
Yes, this means that I not only don't carry a smartphone, but by and large don't carry a mobile phone at all -- a regression to pre-2000 states of comms.
This is a case of race-to-the-bottom behavior, and bad (or simply grossly incompetent) actor behavior poisoning the well for all.
It's an exceptionally strong argument to replace, as rapidly as possible, the present set of hosted online services with privately provisioned ones. Sandstorm.io, FreedomBox, and similar concepts can't hit prime time too soon.
If Google knows what's good for it, it should support this as well. Its choices are having some access to user time and committment, or none.
(Google's previous behaviors mean I've largely left it behind for its namesake service. I interact with it principally through pseudonymous accounts, though I'm aware these offer fairly thin protections against a determined actor.)
As Cory Doctorow has said, data are the radioactive waste of the current age. My formulation is that data are liability.
Overreaching privacy-invading tools are bad news waiting to happen.
Taking advantage of end user provided permissions seems to be the norm instead of the exception.
A few scandals have risen because of it. I remember a popular "free" calculator app that was sending GPS data.
Oddly, most people don't seem to care. They'd rather give up their entire picture collection than spend $2 on a permissions restricted app.
Having more fine-grained restrictions than we already do won't solve the problem. Most people will simply accept the default "give this application permissions to do everything" right out of the gate. I'd be surprised if even close to 5% of the people on facebook have reviewed the applications they've given permission to in the last 12 months.
Oh, don't feel so bad about that. Pretty much every real name gets hit with so much spam now, it's not even funny. Or if it's not actual spam, it's people using your email for stuff they don't care about, like a throwaway account.
I'm getting pretty close to just not using my gmail account any more.
Wow, information is coming at an insane cost. Why do companies have to be so incredibly sneaky when trying to gather your digital information? There really needs to be laws put in place. Technology is growing at too fast a pace and we need laws in place to protect our privacy.
> When he says Google shouldn't make this possible at all, I'm not sure what he's asking for?
I thought maybe he was asking for something like:
1. Request password before allowing access (which seems reasonable if the user hadn't entered it recently; I mean you have to do this for almost every other security setting in your account)
2. Allow finer control over the data. Say not allow it to download the entire corpus or only access to meta data, etc (though that can be probably too complicated for a regular user). Maybe this simply means different permissions when they want full access versus recent / continual access? I could see that being possible more descriptive.
2. Encrypt mail and provide open, verifiable clients and open server protocols.
Google make only a little money from my GMail account. I'd gladly pay them twice that for a strongly encrypted email system that provides infrastructure for key exchange with a web of trust.
Well, of course. One could ask "What did he think was going to happen when he installed a 3rd party mail reader?"
Thing is, encrypted mail and trusted clients means you could store your email at supersketchy.ru and it wouldn't matter. It's the way to make those kinds of choices safe, Or, rether, just having permissions doesn't security is adequate.
This is insane. I have Google/FB test accounts that I use to try out new products. I am now inclined to set up offline mail to make sure that my emails are not readily available to anyone but me. Of course Google still archives my removed emails but I think their policy is to remove them after a certain period. Can someone at Google confirm?
How about feeling inclined to actually read the permissions that the service is requesting from you and deciding upon that?
Same thing applies on smartphones too. If an app requests a lot of permissions that do not look like a legit part of the service, stay the hell away from it. A couple of examples:
* Facebook Messenger does not need access to my location and call logs.
* The main Facebook app does not need access to my SMS.
* Signal does not need access to my calendar.
Solution: I have none of these apps on my phone.
Edit: a couple more examples:
* WhatsApp does not need to read my Google services configurations.
* Viber does not need access to my Bluetooth.
* Snapchat does not need access to my audio settings.
* Instagram does not need to run at startup.
* Microsoft Word does not need to have the ability to set an alarm.
Android is tricky. I'm not an expert at their permissions settings but it seems that some of them are worded alarmingly for over-reaching yet justifiable permissions. I'm thinking for example (not one you listed, but..) that displaying push notifications immediatly when the phone is not in use requires a permission to "prevent the phone from sleeping"...
This is exactly why I change email addresses every 1/2 years. I've forwarding setup from 3 of my old addresses to my current address and for all financial transactions I only use my current email address.
So when you want to look up an old email, you have to remember which three month period it was in and which email address that corresponds to? When you have conversation that spans multiple periods, you have to do this multiple times? This cure is worse than the disease.
I don't use email to have lengthy period conversations.. Didn't even know it was a thing until now!
Almost all of my conversations are over chat and my primary usage of email is to sign up with sites or receive updates on my orders on Amazon/whatever. I haven't felt it as a curse so far. YMMV
What is truly scary is that the banks and financial institutions have not implemented OAuth. Currently, financial data is provided to third party apps via aggregators, like Plaid and Yodlee.
Unlike OAuth, once you log into your bank with a third party app, they get an access token that allows access to your account indefinitely. There is no mechanism to monitor which apps have access to your account and ability to revoke the access to individual apps.
I posted about this a while back: https://medium.com/@johnie/let-my-financial-data-free-74f3b7...