14 ms·
Oh wow, this app got pulled from everything because it's an unofficial 3rd party client for Instagram? I'll say it again, companies should be legally forbidden
by amatecha 4y ago
Oh wow, this app got pulled from everything because it's an unofficial 3rd party client for Instagram? I'll say it again, companies should be legally forbidden from blocking 3rd party clients. They don't have to explicitly support them, but taking action to explicitly thwart them (and writing ToS that forbids them) should be outlawed. There's no reason I should have to be subjected to untold tracking, snooping and advertising functionality to be able to post or look at photos and comment on them. Tech companies get to exploit the public under the guise of something useful, while also getting to completely dictate the terms of that usage. The only thing that limits their exploitation of users is the laws applicable in the relevant jurisdictions (and sometimes not even that). Too bad looking out for the rights of users is apparently just a complete non-issue to anyone in power.
- onlyrealcuzzo 4y agoWithout control of the client, it gets much harder to fight abuse.
- amatecha 4y agoIf you've ever worked on an online service, you might realize that what you ship for the client is almost irrelevant -- it can all be reverse engineered and an unofficial client can _always_ be created. This happens for all online services, even if it's just someone's data-mining app running on a local machine. The number one rule is "never trust what comes from the client", because it's trivial to create carefully-crafted network calls to basically do whatever the API allows (and sometimes more than what was supposed to be allowed). So, obviously 3rd party clients are thus able to perform malicious acts, but existing laws already forbid this. My suggestion to ensure 3rd party clients are always legally permitted isn't mutually exclusive with existing laws protecting the creators of services and software. :)
- xvector 4y ago"Never trust the client" is true, but in practice, some control over the client still helps reduce abuse if you make third party clients a lot harder (eg remote attestation.)
- dangero 4y agoYou should check out Apple App Attest —- this just isn’t true any more for mobile. https://developer.apple.com/documentation/devicecheck/validating_apps_that_connect_to_your_server https://developer.apple.com/documentation/devicecheck/valida...
- Matheus28 4y agoI haven't read it thoroughly, but given the App Attest service runs on the OS, why can't someone just find the certificate for it hidden somewhere and use that to sign fake attests in userland? This is just an extra layer of obfuscation. It doesn't prevent someone from faking api calls with no app (or phone) involved.
- btown 4y agoGiven that this only runs on certain Apple hardware, I wouldn’t be surprised if the Secure Enclave holds that certificate and can confirm at an extremely low level that it is being used only to sign a hash of of the app code itself and a shared secret with the app developer. Brilliant, in a scary way. In a way it makes data portability regulations all the more important.
- Matheus28 4y agoFrom my quick reading of the docs: It generates a public-private key pair that is stored in the secure enclave, then it sends that public key (or the hash maybe) to Apple for them to sign. The rest of the stuff is as you expect. One could simply figure out how the request to apple is made to get them to sign a key, and that's that. Get them to sign a key and pretend to be the app from now on. I guess this prevents spam from someone signing thousands of keys using a specific phone's serial number, though. Assuming there's an unique public-private key for each phone apple makes, one can't simply get them to sign keys with random serial numbers.
- origin_path 4y agoThe way these schemes usually work is that the pairing is done at the factory. Apple switch the iPhone on for the first time as it's being made, it generates a private key that never leaves the secure chip and then presents the public key. The public key is then signed to create a certificate chain and the certs handed back to the device for storage. So, there's no way to beat it except by extracting a private key, or by using some software exploit to confuse it into signing the wrong thing.
- rootw0rm 4y agoback when MechWarrior Online was still pretty new, I reversed the login app (100% .Net, very little obfuscation) which allowed me to access test servers that were testing an unreleased map. Fun times
- zeta0134 4y agoI agree with you, but specifically, I believe it is the user which should have this control. This prevents abuse by the service provider.
- CGamesPlay 4y agoWell, if valid uses for clients are outlawed then the only people buying clients will be the ones trying to abuse the system. So really all the policy does is change the market.
- josephcsible 4y agoDo you also support games using client-side anti-cheat in your OS kernel?
- Matheus28 4y agoThis seems a bit unrelated but I'll chime in with my opinion. Unfortunately for some types of games (first person shooters), a modified client can be game ruining for other players. For me, as long as it's only running while the client is running, and doesn't send private data remotely, I'm okay with it. At least on Windows there's not much difference in terms of privacy of something running in the kernel vs userland in the same user as your important documents. It can read your entire filesystem and attach to running apps anyway without needing kernel access. So the "in your OS kernel" part is only concerning if their anti-cheat is coded poorly enough to cause a BSoD.
- LtWorf 4y agoAll wonderful. Except the anticheat doesn't work and only active moderation stops the game from being ruined.
- Matheus28 4y agoIt prevents the more amateurish cheats, which by itself reduces cheating in the community by a lot. Obviously in these kind of games, active policing is the only way to find the most sophisticated cheaters. But the anti-cheat does help.
- chaostheory 4y agoMeta isn't some utility people can't live without. It's optional. If you're worried about abuse, then don't use it.
- yibg 4y agoDoesn't meta have an obligation to product users that do want to use their product? This is like saying people should be free to pee wherever they want, if you're worried about the smell, don't walk there.
- chaostheory 4y agoActually, the pee analogy fits better with your argument. You’re arguing that people can siphon electricity and use meta’s servers without paying (via ads). As I’ve already mentioned, meta isn’t a utility that people can’t live without like a phone. If they don’t like it, they should use something else. There are many alternatives
- jjav 4y ago> Meta isn't some utility people can't live without. This is not true for large parts of society. There are many institutions which force you to communicate via facebook, so not having access to it means you're locked out of parts of your real life. This is horribly wrong by those institutions, of course, but here we are. It should be illegal, but isn't yet.
- chaostheory 4y agoWhich institutions? if it affected “a large part of society”, I would imagine that I would be aware of it.
- jjav 4y agoSchools tend to be worst offenders, clubs, companies (heard of at least one company which only honors warranty support via facebook!).
- deleted 4y ago[deleted]
- MattDemers 4y agoEvery time this kind of thing happens I just remember how much bigger Twitter got with the help of third-party clients, and then implemented terrible login token limits to prevent any from becoming as good as their own offerings once traction picked up.
- amatecha 4y agoYup! As a Twitter user since 2007 I've watched as 3rd party clients were superior by far (TweetDeck was still my favorite), and have now been left in the dust as Twitter leaves them for dead by cutting off API features to them. Twitter itself has never made a client as good as TweetDeck or TweetBot, and invariably never will.
- deleted 4y ago[deleted]
- slimsag 4y ago> Twitter itself has never made a client as good as TweetDeck or TweetBot, and invariably never will. tweetdeck.twitter.com exists and I use it regularly, what am I missing?
- nilssonanders 4y agoTwitter bought Tweetdeck for $40 Million in 2011.
- amatecha 4y agoExactly right - I meant the "real" TweetDeck of 2008-2010 lol :) Multiple columns of custom user groups, so straightforward. Oh yeah, no ads!
- MattDemers 4y ago"Yellow" Tweetdeck.
- Matheus28 4y agoWhy should 3rd parties be allowed to make unauthorized api requests? Additionally, some apps are only monetized through advertisement, and 3rd party apps don't display them. How do you expect the 1st party to stay in business? I don't align with Meta on a lot of issues, but they should be able to control what apps interact with their platform. Don't like it, don't use it.
- xmodem 4y agoThe 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.
- fzeroracer 4y agoLet 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.
- josephcsible 4y agoSure, there's a risk there. But it should be my choice whether or not to accept that risk, not Meta's.
- fzeroracer 4y agoIn 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.
- voidwtf 4y agoOk, that’s fair, but how should the platform be compensated for the resources expended by the users or developers in question? Would you be ok with a usage plan? Something like $1 per 10,000 tweets read? I mean, the developer could save money by caching the most popular tweets and serving them from their cache, I imagine they’d have to charge for that infrastructure though and somehow they would pass the costs into the user. Maybe the could offer a monthly plan, with some kind of fixed cost that would keep most users fed with tweets while also not making uses worry about usage based billing. Maybe Twitter/Insta/whatever could just require you to have a paid plan to use 3rd party clients?
- josephcsible 4y agoIt would be reasonable to consider setting up such a paid plan, but that's not what Meta did here, and what they did was totally unreasonable.
- amatecha 4y agoSure, that's fine by me. Or even "video content is restricted to 240p unless you have a paid subscription, then you can see videos in 1080p". Right? It's 1000% possible to come up with totally fair business models that aren't so blatantly exploitative. Right now "the user is the product" on ANY free service. Previously there was App.net, which was effectively "Twitter but you pay for access". It had a free tier which had very reasonable limits. It was actually super awesome, and it actually provided a whole identity platform, enabling 3rd party applications of different kinds (for example an Instagram-like, Favd[0]). Unfortunately it didn't pan out, not sure the whole backstory, but it was a really amazing platform and I would love to see more internet services like that. [0] https://www.eriksoderstrom.com/p/favd-app-nets-gateway-drug https://www.eriksoderstrom.com/p/favd-app-nets-gateway-drug
- cortesoft 4y agoOk... what if they said, "it is free if you use our app and let us advertise to you, or you can pay us and use any client you want"?
- quickthrower2 4y ago> There's no reason I should have to be subjected to untold tracking, snooping and advertising functionality to be able to post or look at photos and comment on them. You don’t! Just don’t use meta products at all!
- d110af5ccf 4y agoI agree with you wholeheartedly. However I can't resist shilling self hosted alternatives here. > There's no reason I should have to be subjected to untold tracking, snooping and advertising functionality to be able to post or look at photos and comment on them. Stand up your own PixelFed instance for your family and friends today!
- olliej 4y agoOn the one hand I agree with you, and I detest FB/Meta, but the purpose of these apps is almost universally “block the ads that pay for the service”. Given that, what should a company do?
- geysersam 4y agoOf course they should be able to block 3d party clients. Just because it's technically possible to hijack an API, doesn't mean it's legal or ethical. If you don't want to be tracked, don't use Instagram. However, Meta blocking the developers fb accounts is basically harassment. Let the courts sort it out if their app is illegal. Meta shouldn't take things into their own hands.
- nobody9999 4y ago>Of course they should be able to block 3d party clients. Just because it's technically possible to hijack an API, doesn't mean it's legal or ethical. If you don't want to be tracked, don't use Instagram. This is the bit that's confusing to me. If I want to access my FB/IG/whatever content, and present my credentials to the server along with a valid request for my data, why should Meta care how I do so? I could be using nc[0] piped through openssl, rather than a web browser (do you believe Meta can mandate which browser you use and/or what add-ons/extensions it runs?). Is that "hijacking" the API? If the answer to that question is "no," then shouldn't I be able to write my own client, to access my data, too? If you think I should, then how are either of those (nc, write my own client) really different from using software written by someone that's not me or Meta, as long as I (providing authentication/authorization for my own access) use it to access my own data? [0] https://www.unix.com/man-page/Linux/1/nc/ https://www.unix.com/man-page/Linux/1/nc/
- free652 4y agoThe data server via API isn't yours, that's FB's data. You can download YOUR data via a page on the FB site.
- Nextgrid 4y agoThe data served via the API is ultimately what's displayed on the screen of the official client - if they're displaying it to you, they're happy for you to be seeing it and it shouldn't matter whether you're seeing it in the official client or third-party.
- roydivision 4y agoNonsense, it’s a private company, they can allow or not any access to their platform. I’m not a fan of Facebook in any way, but they have the right to do this, and ban users for their own reasons. Don’t like their policies? Don’t use the service, I don’t.
- SergeAx 4y agoDevil's advocate: you see a ToS when using service for the first time. If that ToS is not illegal in your jurisdiction - you may either accept it, or abstain from using the service. How are you eligible to use any service beyond their ToS? It's like a private club: adher to the rules or go find another club. Or, even better, open your own.
- danaris 4y ago> companies should be legally forbidden from blocking 3rd party clients While, in cases like this, I agree with you, I think there needs to be nuance to a rule like this. Consider what would happen in the reverse case. A competitor arises to some aspect of Facebook's services—say, an app that does something kinda like Instagram, but not quite—and becomes somewhat popular. Facebook adds support for accessing this competitor's service from their own app—look how convenient! You don't need to download two apps, just our app! They replace the ads from the service maker with their own, thus starving them of revenue...or they just wait until some critical mass of users access the other service through their app, then offer free and easy migration from the other service to their own. Then they start introducing UX problems with the other service—oh, but it's not their fault. It's because of changes to the API or ToS of the other app! In short, if this sort of thing is mandated universally, it simply tips the scales back in favor of the behemoths already ruling the roost, who can afford to build support for a dozen competing apps right into their own, and use the good old Embrace, Extend, Extinguish (or any similar playbook) to make sure the competitors die of asphyxiation.
- cplusplusfellow 4y agoWhat you’re missing here is that you don’t actually have a right to be a user.