Reverse-Engineering Twitter To Solve An Advertising Mystery | Hacker News Reader

Reverse-Engineering Twitter To Solve An Advertising Mystery

fastcompany.com

58 pointsbenjlang15 comments

> The FAQ on Twitter's dev site says that, "As of March 12, 2012 there is no Advertising API for serving Twitter's promoted products in third party applications." Which means the promoted tweets ought to appear in any timeline that uses the API.

I don't see how the conclusion that tweets ought to appear in any timeline that uses the API follows. That they don't have an API for third-party applications doesn't mean they don't have one for their own applications. In fact, I'd say that it implies the existence of an internal API for serving promoted tweets. The FAQ seems to be accurate, and not at all misleading from where I'm standing. I don't really see how this is an advertising mystery.

That said, the process of investigating the matter was very interesting.

In this article he is reverse-engineering official Twitter apps. So there is an inconsistency even within Twitter's use of its own APIs. That, to me, is the mystery.

Also, I don't see how that statement implies the existence of something that no one has ever said existed. If the government says there are no aliens at Area 51 does that imply aliens do in fact exist at some other secret location? Uh-oh, maybe that was a bad example!

The statement was that there is no API for promoted tweets for third-party apps. If Twitter has promoted tweets, they have to get them from somewhere. That implies that there is an internal API where they get promoted tweets. I think I may be missing the point of the article, because it really didn't make much sense to me.

The answer for this is pretty simple -- you want promoted tweets to show as promoted, and old clients don't support that type of rendering.

There are hundreds of twitter clients out there, many of them written once and updated sparingly. These clients and apps aren't checking for the "isPromoted" field when they get a JSON blob back from the server -- they just dump the text / author / profile pic into whatever rendering engine they have. So a promoted tweet shows up identical to a read tweet.

Even worse, I doubt the developers are going to waste their time adding support for promoted tweets if they don't get a cut of the ad revenue.

And lastly, Twitter also needs to accurately count impressions on promoted tweets. on the web they can do this with some degree of accuracy -- on clients, it's trivial to filter by the isPromoted field, resulting in delivered tweets that aren't displayed and angry advertisers.

This is simply a case of an out-of-date reference blog post (that 2010 #newtwitter article). Quick observation of Twitter.com today will reveal that it's no longer using the public API (at least from the client). It's fetching the Tweets from the server pre-rendered (via http://twitter.com/i/timeline). So nothing to see there. Maybe taking a closer look at Twitter for iOS, which does receive promoted Tweets, would provide more information.

Well, the real point of what I was trying to say in the article was that Twitter had publicly stated that they're moving to an API oriented architecture - meaning that the web client is merely just another API client. That, coupled with the non-conforming-UX API key revoking acts recently, made me question the legitimacy of their statements...

I don't understand why it matters whether the web client uses a public api? And anyway it's totally reasonable for tge server to access an internal api and prerender the result.

What's the legality with disassembling closed source apps whose code which uses a VM, effectively giving the source code? (Is ObjC similar to how C# uses .NET? ILSpy can print pretty clean output)

No, ObjC is very close to standard C. The [ ] message syntax compiles to calls to the objc_msgSend function.

I think @skeletonjelly's point is that the reverse engineering of ObjC reveals much of the original unobfuscated source coude, thus giving away proprietary data?

Correct. ObjC sits somewhere between C and Java in ease of decompilation. Logic and arithmetic code is compiled just like C but all of the object-oriented options are readily exposed. Message passing is used, letting you hook into every part of the program and find the original class, method, and field names and all operations on them. ObjC is very dynamic and introspective which makes reversing it much easier.

The answer I was after, thanks! I should do some digging into the internals of these things.

You know, I carefully read Twitter TOS before writing this article, and there is absolutely no mention prohibiting the reverse engineering, or decompilation of their software.

Unlike others, Spotify for example, who explicitly prohibit such actions in their TOS...

I don't believe I did anything illegal here...

Fair enough then! I've been curious about this pulling apart programs to see how they work, following TOS of course. Don't want to breach anything personally.

The EFF has detailed information about this:

https://www.eff.org/issues/coders/reverse-engineering-faq

Reply on news.ycombinator.com