Category: Social Networking


Facebook’s New Niche

In the midst of Facebook’s widly-discussed UI changes this week, one new feature fell through the cracks: the Timeline (currently only in developer beta, but you can be involved by following these steps).

Timeline

This new Timeline feature solves a major UI problem that Facebook has been plagued by – the disorganization of each user’s content. The previously-separate Wall, Info, Photos, and so on have all been combined into a single, centralized profile page. But the timeline goes beyond that. In displaying your entire Facebook activity over time, it also allows you to add “life events”, from achievements to medical events to anything, really.

By now, you’ve probably realized that these features don’t just show your entire Facebook activity – they’re meant to show your entire life.

(Note: Sure, this situation is interesting in terms of privacy, but let’s just assume that people will be willing to share the events of their lives. So far, they have been pretty willing.)

The main thing going for Facebook here is how much information they have. Besides sharing information, users give Facebook a ton of personal data. They’ve finally started using this data for more than just targeted advertising; for example, the timeline has a map page that tracks your activity, intersecting place information with status updates and more.

Life-tracking might be Facebook’s niche. Google+’s focus is sharing, not identity creation. In terms of user identity, G+ certainly aims to consolidate your web activity under one profile. But Facebook doesn’t have the web – instead, they combine activity on their site (status updates, photos, places, and now app activity via Open Graph) with the life events you input. In a way, Google+ and Facebook aren’t currently competing in that realm, although Google might certainly try to follow Facebook. If anyone could do something like that best, it would be Google, specifically because of how much we rely on their services in our lives and how much information we have about ourselves on the web.

Hopefully, this timeline feature won’t be treated as just another annoying Facebook redesign. It has the potential to change the way we approach the Internet and collect our online identities. Facebook has been making dumb moves lately – but this might be their killer app.

I’m tired of all the Twitter API applications that force users to enter their Twitter usernames and passwords to log in. Why? Well, because it’s just so insecure!

Many people realized this for web applications some time ago, so now, most Twitter web services use OAuth to connect with the Twitter API. But for some reason, this hasn’t been done with desktop apps: most of them haven’t embraced OAuth.

Of course, there may be less of a security risk of providing your username and password with desktop applications, as one might think that there’s less of an opportunity for the provider of the Twitter app to capture and keep the username and password.

Yet, there’s still a huge risk of packet sniffing!

As an example, I opened Seesmic for Windows and started Fiddler2 to capture my traffic. Here’s what I found:

GET https://api.twitter.com/1/account/verify_credentials.json HTTP/1.1
X-Twitter-Client: Seesmic
X-Twitter-URL: http://www.seesmic.com
Authorization: Basic [REDACTED]
User-Agent: Seesmic
Host: api.twitter.com
Connection: Keep-Alive
That’s the request itself. Guess what happens if you decode that authorization token?
Authorization Header is present: Basic [REDACTED]
Decoded Username:Password= maximz2005:[REDACTED]

Oh look, it’s my username and password! Well, I hid the password here so that no one takes it… :)

Yet, there’s nothing to laugh or smile about here. Traffic from desktop Twitter apps that request a username and password is out in the open.

This all shows one major point: we must embrace OAuth. The OAuth system uses application tokens: in this case, Twitter creates a token for the application, the application connects using the token, and, if the user, at any point, wants to remove the application from his account, the user can just revoke the token, effectively revoking access for the application.

Twitter realized that this system would greatly increase security. Now, they’re phasing out the HTTP Basic Authentication (username & password) connection to their API, with a cut-off date of June 2010.

If you’re a desktop Twitter app developer: do you want your users to be out in the open? Do you want them to feel and be insecure? It’s not a great idea, though many apps are still doing this. Please, use OAuth, for your own benefit, and for that of your users, too!

Update 05/30/2010: The Twitter API Team has now instated a cut-off date for HTTP Basic Authentication connections. By June 30, 2010, a month away, all applications that utilize the Twitter API must switch to OAuth. Thankfully, OAuth isn’t a hard thing to implement, so we can expect a lot of our favorite apps to switch before time runs out. See http://countdowntooauth.com/ for more information.

The anti-trust community is all over Google, these days, says an article in the August 2009 issue of Wired Magazine. Fred Vogelstein tells readers that the search giant is the new Microsoft – remember that huge antitrust lawsuit against Microsoft for packaging their browser with Windows? Now they’re interested in the advertising and business ideas of Google, as Google has a huge market share in the advertising and search market, which gives them an enormous amount of data about users. After all, why do they give their excellent software away for free? This is because the more users that their applications have, the more data they have about them, about their interests, their personal identity, and much much more. Effectively, many companies have access to such huge amounts of personal info – take Facebook for example, which acquired FriendFeed yesterday. They can (and do, for all I know) use all the data that users submit about their interests, identity, preferences, and more, to target advertisements, to circumvent identities (in malicious situations), to sell the data to marketing agencies, and more. Or look at Twitter. Look at how much detail Twitter has, even though mostly all of it is accessible by anyone (except of course for preferences, Direct Messages, and protected updates). I rather like Twitter, but what if they (or someone else, possibly someone who scrapes personal info off of their site) use it to create a whole “profile” of a person’s characteristics, personality, hobbies, interests, and whatnot? I know that Twitter won’t do this, but some other company in such a situation might. Like Apple.

Apple is the one the antitrust community should be gunning for. Look at how they are monopolizing.A classic example is the iPhone, exclusive to AT&T. Why is this, you might ask? This way, they can pull even more money out of the pocket’s of their users. Also, what is the whole point of all the restrictions inside the iPhone OS? Why can’t Apple be open, like Google with Android, open-sourced and partially developed by the community from the start? The Macintosh, Apple’s key product, is also an example of this. Mac OS X is only compatible with Apple hardware, not anything else, so that everything has to be through Apple, hardware and software, meaning more money for Apple, as well as an unnecessary monopoly, while Windows is completely open to all suitable hardware, because Microsoft isn’t a hardware manufacturer and knows not to lock people in, though they did that with IE some time ago (and possibly even again now). Apple even makes it hard for you to change the battery in a laptop!!! They want you to stop from using devices from others that compete with them!

And yet we agree to such a tradeoff. We still give all our information to Apple, ranging from our music purchases in iTunes (musical preferences and interests), files in MobileMe, email, pictures, computer preferences, and so much more. But they are crossing the line – why don’t they understand that doing so is dangerous? However, no one seems to care that Apple is being so monopolizing to users, even though in some of its main conquests it has a small market share. Look, this will end bad for you, Apple, so make the situation better for users NOW and save yourselves of the future consequences of not doing so. Otherwise, what is the commercial world coming to?

In my last post, I explained what truly went on in the Twitpocalypse, which dealt with tweet IDs passing the limits of the 32-bit signed integer (from -2,147,483,647 to +2,147,483,647), which is the most common datatype in use in computer applications today. Yet, whilst computer science has limits embedded into its structure, Twitter does not – the number of users and tweets is growing, and FAST! In September, the Twitter API team estimates, we will pass the limits of the 32-bit unsigned integer which is up to 4,294,967,295. Thus, applications and libraries that utilise that datatype in conjunction with tweet identification numbers in the Twitter API will fail, once again. In the post where I explained the first Twitpocalypse, I recommended that all applications switch to the 64-bit signed (or unsigned even) datatype, and then maybe even consider storing the IDs as strings, with variable length (no arithmetic between IDs is really needed, so this should be extremely easy). The Twitter API team is doing the same thing – it has now informed developers that it is best to switch to a 64-bit implementation for storing those integers. Hopefully, this time, we will be prepared for the upcoming Twitpocalypse, and even less confusion and problems will arise when we pass that huge number of tweets. I myself am switching to a string implementation for the IDs in the Twitter client that I am developing (more info coming soon!), so that no matter how many tweets have been posted, the application will not fail. Good luck, everyone, in surviving this next round of this problem. [@twitterapi 's tweet; Twitter API Announcements (via TechCrunch)]

Numerous friends have asked me about this whole Twitpocalypse thing, as they just don’t get it. “What’s this whole deal with signed integers?”, they ask. Well I’m here to clear that up, as I do programming, and in programming, if you don’t know such basics of computer science, you’re doomed.

What the predicters of the Twitpocalypse were referring to when they mentioned the limit of 2,147,483,647, is the limits of the signed integer data type. The signed integer is a 32-bit data type, so it can hold only so large (or so small) a number – in this case, the highest number the data type can preserve in 32-bits is 2,147,483,647, and the lowest number is -2,147,483,647, respectively. This is what causes the Twitpocalypse problem, as well as the foreseen Unix Year2038 problem (where Unix epoch time will cross the limit, and distros using the 32-bit data type will fail.)

Each tweet in the Twitter infrastructure has its own numeric ID. Thus, programs that invoke the Twitter API’s ID interface into a 32-bit variable fail, as the number of tweets has passed the limit. When this happened, some applications failed, others continued working, depending on their implementation of this feature. Of course, updates were quickly rushed to the failing products, so that users wouldn’t be discouraged or affected for too long. Most applications now use the 64-bit integer datatype (commonly referred to as long or int64) for the ID variable, which supports numbers from −9,223,372,036,854,775,808 to +9,223,372,036,854,775,807 – in other words, pretty large. Until then, we’re safe, but if we manage to cross that 9 quintillion mark (well, it’s certainly possible! :) ), we may be forced to convert to the 128-bit integer time, or even storing numbers as strings (the datatype for any types of characters, mostly letters), but I think computing will have changed a bunch by then, so that we might not even think of such a problem. That is, if Twitter lasts till then, or maybe the world will have been sucked into a black hole. We’ll see.

(On a side note, last year, I created a VeryLargeInt class for storing huge numbers (100 digits long can be stored with this, or even more!) by using the string data-type, and I also built algorithms for computation with strings, including most common mathematical operators. I may publish this project here in the future.)

Copyright © 2010 Maxim Zaslavsky. All Rights Reserved.

Videos, Slideshows and Podcasts by Cincopa Wordpress Plugin