Hacker News Reader

Comment by saurik | Hacker News Reader

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

View on HN

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.

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

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'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.

> some of the best software I have ever used

That's some hefty praise, do you mind explaining why it's so great?

You give it a URL and it downloads the video on that page.

It's better when compared to ad/malware laden webpages that people unaware of youtube-dl use.

Keepvid was always perfectly usable while it was still going.

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.

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.

You can see tweets without logging in. People do it all the time, and websites do it even more.

Follow the thread back to its root to see that that's not what we're talking about here.

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

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.

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.

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

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.

"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.

Reply on news.ycombinator.com