Pages

Showing posts with label answer. Show all posts
Showing posts with label answer. Show all posts

Oct 18, 2012

Reverse-Engineering Twitter To Solve An Advertising Mystery

Does Twitter have an undocumented API for promoted Tweets? Dwolla developer Michael Schonfeld tore apart the app to find the answer.

Recently I opened the Twitter app on my Mac and noticed something very strange: It was omitting promoted tweets from my timeline. In the side-by-side comparisons below, notice the "howaboutwe.com" promoted tweet from Twitter.com on the right is missing from the Twitter.app feed on the left.

An example of Twitter breaking its own rules, or just a bug?

Then I found a missing promoted "Pepsi" tweet on Twitter.com which was absent from the feed on my iPhone Twitter app. There was definitely something going on here. Why would Twitter differentiate content between their official mobile app and their web client?

Back in September 2010, Twitter said that it was using its own API. "It fetches data from the same endpoints that the mobile site, our apps for iPhone, iPad, Android, and every third-party application use," wrote Britt Selvitelle in a post on the engineering blog. That appears to no longer be the case, which raises an even more hairy question: Does Twitter have an undocumented API for promoted tweets? To find out, I did what every curious engineer would and decompiled the app. (Twitter, if you're reading this, please don't ban me from your network.)

Reverse Engineering Twitter.app

My first idea was to set up a local proxy and examine if the Twitter.app was filtering out promoted tweets, or whether it was receiving them at all. Setting up a proxy proved not to be as easy as I had hoped. Twitter.app uses SSL encryption to communicate with the API server and because it's set to reject self-signed certificates, trying to spoof an SSL certificate renders the app completely non-functional.

For help, I enlisted my brother Daniel Schonfeld, a seasoned hacker for help disassembling Twitter.app. Fortunately for us, the app was written almost entirely in Objective C, which meant that we'd be able to examine some of the app's source code as it was written by Twitter's very own engineers; usually, when disassembling C/C++ binaries, source code loses its original naming symbology, but Objective-C preserves a lot of symbols which makes it easier to follow along.

Using a nifty tool called class-dump, we began examining the contents of Twitter.app and how it was designed. First, we set out to see if we could find any mentions or references to promoted tweets. It wasn't too long before we found this little gem buried within the code definition of the "Twitter Status" object. Notice the built-in flag for promoted tweets:

@interface TwitterStatus : NSObject <...>
{
NSDate *lastUpdated;
...
struct {
...
unsigned int isPromoted:1;

From this finding, we could assume that Twitter.app does in fact at times receives promoted tweets from the API server and classifies them as such using the "isPromoted" flag.

On to the Data Stream
Once we knew that Twitter.app has some built-in handling for promoted tweets, we had to dig deeper. Daniel fired up Hopper.app, a Mac disassembler, and a couple hours later, boom: He had found the code routine that handles network responses. Namely, the [ABHTTPRequest connection:DidReceiveResponse:] message (method). Now could finally answer our initial question: Does the app receive promoted tweets from the API server or not?



We used GDB to set up breakpoints in Twitter.app and forced it to show us what it was getting back from the API server. Specifically, our debugger will halt every time the app receives a network response.

To repeat our method, fire up a terminal window and launch the debugger:

> cd /Applications/Twitter.app/Contents/MacOS/
> gdb --arch=i386




Then, while working within gdb, type:

> (gdb) exec-file Twitter
> (gdb) b *0x6dec3
> (gdb) commands
> x/s $eax
> end
> (gdb) set print elements 0
> (gdb) r

This will cause the debugger to freeze Twitter.app on our given breakpoints. The first thing you'll notice is that Twitter.app is actually working with Twitter's XML format--yuck. The first couple API server responses will be your own account's information. Type **c**, then hit the **Enter** key to continue to the next breakpoint. The next block of XML you'll receive is your timeline feed. Comparing the XML to my Twitter.app feed and my Twitter.com feed, we discovered that Twitter.app is not actually not receiving the promoted tweets in the data feed from the API server at all.



Is This an Undocumented API?
Just one question remained: Were only Twitter's official apps not receiving promoted tweets from the API server? Or, does the API not return them to any client at all?

This was a rather easy test. Using Rested for Mac, I quickly polled Twitter's API server for my own timeline feed. As can be seen in the resulting output above (truncated for your convenience), it appears that the API server simply does not return any promoted tweets.



Conclusion: Twitter Has A Secret Feed For Promoted Tweets
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. That's obviously not the case.

The mobile ad market is an enormous and constantly growing one. Ad revenue is a major component of Twitter's revenue, and the company projects it to grow to $540 million by 2014. Twitter has also promised to "share a portion of advertising revenue" with developers who serve Twitter ads, according to its own Developer Rules of the Road.

Advertisers and developers, it's getting close to 10 p.m.: Do you know where your promoted tweets are?

Michael Schonfeld is head of developer relations at Dwolla, a service that empowers anyone with an Internet connection to send money simply. Follow Michael Schonfeld and his brother Daniel Schonfeld on Twitter.


Source : fastcompany[dot]com

Aug 29, 2012

Can You Move Your Intranet to the Cloud ?

A recent set of experiences at work has led me to ponder the question: can you move your intranet to the cloud?

The answer it would appear is that often given by consultants: "yes, but it depends!"  

So what does it depend on? Well, let's investigate some of the variables.

What and Why ?

The first thing to consider is what is your definition of "cloud"? I am not going to be purist about this. Whether it's a "true" multi-tenant public cloud, hosted managed services or even a corporate private cloud, what I am really looking for here is removing the technology stack from my data center / LAN and thus potentially supporting the stack, and even developing for it using staff who aren't on my organization's core payroll.

Cloud Computing_Cawthorne_August.jpg      
This diagram is courtesy of Sam Johnston via Wikipedia (Creative Commons Attribution-Share Alike V3.0)

I will be a little more proscriptive in defining the technology stack. In essence, what I am looking for is a Web CMS for the core information publishing function on an intranet. Whether you prefer the term Digital Workplace, Intranet Ecosystem or some other label, when it comes down to it there are many cloud based solutions for content centric collaboration or social collaboration.

However, apparently there are far fewer alternatives for that good old fashioned core intranet use case of content publishing, or portal development and not every organization is culturally mature enough yet to move to a social platform (e.g. Jive) as their intranet solution.

Organizational Size

Oh yes, size does indeed appear to count! There are some excellent cloud-based or hosted intranet solutions that unfortunately just do scale to 5,000 users. For example ThoughtFarmer is an excellent "social intranet" platform which can run on site or in the cloud, but either way, the ThoughtFarmer team doesn't recommend it for more than 5,000 users.

There are other alternatives, which may serve you in the Small to Medium Enterprise space, with many “intranet in a box” offerings moving to a cloud model, and even heavy duty intranet focused CMS platforms like Ektron are doing interesting things which can include hybrid models via their Cloud Manager product.

Organizational Readiness

So how mature is your organizational culture with respect to moving data into the cloud in general? Do you have standards in place? Or do your Info Sec and Enterprise Architecture colleagues have apoplexy when you mention moving content off your network and outside of your trusty firewall?

This is potentially where the variations of public versus private cloud, versus managed hosting services etc. come into play. Risk assessment is of course the broadly scoped answer to this conundrum, for which there are many corporate or public methodologies which are beyond the scope of this article.

Potential Paths to Investigate

If you're a SharePoint house for portal, WCM and other Intranet functionality, then you can investigate their cloud offering under the Office 365 brand. There will of course be plenty of potential partners to advise you on advantages and warn you of pitfalls, but I am no Office 365 expert, and I don't like SharePoint as a Web CMS !

 

Continue reading this article:

 
 

Source : cmswire[dot]com