Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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?


> 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?


> 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?


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. :)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: