Earlier this year I blogged about that fact that all the hype around Facebook had triggered my curiosity, and I was spending some of my spare time tinkering with the new Facebook platform. Rather than build the typical 'Hello World' application, I wanted to create an application which actually had some more practical use so I asked around to find out what people were looking for.
Applications CANNOT track profile views for users who simply visit another person's Profile. Facebook has made this technically impossible.
The reason why it is technically impossible is because Facebook has included restrictions into their platform which prevent references to external resources. The way Facebook deals with this scenario is by performing specialized processing on external references in Profile pages. Take for example an image which is being hosted on an external site. Facebook will pull the image onto its own servers, generate a unique filename, and modify the SRC= attribute to point to the local image rather than the remote image. This effectively prevents third parties from tracking visitors.
So I gave up on that idea for the time being and moved onto a different application. However in the process of building the new application I accidentally stumbled upon a vulnerability which allowed me to circumvent the restriction I just outlined above.
To test out my theory, I went back to my original application and successfully created a Hit Counter on my Profile page – a feat which is supposed to be “technically impossible”.
So how was I able to do this?
The HTML specification has support for TABLE elements and specifically table columns ( TD ). Table columns have a number of custom attributes and one of the more obscure attributes is the BACKGROUND= attribute. This attribute allows you to specify a URL to a resource. So what my application did was inject a very simple HTML table with a BACKGROUND= attribute into a users Profile.
Apparently the Profile script parser was not smart enough to recognize the BACKGROUND= attribute, so it left it intact. This allowed me from my remote server to capture details about the request including the persons IP address, querystring, etc… And leveraging the ID parameter, I was able to track the number of hits to a users profile and dynamically generate and serve an image containing the number of hits. In addition, by cross referencing IP Addresses and IDs, the application could keep track of who was visiting whom, how often, and when. Using the IP address and geocoding, it could even figure out where the user was currently located.
I named the application 'Top Visitors', added the application to the Facebook directory, and within a week it had grown to 5,000 users. Within two weeks it had doubled to 10,000 users. It appeared there was definitely demand for the application so I added some more advanced features which provided more privacy. Basically a user could choose to be visible to some of their friends and invisible to others.
However, as the creator of DotNetNuke, a pervasive platform in its own right, my own conscience began to get the best of me. To preempt the embarrassment of getting branded a malicious 'hacker' I reached out to Facebook in May 2008 and was lucky enough to get into contact with Facebook Vice President of User Growth, Mobile and International Expansion, Chamath Palihapitiya. I explained the vulnerability to him and recommended a modification to their Profile parser. To their credit, Facebook moved very quickly to patch their site, eliminating the vulnerability within days with no side effects or public consequences. I was highly impressed with the professionalism of their executive management and how serious they are in regards to user privacy.
The patch effectively busted my application, so the next barrage of complaints I received were from the thousands of Facebook users who were big fans of the Top Visitors application and were wondering why it was suddenly broken. I posted a note in the application directory listing indicating that a change to the underlying Facebook platform was responsible for the problem and that there was no known solution. Many people did not read this message and to this day I still get complaints from users who want to add the application to their profile ( I should probably remove the applicaton from the Facebook directory ).
The one thing I find most perplexing about the whole thing is the fact that Facebook has not yet added such a feature to their platform. Since their business model is based on advertising, the number of "sticky" features in their platform are directly related to the amount of revenue they can generate. And I know for a fact that the Top Visitors application was extremely sticky - users would constantly refresh the page to see who had visited their Profile. And since no third party developer can create a feature such as this due to the technical restrictions, there would be no complaints of Facebook competing with its own platform developers. As far as privacy is concerned, Facebook could leave the feature disabled by default and allow users to enable it at their own discretion through their privacy settings. And including the Visibility capabilities similar to those I included in Top Visitors would provide users with ultimate control. Anyways, I have no idea how Facebook integrates feature requests with its roadmap, so we shall have to wait and see if something like this ever materializes...