Hacker News Reader

Comment by saurik | Hacker News Reader

I continue to be shocked that Twitter convinced an entire generation of software developers that you need to obtain something called an "API key"--which can somehow be refused or even revoked once granted--in order to write a client for their protocol. "Back in my day", we just reverse engineered the official client and used whatever algorithm it used to talk to the server and called the war won :/.

View on HN

It should be illegal for companies like Twitter to forbid this. Users should be free to access their data, and free to use any tool to do so. The revered network effect is anti consumer and it must be broken.

This is the one regulation that could save a nation from FB, Twitter, Instagram and their ilk. Any politician to run on this could shoot somebody in the middle of a crowded street without losing my support.

> Any politician to run on this could shoot somebody in the middle of a crowded street without losing my support.

That might be a bit overdone, but I get your point.

It's a reference to a statement the current president made during his campaign.

I'd say it entirely depends on who they're shooting.

Its an (in)famous Trump line.

The one regulation that could save a nation from FB, Twitter and Instagram is to ban advertising. All of it. Ban all advertising anywhere for any reason.

You may not advertise this proposed regulation.

I dunno about that.. controlling access to your server is much more important today because tech is ubiquitous, and a big target for bad actors. In the old days very few people would know enough and care enough to reverse engineer your protocol.. when a service has billions of users and valuable data, that changes.

If Twitter did not have an API key, they would spend 2x the money on absorbing & defending against DDoSes and security vulnerabilities. That cost would get passed on to us with frequent outages and many more ads in our feeds. Or a leak of someones DMs.

> If Twitter did not have an API key, they would spend 2x the money on absorbing & defending against DDoSes and security vulnerabilities. That cost would get passed on to us with frequent outages and many more ads in our feeds. Or a leak of someones DMs.

This is complete nonsense. Attackers aren't going to follow your TOS, so what possible benefit could asking your users to do it on little more than the honor system provide?

Stopping a DOS is easier if you can tie whatever expensive operations that are happening to a single user.

Except you can't actually figure out which user it is.

API key != TOS

The TOS is the reason that people use API keys instead of just reverse engineering the protocol (which is what an attacker will do).

No, CSFR tokens, validating API keys, restricting the origin of request, etc is how to restrict access to the API. TOS is only text to keep the honest honest, the security layer is to keep the attackers and others without access out. A TOS is the web-site telling how it want you to behave, and all it can do if you don't behave that way is to do its best to not let you in. Nothing of this stops you from trying to reverse engineer the protocol.

The best part with using an API is that, at least in theory, it is stable and will not have changes that breaks your integration with it

Is this system of "API keys" why Pidgin doesn't handle all these new IM protocols, and why there's no other good old-fashioned multi-protocol clients for them (that I'm aware of)?

Because reverse engineering some IM protocols is far from trivial. Skype, in particular, is a nightmare of obfuscation, as I understand (second hand knowledge from having wanted to replace it with Pidgin in the past, I haven't tried reverse engineering it myself).

Skype I know is infamously hard, but I'm wondering about the more general case -- are the problems there similar to the problems with Skype, or are they due to something else?

As far as I know, they're a combination of it being hard work and there just not being enough of a qualified developer community around Pidgin etc. to put in the effort required. I think people generally underestimate the sheer amount of work involved in reverse engineering an IM protocol, even one that's not particularly well obfuscated.

But what about other projects? Back in the day there were multiple multi-protocol clients. Pidgin (or rather Gaim back then), Trillian, and others; now there's... maybe Franz, as cosmie mentions? Simply saying "Pidgin kind of died off" doesn't seem like enough of an explanation here; why aren't there more such projects popping up?

They never worked properly. It takes years to develop and it's broken anytime the owner will change anything in their implementation.

Even if you had the ultimate multi chat clients, noone cares about it. People use the official client that works just fine.

And you've hit the nail on the head: there's just a lot less _demand_ for multi-protocol clients these days. Official clients are much better than they were in the 1990s. Like piracy: undesired use of a protocol is a service problem, one that modern IM clients are actually addressing.

Back in the day when protocols ran over HTTP it was also a lot easier for amateurs to pick up wireshark.

But if we know that the company is going to respond by changing the protocol. Then who wants to spend time reverse engineering it?

That hardly seems like much of an explanation. Look at the old protocols Pidgin and other clients of the time (e.g. Trillian) spoke -- AOL, MSN, Yahoo... those didn't run over HTTP. More importantly, the companies did respond by changing the protocols; the client-writers kept up all the same. So that's not something that's different between then and now.

Franz[1] is the closest thing I’ve found to a client around newer IM protocols.

[1] https://meetfranz.com/

Includes a Monero miner.

Interesting. I hadn't realized that before. In the Windows version, there's no reference to it anywhere. And I no longer have a Mac to check that out (although it did trigger the dedicated GPU in the MBP, I attributed that to the FB Messenger plugin).

In looking for references to the miner, people seem to mention Rambox[1] as an alternative. I can't say much about that as I just came across it, but it looks promising as well.

[1] http://rambox.pro/

Huh, interesting. Its website isn't very informative though. I can't find a list of protocols, annoyingly.

It has a plugin architecture. Most of the core services it supports are listed in the Franz Plugin repo[1]. Note that it's not just about IM protocols, but rather a one-stop messaging app in general (so supports things like Gmail). And there are quite a few third-party plugins floating around, as well. And a good number that haven't been ported from Franz 4 to Franz 5.

[1] https://github.com/meetfranz/plugins#example-recipes

Huh? Based on the code, it looks like this thing just embeds stock web clients in some kind of webview and uses a little bit of JS injection to extract message counts. It's nowhere close to actually reverse engineering any protocol.

Right. I've definitely noticed a certain technical meekness lately, and honestly, I'm worried that it's connected to the broader cultural trend toward deference to authorities. Break some rules!

In the past you could break rules on the internet and people would treat it as a joke or cool implementation of a technique at best and annoyance at worst. Now if you break those rules the system breaks you.

It's not meekness so much as the economics have changed and breaking rules isn't worth it for as many people anymore

I write bots for various purposes all the time. For the exact reasons you mention, I rarely bother even looking at APIs anymore and go straight to mimicking HTTP headers from a web browser for the functions I need.

It's still common to reverse engineer clients. Unless you're planning to build a legit business and can't have the liability, there is no reason to not use private APIs.

It’s quite lame. Think about how there aren’t even Facebook 3rd party clients and they actively block any scraping. Google also isn’t developer friendly for using the stuff they don’t want you to. Few APIs to their sites.

These companies are pretty different than the old school put up an api.

If DNS was designed by Facebook or google it would make a dedicated client and refuse some people who used too much.

It seems the war of protocol vs systems is going poorly for protocols.

Reply on news.ycombinator.com