New developer requirements to protect our platform(blog.twitter.com)
blog.twitter.com
New developer requirements to protect our platform
https://blog.twitter.com/developer/en_us/topics/tools/2018/new-developer-requirements-to-protect-our-platform.html
105 comments
As someone who is apparently "old", I continue to not understand how Twitter has managed to trick an entire generation of developers into believing they need Twitter's permission to develop a third-party Twitter client. Has the law changed in some noticeable way to make reverse engineering the official Twitter client and extracting their first party keys for purposes of interoperability suddenly illegal? We used to do this all the time, at scale before Twitter's invention of the "API key", and the only recourse the service has is to try to detect weird usages of their backend and then punish the users... something that tends to be something of a PR nightmare. (FWIW, I am totally willing to believe the issue is that Apple won't accept them, but then that is Apple being the asshole, and we should be looking into ways of making that market collusion illegal, assuming of course that it isn't already.)
I can see two counter arguments. One, you don't want to go with Twitter, or any large corporation for that matter, to court. They have a legion of lawyers and you don't. They have budgets for these kind of cases, you don't. Even if any dispute you have with them won't make it to a court you'll lose precious time and resources consulting with lawyers in order to answer their C&D demands, which I guess at some point will escalate if you keep ignoring them.
Then you have the practical part. Would you really base your project on reverse engineering and hacking a third party service? It will end up being an arms race. Everytime they change something you'll race to hack it again. In the meantime your service will be inoperable. If your user base is in the tens of thousands that will kill you. I can't think of any reliable service that every couple of months or so would go offline even for a few hours until the developer finds a way to circumvent whatever countermeasure Twitter came up with.
So you play nice and follow their rules. Even if they suck, which by the way is the main reason why Twitter lost all the love of developers and has stagnated for the last years.
Then you have the practical part. Would you really base your project on reverse engineering and hacking a third party service? It will end up being an arms race. Everytime they change something you'll race to hack it again. In the meantime your service will be inoperable. If your user base is in the tens of thousands that will kill you. I can't think of any reliable service that every couple of months or so would go offline even for a few hours until the developer finds a way to circumvent whatever countermeasure Twitter came up with.
So you play nice and follow their rules. Even if they suck, which by the way is the main reason why Twitter lost all the love of developers and has stagnated for the last years.
> It will end up being an arms race. Everytime they change something you'll race to hack it again. In the meantime your service will be inoperable.
They (any service with a large user base across many devices) are at a serious disadvantage of not being 100% in control of app upgrades across the legion of devices and app versions supported. They are just as likely to break a legitimate user's app as yours (even higher, imo). I don't think the technical war is nearly as difficult as you imagine. On the legal side, you might be right depending on the geographical location of the dev.
In regard to the original question, I think we'll begin to see a shift in that direction as these services tighten the screws. Like youtube-dl, Youtube++ app is a relief to anyone who watches much YT on a phone/tablet. It's easily sideloadable even on iOS and actually puts the user first with regard to permanently settable playback speed and ability to hide algorithmic suggestions among many other tweaks. It's based on a year+ old version of the official app and is still working fine even after being DMCAd. So you know they got Google's attention, but haven't had to update the app in almost a year. I also see these gray area tools as an important check on the power of the platforms to not abuse their dominance. Like jailbreaking was before Apple started incorporating many of the more popular tweaks into iOS itself.
They (any service with a large user base across many devices) are at a serious disadvantage of not being 100% in control of app upgrades across the legion of devices and app versions supported. They are just as likely to break a legitimate user's app as yours (even higher, imo). I don't think the technical war is nearly as difficult as you imagine. On the legal side, you might be right depending on the geographical location of the dev.
In regard to the original question, I think we'll begin to see a shift in that direction as these services tighten the screws. Like youtube-dl, Youtube++ app is a relief to anyone who watches much YT on a phone/tablet. It's easily sideloadable even on iOS and actually puts the user first with regard to permanently settable playback speed and ability to hide algorithmic suggestions among many other tweaks. It's based on a year+ old version of the official app and is still working fine even after being DMCAd. So you know they got Google's attention, but haven't had to update the app in almost a year. I also see these gray area tools as an important check on the power of the platforms to not abuse their dominance. Like jailbreaking was before Apple started incorporating many of the more popular tweaks into iOS itself.
> They (any service with a large user base across many devices) are at a serious disadvantage of not being 100% in control of app upgrades across the legion of devices and app versions supported. They are just as likely to break a legitimate user's app as yours (even higher, imo).
Yes they are? Alternative apps use the official API, their internal services use their internal API's, which are also likely versioned. So if the internal DM API has an upgrade, the website can change to the new version while the mobile app is using the previous version.
youtube-dl and Youtube++ are already solved problems. The fact that you have to sideload it means the user market is tiny and at this point I highly doubt YT even cares anymore.
> I also see these gray area tools as an important check on the power of the platforms to not abuse their dominance.
This is the weirdest thing you've said in a whole lot of weird things. YT proved how powerful it was via demonetization of so many creators videos. Nobody could do anything about it, primarily because the real power behind YT is that creators don't have an alternative, not users.
Yes they are? Alternative apps use the official API, their internal services use their internal API's, which are also likely versioned. So if the internal DM API has an upgrade, the website can change to the new version while the mobile app is using the previous version.
youtube-dl and Youtube++ are already solved problems. The fact that you have to sideload it means the user market is tiny and at this point I highly doubt YT even cares anymore.
> I also see these gray area tools as an important check on the power of the platforms to not abuse their dominance.
This is the weirdest thing you've said in a whole lot of weird things. YT proved how powerful it was via demonetization of so many creators videos. Nobody could do anything about it, primarily because the real power behind YT is that creators don't have an alternative, not users.
> Yes they are? Alternative apps use the official API, their internal services use their internal API's, which are also likely versioned. So if the internal DM API has an upgrade, the website can change to the new version while the mobile app is using the previous version.
I think we might be speaking about different things. My original point was that reverse-engineering Twitter's private APIs (used by the first-party app) is not as difficult to do or maintain as the parent suggested. My reasoning was that for the foreseeable future there will be legitimate users on non-updated clients, forcing Twitter to choose between disabling those clients or letting your 'cloning' of those apps' API calls continue to function.
> This is the weirdest thing you've said in a whole lot of weird things. YT proved how powerful it was via demonetization of so many creators videos. Nobody could do anything about it, primarily because the real power behind YT is that creators don't have an alternative, not users.
Maybe I wasn't clear. I'm not speaking about creators-vs-YT, but consumers-vs-YT in terms of anti-user restrictions in the YT app and website. Issues that grey area tools alleviate and therefore provide the only effective check on YT's ability to take them further. Just as abusive ads and tracking has caused a jump in adblock usage. The harder it gets to enjoy YT content through the first-party app, the more people will take the time to discover alternatives.
The concept generalizes to Twitter or YT or any platform (or creative industry) that achieves ubiquity or monopoly. Even if you disagree, maybe it sounds less 'weird'.
I think we might be speaking about different things. My original point was that reverse-engineering Twitter's private APIs (used by the first-party app) is not as difficult to do or maintain as the parent suggested. My reasoning was that for the foreseeable future there will be legitimate users on non-updated clients, forcing Twitter to choose between disabling those clients or letting your 'cloning' of those apps' API calls continue to function.
> This is the weirdest thing you've said in a whole lot of weird things. YT proved how powerful it was via demonetization of so many creators videos. Nobody could do anything about it, primarily because the real power behind YT is that creators don't have an alternative, not users.
Maybe I wasn't clear. I'm not speaking about creators-vs-YT, but consumers-vs-YT in terms of anti-user restrictions in the YT app and website. Issues that grey area tools alleviate and therefore provide the only effective check on YT's ability to take them further. Just as abusive ads and tracking has caused a jump in adblock usage. The harder it gets to enjoy YT content through the first-party app, the more people will take the time to discover alternatives.
The concept generalizes to Twitter or YT or any platform (or creative industry) that achieves ubiquity or monopoly. Even if you disagree, maybe it sounds less 'weird'.
I've never even heard of YouTube++ but it sounds like I need it in my life
> Would you really base your project on reverse engineering and hacking a third party service? It will end up being an arms race. Everytime they change something you'll race to hack it again. In the meantime your service will be inoperable. If your user base is in the tens of thousands that will kill you.
Depends on what the service is. youtube-dl faces this issue but is some of the best software I have ever used.
Depends on what the service is. youtube-dl faces this issue but is some of the best software I have ever used.
> some of the best software I have ever used
That's some hefty praise, do you mind explaining why it's so great?
That's some hefty praise, do you mind explaining why it's so great?
Twitter is a public company owned by shareholders, running a private service on their own servers. They have a right to try and control how their service is used by users and developers. If Twitter tells me I can't access their API, I probably won't develop that client not because I technically cant but because it would be an uphill battle to develop and put something out there if it depends on someones third party servers and that person does not want me to use said servers.
I don't understand this argument. Twitter hasn't tricked anyone. They have an enforceable terms of use agreement with their users. If you deliberately circumvent controls described by that agreement, they have civil recourse. It's their site and always has been.
> I don't understand this argument. Twitter hasn't tricked anyone. They have an enforceable terms of use agreement with their users. If you deliberately circumvent controls described by that agreement, they have civil recourse. It's their site and always has been.
That's actually not true, if it's public information, then you're free to grab it. See below:
https://www.theverge.com/2017/8/15/16148250/microsoft-linked...
By reverse engineering the API, sure they can shut you down, but a lawsuit? Hardly.
That's actually not true, if it's public information, then you're free to grab it. See below:
https://www.theverge.com/2017/8/15/16148250/microsoft-linked...
By reverse engineering the API, sure they can shut you down, but a lawsuit? Hardly.
Whoah, hold on. You're referring to a preliminary injunction issued in a case that hasn't been tried yet; not only that, but LinkedIn appealed that judgement, and their appeal is still pending. That case also revolved around antitrust liability, which Twitter doesn't have. It is not at all settled that anything in front of a login screen is public and not protected by TOS's. And, of course, here we're talking about things that appear after a login page.
https://www.ca9.uscourts.gov/media/view_video.php?pk_vid=000...
The 5-minute spans around minute 20 and around minute 53 are particularly interesting. Even HiQ agrees that they have no right to ignore TOS terms pertaining to things behind login screens.
https://www.ca9.uscourts.gov/media/view_video.php?pk_vid=000...
The 5-minute spans around minute 20 and around minute 53 are particularly interesting. Even HiQ agrees that they have no right to ignore TOS terms pertaining to things behind login screens.
>That's actually not true, if it's public information, then you're free to grab it.
Er, since when? Auernheimer/weev was sentenced to 4 years for "hacking" AT&T by changing a URL parameter to access other customers' info. It was questioned in the appeal decision that let him go, but the ruling was on narrow (venue) grounds.
https://www.wired.com/2014/04/att-hacker-conviction-vacated/
Er, since when? Auernheimer/weev was sentenced to 4 years for "hacking" AT&T by changing a URL parameter to access other customers' info. It was questioned in the appeal decision that let him go, but the ruling was on narrow (venue) grounds.
https://www.wired.com/2014/04/att-hacker-conviction-vacated/
So, let me get this straight: you seriously believe that Twitter is going to randomly select a handful of users and try to throw the book directly at them (as the person who made the client is not subject to the service's terms of service). Generally the only tort expressabale against someone who violates terms of service is "the service can be revoked" (or like, at worse, the "damages" involved... good luck demonstrating those against an individual user ;P), and so far as we have seen there is no reasonable civil argument (the DMCA certainly doesn't apply and the CFAA is rapidly being determined to not apply); but let's say that this was an option: you feel like some massive hefty fine or maybe a jail sentence for some random user (as again: the person who wrote the client isn't doing anything wrong) is going to serve Twitter's interests here?
I'm not sure I understand how you're using the word "tort". A tort is an action that causes damage. Obviously, Twitter can suspend service for a user violating their agreements, or, if the user is causing damage and circumventing Twitter's controls, they can go further and sue.
Fines and jail sentences are things only the government can impose. I'm not talking about what the government might do to someone violating Twitter's user agreements (I doubt they'd do much).
The overall gist of your argument is really hard to understand. Twitter makes a service available conditioned on an agreement they have with their users. That agreement is binding. The legal issues here seem pretty straightforward.
It's possible that we're talking about different actors in this story. You might be thinking I'm saying Twitter is likely to sue individual users who use third-party clients. I don't think that will ever happen. On the other hand, if you're the kind of organization Twitter is describing in this bulletin, making potentially millions of dollars by abusing the Twitter APIs to spam or deceive users, I have no problem at all seeing how Twitter might seek recourse in civil court. It's their site, and access is conditioned on their rules.
Fines and jail sentences are things only the government can impose. I'm not talking about what the government might do to someone violating Twitter's user agreements (I doubt they'd do much).
The overall gist of your argument is really hard to understand. Twitter makes a service available conditioned on an agreement they have with their users. That agreement is binding. The legal issues here seem pretty straightforward.
It's possible that we're talking about different actors in this story. You might be thinking I'm saying Twitter is likely to sue individual users who use third-party clients. I don't think that will ever happen. On the other hand, if you're the kind of organization Twitter is describing in this bulletin, making potentially millions of dollars by abusing the Twitter APIs to spam or deceive users, I have no problem at all seeing how Twitter might seek recourse in civil court. It's their site, and access is conditioned on their rules.
He's suggesting developers extract the keys from the official Twitter client and use those, bypassing the usual developer agreement.
I spent... 6 months trying to write a remote control for the google chrome dongle (not using Google's API). It was pretty clear that the official SDK had access to an entirely different API, and because it was all encrypted, I would never, ever, see any of it.
The bits and pieces of an API I did piece together (from older protocols), were stunningly unreliable. I am sure they were left in only to frustrate people trying to do exactly what I was.
The bits and pieces of an API I did piece together (from older protocols), were stunningly unreliable. I am sure they were left in only to frustrate people trying to do exactly what I was.
[deleted]
They could claim copyright over the API key (unlikely) or (more likely) ask a friendly prosecutor to charge you with violating CFAA. You are accessing their systems, not in a way they authorized. Enjoy some jail time. Sadly, yes, it has come to this. Eg: https://www.newsweek.com/most-hated-law-internet-and-its-man...
They don't need a prosecutor; CFAA includes civil causes of action.
The CFAA has existed since the 80s, and yet I have not heard of it being used successfully to stop all of the work we did in the 90s on third-party clients. Meanwhile, all of the recent stuff I have heard about the CFAA has been that precedent is being set that its super vague provisions can't be used to enforce a mere terms of service.
https://www.eff.org/deeplinks/2018/01/ninth-circuit-doubles-...
https://www.eff.org/deeplinks/2018/01/ninth-circuit-doubles-...
I think you're reading something into that 9th Circuit decision that isn't there. That decision held that the federal government couldn't use a TOS violation as a predicate for a felony CFAA charge. It did not hold that TOS agreements are unenforceable. Even the EFF isn't saying that TOS contracts are unenforceable --- and here we're not talking about browse-wraps, but on Twitter informing people directly as to their terms, and then having those people deliberately circumvent controls that enforce those controls.
For a straightforward counterexample to your argument about TOS enforceability, see 3taps. Or Facebook v. Power Ventures.
For a straightforward counterexample to your argument about TOS enforceability, see 3taps. Or Facebook v. Power Ventures.
"I continue to not understand how Twitter has managed to trick an entire generation of developers into believing they need Twitter's permission to develop a third-party Twitter client. "
It's Twitter's API, and Twitter's servers.
"Has the law changed in some noticeable way to make reverse engineering the official Twitter client and extracting their first party keys for purposes of interoperability suddenly illegal?"
If you don't have permission to use someone else's stuff, you don't use it. We were all taught that in kindergarten.
"We used to do this all the time"
The fact that you abused other's web servers back then doesn't mean that it was right then or now.
It's Twitter's API, and Twitter's servers.
"Has the law changed in some noticeable way to make reverse engineering the official Twitter client and extracting their first party keys for purposes of interoperability suddenly illegal?"
If you don't have permission to use someone else's stuff, you don't use it. We were all taught that in kindergarten.
"We used to do this all the time"
The fact that you abused other's web servers back then doesn't mean that it was right then or now.
The translation of this is: We're trying even harder to kill any and all 3rd party applications. 300 tweets per 3 hours global rate limit is bonkers. My favorite twitter app for android is probably dead after this.
On the plus side, signal to noise is about to skyrocket on Twitter.
How so? What's stopping bad actors from using their official client's secret (found on mobile apps binary)?
Scarcity enforces efficiency.
API monitoring stops bad actors; doesn't matter much if you extract the creds from a binary blob if the usage pattern begins to deviate from the norm, invalidating the creds and forcing a creds cycle.
API monitoring stops bad actors; doesn't matter much if you extract the creds from a binary blob if the usage pattern begins to deviate from the norm, invalidating the creds and forcing a creds cycle.
Invalidating creds would mean millions of users blocked overnight, which is something they would never do, too much friction for the vast majority of the users.
With these changes (limits), you’re not having millions of users. Those days are long gone.
API access is now effectively for ancillary or supporting tools.
API access is now effectively for ancillary or supporting tools.
Are you implying the official client no longer uses their own API?
I'm implying that non-official consumers of the Twitter API are slowly being relegated to second class citizens.
Not knocking it, it makes sense from a platform integrity perspective. It is what it is.
Not knocking it, it makes sense from a platform integrity perspective. It is what it is.
This will make maintaining an army of bots more expensive. It does little to actually stop it.
The API only makes it easy for the good guys to use twitter.
So you don't believe price effects the creation and maintenance of bots?
When maintaining an army of bots becomes more expensive than the amount of money they are making from it, they will stop doing it.
When maintaining an army of bots becomes more expensive than the amount of money they are making from it, they will stop doing it.
Having dabbled in the space a bit: (on the less-malicious side, scraping for archiving, I imagine pro bot-writers are far beyond me.)
There's an upper bound to "bot complexity"; that being the complexity you want to impose on a normal user. For many sites (e.g. instagram) it's often easier to just "pretend to be a normal user" and hit it from a headless browser. You lose some functionality, but at least for my needs, that's always been a sufficient fallback.
As such, I've always been of the opinion that the primary function of API limitations is to punish/limit/extract more money from the good participants.
There's an upper bound to "bot complexity"; that being the complexity you want to impose on a normal user. For many sites (e.g. instagram) it's often easier to just "pretend to be a normal user" and hit it from a headless browser. You lose some functionality, but at least for my needs, that's always been a sufficient fallback.
As such, I've always been of the opinion that the primary function of API limitations is to punish/limit/extract more money from the good participants.
Sure, it affects things at the margins. However that is all this does. The biggest outcry against bots is not the low margin spam/advertising related stuff. People learn to ignore that type of content almost as soon as they start using the internet. The real troubling bots are those used for harassment, influencing financial markets, and influencing political discourse. The first was never about pricing. The latter two are still amazingly cost effective. I would bet they would have to go up by an order of magnitude or two before the pricing effects start having a real impact.
A little more expensive maybe.
Most bot farms have a LOT of dev accounts, multiple apps, ways to automatically create an app, etc.
This is not a solution against bots.
Most bot farms have a LOT of dev accounts, multiple apps, ways to automatically create an app, etc.
This is not a solution against bots.
Extremely doubtful in reality though, it's still going to be all noise.
It's always been about how you follow people.
I have a few twitter accounts:
one where I follow people I know and devs and it's very noisy. It's nearly unusable, it's full of political rants, even from well known devs, angry tweets, just not very useful. I don't read it much.
The other twitter account I follow people who write funny tweets, and that account is a goldmine. I love it. I like almost every tweet. Nobody follows this account, it's just like a read only twitter and it's amazing.
I have a third twitter account for local news, I follow the local fire department, police, local news, local businesses, and it's also super great.
Twitter's android app makes it easy to switch between accounts, it's basically just like different feeds.
I have a few twitter accounts:
one where I follow people I know and devs and it's very noisy. It's nearly unusable, it's full of political rants, even from well known devs, angry tweets, just not very useful. I don't read it much.
The other twitter account I follow people who write funny tweets, and that account is a goldmine. I love it. I like almost every tweet. Nobody follows this account, it's just like a read only twitter and it's amazing.
I have a third twitter account for local news, I follow the local fire department, police, local news, local businesses, and it's also super great.
Twitter's android app makes it easy to switch between accounts, it's basically just like different feeds.
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.
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?
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?
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
[0] probably doesn't exist, just a hypothetical example
Right, i missed the oauth2 scoping aspect.
Users don't want to give third party apps full access.
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.
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.
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.
The new default limits for each endpoint are outlined below and will apply in addition to existing user-level rate limits for these actions. By default, an app (across all of its users) will be limited to:
- Tweets & Retweets (combined): 300 per 3 hours
- Likes: 1000 per 24 hours
- Follows: 1000 per 24 hours
- Direct Messages: 15,000 per 24 hours
They write that they can lift this requirements for certain apps. But any new 3rd party twitter client is pretty much toast.
They write that they can lift this requirements for certain apps. But any new 3rd party twitter client is pretty much toast.
>But any new 3rd party twitter client is pretty much toast
Unless they take the time to go through the review process and get a rate limit increase, in which case this theoretically should improve the app quality overtime as only those willing to put in the work will make it through.
Unless they take the time to go through the review process and get a rate limit increase, in which case this theoretically should improve the app quality overtime as only those willing to put in the work will make it through.
What a joke. The only thing that will improve app quality is evolution by natural selection. Shitty apps bleed users and bleed cash. Increasing friction lowers the number of new entrants and raises the cost of iteration ie the two things that increase the speed of evolution. The only viable apps will be incumbents, who are incentivised to not change anything and increase monetization ie ads and tracking.
Any old third-party Twitter client is pretty much toast unless Twitter deigns to lift the requirements for them. I'm not entirely sanguine they will.
This is per-user, not per-entire-app-user-base, AFAIK
RTA, "By default, an app (across all of its users) will be limited to: - Tweets & Retweets (combined): 300 per 3 hours - Likes: 1000 per 24 hours - Follows: 1000 per 24 hours - Direct Messages: 15,000 per 24 hours"
That sounds like the end of a lot of API use for small players... Review is noticeable hurdle for small/private projects, and at the same time services serving many small users will easily have trouble with the rate limits, unless they make it easy to get those raised (which is possible, but I'd be skeptical).
Instagram did this a long time ago with their API - they require you pass a Permissions Review [0] where you submit your featureset along with a website landing page (ex. for a product offering) for review by a human who then can accept or deny your application.
[0] https://www.instagram.com/developer/review/
[0] https://www.instagram.com/developer/review/
This is also the approach Facebook has taken in the wake of the Cambridge Analytica debacle.
Everything has shifted back to the walled garden approach. Twitter had destroyed a wide ecosystem of applications that promoted their brand several years ago via a similar approach. FB has done (and may be again doing) the same.
The message remains clear: don't build your business on another business without contracts and guarantees. When the utility of having you as a promotional instrument wears off, they will dump you.
Everything has shifted back to the walled garden approach. Twitter had destroyed a wide ecosystem of applications that promoted their brand several years ago via a similar approach. FB has done (and may be again doing) the same.
The message remains clear: don't build your business on another business without contracts and guarantees. When the utility of having you as a promotional instrument wears off, they will dump you.
> don't build your business on another business without contracts and guarantees
Or even with them: https://techcrunch.com/2018/06/21/twitter-smytes-customers/
Or even with them: https://techcrunch.com/2018/06/21/twitter-smytes-customers/
That's... amazing.
These two tweets really show just how WTF this was
> A vendor notified us of their acquisition at 6am this morning and shut down their APIs 30 minutes later, creating a production outage for npm (package publishes and user registrations). The sheer unprofessionalism of this is blowing my mind.
> It takes weeks to negotiate and sign an acquisition. You didn't find out at 6am. You couldn't give us a week? Even a couple of hours to take your service out of our critical path and avoid an outage? Fucking shocking behavior.
These two tweets really show just how WTF this was
> A vendor notified us of their acquisition at 6am this morning and shut down their APIs 30 minutes later, creating a production outage for npm (package publishes and user registrations). The sheer unprofessionalism of this is blowing my mind.
> It takes weeks to negotiate and sign an acquisition. You didn't find out at 6am. You couldn't give us a week? Even a couple of hours to take your service out of our critical path and avoid an outage? Fucking shocking behavior.
The number one reason I stopped developing an Application based on IGs API. The hoops you have to jump through was insane.
Full paragraph explanation for each permission you're requesting. (meh)
Video of the app working.
Only can use personal account for testing/polling API.
Full paragraph explanation for each permission you're requesting. (meh)
Video of the app working.
Only can use personal account for testing/polling API.
A common workaround after Twitter attempted to kill third party client apps was to have users register their own "app" and insert the API keys. So this will put a stop to that.
These new limits seem specifically designed to continue allowing that workaround. 300 tweets per three hours is about the upper limit of what a single user would do, so if you're registering a developer account just for personal use you can do that without any manual review or having to demonstrate having a real product.
You only require approval from twitter and a product website if you have higher usage than that, which is what would prevent you from using that workaround.
You only require approval from twitter and a product website if you have higher usage than that, which is what would prevent you from using that workaround.
I think I see what the OP meant, here are relevant excerpts from the article. New API access:
> Beginning today, anyone who wants access to Twitter’s APIs should apply for a developer account using the new developer portal at developer.twitter.com.
Existing API keyholders:
> Eventually, all developers with existing access to our APIs will be required to complete a developer account application in order to maintain their apps.
> Beginning today, anyone who wants access to Twitter’s APIs should apply for a developer account using the new developer portal at developer.twitter.com.
Existing API keyholders:
> Eventually, all developers with existing access to our APIs will be required to complete a developer account application in order to maintain their apps.
Maybe i'm misreading it, but it looks like you're essentially just filling out a form with your contact info and agreeing to the T&C for the initial "application".
I don't think I understand how the rules will affect that, won't the 300 per 3 hours limit on tweets still only affect the "app" a user generated their keys for?
Because $JOE_AVERAGE_USER is not going to convince Twitter's account approval team that they are a legitimate developer (because they're not).
Meantime: https://www.dropbox.com/s/hb7c0l54r8m0zoy/Screenshot%202018-...
I know that fixing/changing/upgrading things at scale is much harder that what most people think, but man... they have done nothing to fix these type of issues, and don't tell me is not something easy to fix.
The other day a journo complained on twitter about the problem of dealing with crappy messages: https://twitter.com/sarahfrier/status/1020512187322789888
So in less than an hour, I had a prototype to help to filter those type of messages: https://www.dropbox.com/s/z914olzgn68v660/Screenshot%202018-...
If a random dev can do this, why they can't fix it?
I like twitter, and I'm genuinely curious why some of these seemingly easy to fix problems are not taken care.
I know that fixing/changing/upgrading things at scale is much harder that what most people think, but man... they have done nothing to fix these type of issues, and don't tell me is not something easy to fix.
The other day a journo complained on twitter about the problem of dealing with crappy messages: https://twitter.com/sarahfrier/status/1020512187322789888
So in less than an hour, I had a prototype to help to filter those type of messages: https://www.dropbox.com/s/z914olzgn68v660/Screenshot%202018-...
If a random dev can do this, why they can't fix it?
I like twitter, and I'm genuinely curious why some of these seemingly easy to fix problems are not taken care.
I could redesign my bank's website in a week if I didn't have to deal with their codebase, build processes, technical debt, internal politics, or the real world complexity of building a production ready website at their scale ;)
What are we supposed to be seeing in your second screenshot? I just see an array of DMs, what's being filtered?
Yeah, sorry. You are right is not showing anything else besides the API result.
But is trivial to return a secondary, already parsed array. I haven't used the API in a while and was just seeing if I could achieve that.
But is trivial to return a secondary, already parsed array. I haven't used the API in a while and was just seeing if I could achieve that.
Isn't the issue with spam prevention is they adapt to your changes?
How would this impact a service like Buffer? Limiting posting 300 tweets per 3 hours certainly wouldn't be feasible, given the number of customers they have...
The existing large players probably already have their exceptions worked out, or will very soon.
Want to join that space? Gotta be lucky with review/limit raise request I guess. It's possible they just want services to start small and act legitimate to raise the bar for "bad apples" and will raise the limits easily afterwards, we'll have to see.
Want to join that space? Gotta be lucky with review/limit raise request I guess. It's possible they just want services to start small and act legitimate to raise the bar for "bad apples" and will raise the limits easily afterwards, we'll have to see.
The post mentions heavy API users will get exceptions based on their use-case.
I know a lot of the conversation about the API separates out good guys and bad guys, i.e. spammers.
But I'm more and more thinking that Twitter and other platforms should consider marketing automation to be a form of spam. Once you start questioning that there isn't a human behind the human account you give up on human interaction.
So yeah, maybe there's some vanity metric that marketing automation props up for companies like Twitter. But underneath that vanity metric, the real quality of the site is being diminished.
But I'm more and more thinking that Twitter and other platforms should consider marketing automation to be a form of spam. Once you start questioning that there isn't a human behind the human account you give up on human interaction.
So yeah, maybe there's some vanity metric that marketing automation props up for companies like Twitter. But underneath that vanity metric, the real quality of the site is being diminished.
This is basically "know your customer" for an API. It's episode N in "why the Internet can't have nice things." If you make a technology available at scale, it will be abused.
Compare with email spam countermeasures making it more difficult to set up a email server that other email providers will accept mail from. Or malware resulting in the rise of app signing and app stores.
Compare with email spam countermeasures making it more difficult to set up a email server that other email providers will accept mail from. Or malware resulting in the rise of app signing and app stores.
No more free $ETH giveaways. Just darker, more deceptive black hats.
Well, I guess my movie quiz bot (@whattheshot) which turns 8 in a few hours, is almost coming to an end then. I had to adjust so many things the last few years that the game lost completely interest to most of my players. I was shadow-banned anyway.
My last hope is that the "review process" they talked about could really differentiate bad apps/bots and interesting bots and let them work. But I honestly doubt it will happen.
My last hope is that the "review process" they talked about could really differentiate bad apps/bots and interesting bots and let them work. But I honestly doubt it will happen.
Thinking through this a bit... So the end result of this move is less SPAM and higher quality content. Great! But if SPAM is a form of activity (albeit a less desirable one) and activity represents feed liquidity - which directly impacts revenue - how does this not significantly hurt the bottom line? Time to short TWTR in Q4ish.
Given how many times twitter has screwed developers attempting to build things on top of their API, does anyone still care? Does anyone still think developing on twitter's API is a good idea?
We've updated the submitted title from ‘Twitter introduces new developer requirements “to protect our platform”’. Submitters, please leave out the editorial.
I'm the submitter:
This wasn't intended to be an editorial, it was intended to provide context. I believe that it's not clear from the title alone as you've included it here that it was Twitter. Yes, it's on the twitter blog platform, but so are many other things that aren't actually from twitter.
Personally, I spent some time trying to make sure the submitted title was more accurate and informative than the one on the post. I freely acknowledge that it's your call. I think you got this wrong.
This wasn't intended to be an editorial, it was intended to provide context. I believe that it's not clear from the title alone as you've included it here that it was Twitter. Yes, it's on the twitter blog platform, but so are many other things that aren't actually from twitter.
Personally, I spent some time trying to make sure the submitted title was more accurate and informative than the one on the post. I freely acknowledge that it's your call. I think you got this wrong.
According to https://news.ycombinator.com/from?site=blog.twitter.com it's the Twitter blog site, is it not? The quotation marks seemed to convey something else, whether you intended them to or not. But since the original title was neither misleading nor click-bait it's besides the point.
https://news.ycombinator.com/newsguidelines.html
https://news.ycombinator.com/newsguidelines.html
One can't know that without going to the site and working it out. Exactly that title on Medium, for example, would leave it completely unclear without visiting the article. So unless you know that this is Twitter's official blog - which some people (including me) wouldn't - it's useful to have the modified title. In particular you say:
... since the original title was neither misleading ...
To me the title as it stands is misleading. That's why I wanted to make it clearer. <fx: shrug />
But seriously, your call. You thought it was editorialisation, intentional or not, and you changed it. I think the existing title is less useful or informative, but it's not my final decision. I've long felt that the blind reversion of submitted titles to the title of the article is misplaced and over-zealous, but as a moderator on other platforms, I know that every decision requires work, so not actually making a decision is a huge saving in time, effort, energy, and will.
(Several edits have been made as I try to make my points clearer. Not sure I've succeeded, but I have no more time.)
... since the original title was neither misleading ...
To me the title as it stands is misleading. That's why I wanted to make it clearer. <fx: shrug />
But seriously, your call. You thought it was editorialisation, intentional or not, and you changed it. I think the existing title is less useful or informative, but it's not my final decision. I've long felt that the blind reversion of submitted titles to the title of the article is misplaced and over-zealous, but as a moderator on other platforms, I know that every decision requires work, so not actually making a decision is a huge saving in time, effort, energy, and will.
(Several edits have been made as I try to make my points clearer. Not sure I've succeeded, but I have no more time.)
Ah, I see. Appreciated! I did jump to conclusions here and I apologize.
Thank you. I'd suggest some middle ground, but it's probably too late.
The "please leave out the editorial" part makes me think it was the scare quotes, not the word Twitter, that led to the title edit.
They weren't "scare quotes" - that was the part that was directly quoted, the other was to provide the context for the exact quotation.
Perhaps I should've put:
Twitter introduces “new developer requirements to protect our platform”
To be honest, I do what I think is right, and I don't care to second-guess the mods. But I'm slowly being trained not to care at all.
Perhaps I should've put:
Twitter introduces “new developer requirements to protect our platform”
To be honest, I do what I think is right, and I don't care to second-guess the mods. But I'm slowly being trained not to care at all.