Hacker News Reader

Comment by xmodem | Hacker News Reader

The 3rd party is not making the API request though. I am, just using software that didn't come from the platform vendor.

Many 3rd party twitter clients have expressed a willingness to display ads if provided an API to do so.

As someone who has lost precious accessibility capabilities because of restrictions on 3rd party clients, I unfortunately have to point out that I don't really have a choice of what platforms I do or don't interact with in a lot of cases. I wouldn't stay at my job for very long if I didn't tolerate Slack's BS, for instance.

View on HN

Let me offer you a question then: Do you know how much data the OG App is taking from you while you authorize it to work on your behalf? How do you know it's not reading through your entire message history? Or building its own network graph of your friends to sell? How about security? How do you know it's securely storing your credentials? Or that it's not selling said credentials as well?

Like in this scenario to Facebook it is in theory effectively you. Not the app operating on behalf of you with a limited set of permissions.

Yes, people can and will write malicious programs. Those will sometimes take the form of third party clients for a service. That is not and will never be a valid argument against them being allowed to exist. Monopolies are not ok. Abusive behavior by the dominant market players isn't ok.

Yes, but my point is that said clients should have to talk through properly secured APIs and required by law. Until then, an app like this is a massive, MASSIVE security risk and I would question the sanity of any team that saw something like this and ignored it.

> should have to talk through properly secured APIs

I don't follow what you mean by this. The API endpoints that a company provides ought to be secured properly. In practice they might or might not be but obviously they ought to be.

I don't see what that has to do with third party clients though. A third party client is stuck interacting with whatever API the company provides, however secure or insecure it might be.

I mean from another perspective this is effectively a MITM style way of interacting with Meta's API. They are behaving as another unauthorized layer between the user and Meta's API. In actual secure systems involving third party clients the client usually authorizes itself on behalf of some user requests or permissions, so while it does things for the user there's a clear and secure delegation of permissions.

Have you done much work with authorization? To put it in another way let's say there was a website that said it authorized with Steam. It asked you to put in your steam username and password. Is this secure?

Now let's say that same website instead redirected you back to Steam (properly) and requested authorization on behalf of you. Is this secure?

Now which bucket does this app fall under?

> To put it in another way let's say there was a website that said it authorized with Steam. It asked you to put in your steam username and password. Is this secure?

"Is this secure?" fully depends on what the attack vectors you're considering are. Breach of the server's database? Make it an app instead of a website and make requests directly. Malicious code in the client itself? Make it open source. Now it's even more secure than the official client.

But regardless of all of this, how is it any of the service provider' s business what I do with my login details? It's my data on my account. If I use it in an insecure fashion, that's my problem. I am free to post my login details on Twitter for everyone to see, so why can't I put them in a database on some russian dude's basement server?

Moreover, exactly how does said 3rd-party app differ from a web browser? Is it not a 3rd-party that has full access to login credentials, cookies, etc? Do they prohibit certain browsers from using their websites and APIs?

> They are behaving as another unauthorized layer between the user and Meta's API.

Unauthorized? Hasn't the user explicitly authorized this layer by installing the app?

This might not be the response you expected, but the app is only a security risk because it's not open source, and you can't audit its changes when you install an update. :)

Sure, there's a risk there. But it should be my choice whether or not to accept that risk, not Meta's.

In this case the risk you take doesn't matter (though I argue from a security standpoint this is something you should really care about in any argument around Meta), it's the risk Meta takes by allowing it. Because if the company takes your data and runs, Meta is the one also on the hook for not securing their APIs. If it turns out they're farming passwords from users to sell to whatever group ultimately the class action lawsuit will come out with knives facing Meta.

Like this is a security problem, straight up. I would hope that you can agree on this and that not securing your API is bad.

Should you secure your API? Of course. But you should not secure my data from me.

What do you mean? On what planet is it a provider's fault if a third party farms logins through a custom client. It's not their fault if I get phished, if the little booklet I store my passwords in under my pillow gets stole, if my computer is infected with a RAT... so why would it be in this scenario?

I only got a few posts into the thread before Twitter booted me out for not having an account, so maybe there's some context I'm missing, but what kind of "not securing your API" are you talking about? The fact that a thir party, explicitly authorized the the user, was able to make actions on the user's behalf, doesn't make it secure, it makes it functional.

> What do you mean? On what planet is it a provider's fault if a third party farms logins through a custom client.

Earth: https://en.wikipedia.org/wiki/Facebook%E2%80%93Cambridge_Ana...

> Cambridge Analytica then arranged an informed consent process for research in which several hundred thousand Facebook users would agree to complete a survey for payment that was only for academic use. > However, Facebook allowed this app not only to collect personal information from survey respondents but also from respondents’ Facebook friends.[13] In this way, Cambridge Analytica acquired data from millions of Facebook users

FB gave them data about friends, when it was supposed to only give them data about respondents. Totally different situation.

Yes, the reason this happened was that when a user authorized the Cambridge Analytica app, it would have the ability to view information about all of that user's friends. Sound familiar?

The fault was not in anything CA did, even though I think what they did was bad. The fault was in Facebook letting clients access more data than you authorized them to.

If I approve an access request for a low level engineer to get a single repo from github, and github lets them access every repo on our orgs account, that's a huge fuckup by github, not me.

No, not even remotely similar. A user authorized CA to see their data for the purpose of a research suvey. CA got more data than the user thought they were giving them. With a custom client, the user is giving the client their account for the purpose of accessing all of Facebook through it. The client is getting exactly what the user is giving them and it makes perfect sense that it needs it.

If you use the third party app, it might be doing all that stuff. If you use the official app, it will be doing all that stuff.

Reply on news.ycombinator.com