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...
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 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.
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.
There is a dev version on XDA, but it's not fit for daily use as the mic and calls and camera don't work properly.
Github is a great example of handling OAuth scopes: https://developer.github.com/v3/oauth/#scopes
(you're right that it's often not used, though. I tried bitbucket and gitlab and both appear to only have a single scope)
"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.
Most of the time the client app breaks, but that's getting better with time.
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.
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.
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.
Pretty much only get cheques from charities/clubs now, haven't written one in maybe 10 years.
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.
Cash is reserved for shady landlords and tax evasion.
Maybe GP can make them use Transferwise, Currencyfair or the like?
While we could do ACH transfers, it's way easier to just write a check.
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.
Never doubt the American banking system's capacity to gouge the customer.
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.
No, this is just Stockholm Syndrome, sorry (and they charge you how much to print cheques again?)
Way easier is entering two or three numbers depending on the country (for SEPA payments it's two strings) , a value and done.
Details are saved if you want so you just need to pick it again next time.
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.
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.
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.
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.
2. I have to log provide my passwords to mint.com and hope they don't misuse them.
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.
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).
Some even provide APIs:
* ATM has fees unless you use your own bank's
* Transferring money takes quite some time to arrive
There's higher rate of contactless payment adoption in Oz though it's picking up fast here in the UK as well
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).
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.
- 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.
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.
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.
As I said above, Google even uses the terms when you do the signin: https://jaxenter.com/wp-content/uploads/2015/05/google-permi... and gives you direct instructions on how to manage them.
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 try to mitigate this personally by creating multiple Google Accounts, but it isn't foolproof---plus, not every social network lets you do that.
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.
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.
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.
Or just an AuthN-only protocol, like OpenID.
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.
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.
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.
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.
How many stories of the form "User-provided permissions used responsibly, nothing interesting to report" do you expect to see in the news?
I'm getting pretty close to just not using my gmail account any more.
In other words, if you care, make a technological solution, not a legal one, because the right laws will be too little too late.
Isn't the alternative basically vendor lock-in?
Or that this would mean disabling things like IMAP & POP?
Fleep sounds like a shitty service from the description, but at some point user's need to take responsibility for their actions, no?
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.
1. Don't allow 3rd party mail apps
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.
3. Click "Deny" when the app explicitly has Google's OAuth flow ask if you want to give it permission to read, create, and delete all of your email.
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.
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.
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.
Using mutt or offlineimap:
1. Configure POPS/IMAPS access to the account, use Maildir format locally.
2. Download all messages.
3. Copy your saved messages to another location.
4. Delete all email on server.
Local search tools can then be used to access that archive.
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