Fuck it, I am going to build an open source project with the sole goal of automating access to all of these sites with selenium or something.
Get ready for war(in the nice, data science-y way)
Get ready for war(in the nice, data science-y way)
Incidentally, I have never used one, because that requirement is completely insane.
(Of course there's a huge gray area of things they could do that you wouldn't like, but that would't ruin them. But there's a clear difference between questionable things, like selling your data to advertisers, and completely not-ok things, like stealing your money).
Because there is such thing as a read-only API. But logging into the banking site as a customer permits the aggregator to take actions as the customer, like wire transfers--which are not reversible, and not typically covered by fraud protection.
Sure, I might trust Mint not to do that, but what if Mint gets hacked? By definition, Mint can access my bank creds in plain text, since it must paste them into my bank's website. That is worse security than even my own bank's website, which undoubtedly stores only the hash of my password.
My bank is not going to indemnify me for fraud caused by Mint's security problems. Bank agreements usually say "don't share your account creds," so if you do, and then lose your money, the bank is not likely to make you whole.
No, it's completely different. The entire point of keys is avoid having to store credentials, it has nothing to do with permissioning. In the case of Mint etc., they have to store credentials because there is no token/key system being provided from the banks (ie: oAuth). In the case of something like oAuth creds are never sent to the 3rd party.
And the ironic part of this is if they banks simply provided something like oAuth then they would have MUCH more control over who they worked with and have an easier time managing 3rd party data.
They've open sourced much of their code. Take a look at https://github.com/wesabe/ssu and the other projects in that organization.