I maintain the position I have had ever since Twitter sold people on the ridiculous idea of "API keys": the correct path has always been adversarial interoperability (as we did back forever ago when people built alternative apps for instant messaging services); if Twitterrific had been designed to use the same API and authority as the official app--maybe as a fallback, if nothing else--Twitter would not have been easily able to kill it... they could try, but it would be a cat and mouse game at best, and the only real recourse they would have would have been to try to detect API abnormalities (which Twitterific could quickly fix, and frankly the skeleton crew at Twitter today likely couldn't do well anyway) to directly punish the end users for continuing to insist on logging in with alternative clients (as Snapchat is forced to do); and, while it is easy to just shut off Twitterific's API key and tell the users "too bad", I think having to take the war to Twitterific's userbase (as the app would be able to keep working forever, with only momentary brownouts) would be a tougher pill for Twitter to swallow, given that it had way too much marketshare at this point.
Unauthorized “gray” third-party clients were a more viable option in the days when vendors couldn’t easily update first-party client program installations in the wild, so the API had to be backwards compatible.
But it’s not really like that for Twitter. They can do rapid updates to the iOS and Android apps, and any holdovers of old client versions would be a relatively small segment.
I recall Microsoft tried to build and maintain their own YouTube client for Windows Phone around 2011-12. That’s probably the last time a major tech company tried this approach and it was out of massive desperation. Google seemed to make a special effort to break the app.
There's probably a need for legislation here. It's completely normal and vital for competition that you can make things that are (adversarially) interoperable with others in the physical realm and you can't really be stopped (as long as you don't just copy).
That's not really a thing once you involve software. It's trivial to lock things down using cryptography and constant changes, making any kind of interoperability entirely infeasible.
As far as I understand this is pretty unprecedented and very bad for an efficient market.
Idk, having other, especially adversarial, companies between service and a customer just sounds like a recipe for bad things being pushed. Like IE toolbars. Or addblock (i use it, but it certainly has societal downsides). Or all the things our ISP wants to do with our traffic. You'd need unimaginably well crafted policy for this to not go south and have us complain about the opposite shortly thereafter.
It's straightforward anti-trust - currently Twitter-the-company is bundling Twitter-the-client-software with Twitter-the-service, using the market position of the latter to maintain the market position of the former.
I have been running the same copy of Facebook and Twitter and certainly YouTube on my phone for many years now. The only people who have been able to try to push updates at people like that are Snapchat, and even they have a hard time doing it quickly and at scale: and it only results in a temporary loss of service for the alternative clients!
(And, even then, most of the success for Snapchat comes because 1) the official clients for Snapchat go far out of their way to do crazy obfuscation techniques and 2) they wield a ban hammer over end users over trivial infractions making it difficult to test; I fail to see how such would work for YouTube, where third-party clients are, in fact, plentiful).
At F8 back forever ago, the reason Zuckerberg cited for having to give up on "Move Fast and Break Things" and go to "Move Fast with Stable Infra" is because they in fact couldn't rapidly push updates to their apps across the myriad supported platforms the way they could with their website, and so they effectively had to maintain API compatibility across ridiculously long timespans of client versions... much long enough to let the alternative clients reverse engineer the new builds and have updates out before Facebook can just kill service to the old ones.
> But it’s not really like that for Twitter. They can do rapid updates to the iOS and Android apps
They can do rapid updates to the apps but doesn't it take time for users to apply the update? Where I work you can't expect people to update their app right away, it takes days or even weeks for people to catch up.
Twitter put in a reasonable about of effort to keep old clients working and compatible with backend changes. We had checks in place to avoid breaking changes to clients that were years old, and when things did occasionally get through they were rolled back very, very quickly. If I remember correctly there are people with old devices/jailbreaks running things like clients on like iOS 7 and things still work for them for the most part.
> They can do rapid updates to the iOS and Android apps
Sort of! I haven't updated my iOS install in many months. I don't see the new fake blue checks or a handful of other dumb new features, it's kind of great!
All your suggestions lead to a terms of service violation for the Icon Factory and would likely result in their Apple developer accounts being banned, especially if Elon wanted to pursue it.
Getting their developer accounts banned would affect their other products, as well as any future products.
Aside from all the above, the vast majority of their Twitterrific customers doesn't understand API keys and will complain and request app and subscription refunds, likely also leading to developer account problems.
Falken's Law applies here: The only winning move is not to play.
I hate Apple :(. Like, isn't it kind of ridiculous how the issue here isn't that doing this is somehow illegal, but that Apple is willing to step in to remove apps that hurt fellow Big Tech companies? Apple simply should not have centralized control over what software can and cannot exist: that's the real issue.
The writing is on the wall though, Apple is going to have to let other app stores exist. I think the EU said so already, and I would bet the Brussels effect will make this happen elsewhere.
I maintained an adversarial browser extension with around 100k users that added stuff like tooltips and keyboard shortcuts to a browser game, for about 3 years. The reward was the developer copying a couple of my easiest ideas, then sending me legal threats and banning a bunch of my users (who were their paying customers). The engineering time they spent (quite a bit) trying to detect my extension or break it could have been spent doing things like adding ARIA roles and alt text, but they don't care about people with disabilities.
I kept it going for 3 years because I cared about the people who used it, and the developer struggled to block it because it's hard to outwit someone who worked on web browsers. In the end though, it's not worth doing free work for a company that doesn't respect the needs of their customers. Go elsewhere.
Your jailbreak spirit lives on, a big thank you! A tweak exists for the official client to clean up a lot of the issues:
https://github.com/BandarHL/BHTwitter
Hopefully this now gets more support with the antics that Twitter has pulled with these 3rd party clients.
Twitterrific makes money; it has a whole team of developers whose salaries are paid by them existing in the App Store and taking money via subscriptions. Adversarial interoperatability would result in Twitter sending the team a cease and desist, and given that their product isn't particularly decentralized or hard to enforce legal action against, they would probably lose the lawsuit or fold early. I think you need to understand that the number of people who want to be in this kind of relationship with an entity far larger than them is pretty small, and clients of this sort are invariably some sort of open source script or small project by a single developer without much to lose. A Twitterriffic where you could lose your access to you account and its many thousands of followers is not actually something people will use.
While I think I've come around to this position, the big question here that comes to mind is: does this even work for iOS apps, given Twitter could just go to Apple (the App Store team, I guess) over it?
This is the rub, and I do believe the answer is "no" :/. But, "Apple having central control over software development and distribution is, at its best, an extra-judicial defense of surveillance capitalism (...and, at its worst, an extra-judicial defense of totalitarian regimes)" is at least nothing new :(.
I really miss the iOS jailbreak ecosystem--back before Apple really started to win--as I felt like I could just build whatever I wanted (as long as it was legal and I definitely had lots of lawyers to check some of the stuff I had wanted to release ;P) and push it without asking for permission from Big Tech :(.
So I am not a lawyer, and if you do this stuff you should get a real lawyer (I mean, I have lots of real lawyers! ;P), but I am on the front lines of a lot of these battles (look into who I am if you haven't; hell: I've had Snapchat once try to come after people in my ecosystem, and the only thing their lawyers had as an argument was trademark law... I easily shoved them away), and I am going to claim Twitter would have no legs to stand on. At best--at BEST--they could ban you and all of your company accounts from their service.
Heh. To save some people a click: An important figure in the iOS jailbreaking scene (maker of the foundational tweaking framework and app store).
Thanks for all the good times. Jailbreaking was great for my experimentation urge and taught me a lot about Unix. It also informed some software opinions I still hold today (much more things should work like WinterBoard's layering). A jailbreakable iOS device is a great educational toy for a kid interested in messing with technology (Amazon Kindles are good for this too, by the way).
And thanks for also being involved in legally defending these freedoms. (I've been waiting for a chance to say this without writing a completely unproductive comment)
How would it not be a CFAA violation? E.g. if they included the official client's API key, surely that falls under "(6) knowingly and with intent to defraud traffics (as defined in section 1029) in any password or similar information through which a computer may be accessed without authorization, if—(A) such trafficking affects interstate or foreign commerce".
(I say this not because I think it should be a crime, but because I think the CFAA is a terribly broad law)
So maybe they can't sue the company making a third party app. But take Discord for instance. It's against the Discord terms of service to use a third party client, and there are stories of Discord banning users who do use third-party clients.
Now, Discord doesn't need to sue anyone to stop me from using a third party client—the threat of being banned is enough deterrent to keep me on the official client.
Discord doesn't ban third party clients, only illegal stuff like spamming.
From the people at Discord:
> I run the infrastructure department at Discord which includes our anti-spam engineering team --
Just want to +1 what you're saying and confirm that we are never trying to ban third party clients (that aren't self-bots). Honestly, it would be a waste of our time and basically do nothing good for Discord.
I talked about that in at least half of my original comment. To repeat, Twitterific managed to get to having the kind of marketshare to make that war interesting (in a way Discord clients never have and likely never will: they didn't make the same bargain with third-party app developers that Twitter did, where Twitter left most of the innovation to third-parties).
I apologize if this comes across as a snarky tangent, but I'm genuinely curious if law firms would even contract with Twitter now, given Musk's willingness to not pay bills.
>and frankly the skeleton crew at Twitter today likely couldn't do well anyway
You can just use attestation to make sure that people are using the official twitter client and not a third party one. There is no cat and mouse game no that mobile platforms offer security against malicious third party clients.
I don't know the specifics about Twitter's API saga over the years but... why isn't this the case? Why does Twitter need to be involved on the client side with consumption of the API?
> Why does Twitter need to be involved on the client side with consumption of the API?
Twitter is an advertising company. Alternative clients do not show Twitter's ads nor return to Twitter user data, so Twitter makes no money when alternative clients get used but still incurs bandwidth costs. There is no profit, only cost, in providing an exchange for short text messages; the profit all comes in the advertising, and that requires control of the client UI.
Just yet another reason to eradicate this cancerous, disgusting business model. It seems like the majority of the evils of tech in the past decade can be attributed to it.
Can you provide any citation for them having "legal backing"? I literally participate in hearings at the Copyright Office at the Library of Congress over people providing adversarial interoperability and I have never seen any functional legal argument against such.
I see plenty of discussion about CFAA being used against scrapers, particularly automated "bot" scrapers, but I don't see anything about alternative clients, where a human consumer of the service is barred from using the API. But I also only did cursory searching, so some sources for CFAA applied to API would be helpful.
I'm not sure how this would be any different than other software projects that use an API they don't own. Things like Cider for Apple Music, Ripcord for Slack, and the many Spotify clients all come to mind. Perhaps those are less aggressive in pursing 3rd party clients?
The idea is you get the content for free if you also get the ads. Why do you think publishers don't expose an API client that serves their content for free?
The issue is why can't Twitter charge for tweets via their API, but offer them for free in a browser if they are served alongside ads. Perhaps their own internal research suggests so few people would be willing to pay that it wouldn't be worth maintaining the API, but it would be nice to hear more info about this.
