Hacker News Reader

Comment by strken | Hacker News Reader

How long before we go back to dodgy apps that just ask for the user's email and password, if regular API access is so heavily restricted? I know there's an npm package out there for my bank that runs a headless browser and requires full credentials, which is terrifying.

View on HN

I've noticed both on Coinbase and Ally recently that connecting other accounts for transfer lets you do it instantly in a little popup window that asks for credentials for other banks. Seems like a big step backwards in training users.

This is because the vast majority of banks don’t have APIs and Plaid is the service which builds these connectors.

At least the EU is trying to fix this https://www.cnbc.com/2017/12/25/psd2-europes-banks-brace-for...

Go back? When did we migrate fully? Most banks still do this (e.g., Chase).

Is there anything stopping dodgy apps from doing that now?

No, but users tend to think twice and avoid them if there is a less dodgy alternative

It's more costly so it probably changes the economics of spam.

I'm lost - how does what your bank does and what Twitter does connect?

I think the point was that if providers like Twitter or Bank X don't provide a useful enough API then people will just skip the API entirely and use something like a headless browser.

Right now if you want to connect a third party application to your most online banking accounts you need to give that third party application your online banking username/password, or log in to your online banking through the app.

The suggestion is doing this for Twitter too, so instead of using an API key you would log in through an app and it would scrape the data it needs.

Twitter is currently locking down their API and making it harder for developers to access. My bank doesn't even have an API, but developers still gain programmatic access to it, only they ask users for their full credentials instead of limited, monitored, and revocable API access. My concern is that Twitter's new restrictions, and restrictions like them, will push apps towards just collecting a user's login credentials.

How is running a chrome headless any different than running it normally, that's how you login to your account, don't you?

Users don't want to give third party apps full access.

It's exactly the same thing, which is why it's bad. When I log into e.g. CoolQuiz[0] on quizzes.cambridgeanalytica.com with Facebook using OAuth 2, it requests a limited list of permissions from Facebook, which are shown to a user, and which don't include things like like resetting the user's password or changing the user's email address. It gets back an access token which can only be used for doing those things, and Facebook can track what's done with that access token, in the case that e.g. CoolQuiz uses it to read personal information from all a user's friends and microtarget advertising during a US election. Headless chrome is indistinguishable from a normal user, which means it can do absolutely anything a user can do and can't be tracked.

[0] probably doesn't exist, just a hypothetical example

Right, i missed the oauth2 scoping aspect.

Reply on news.ycombinator.com