Smiley Profile Image Set

I wish I could use a set of profile images instead of just one and have appropriate one displayed based on text content so that if I put a smiley like ๐Ÿ™‚ or ๐Ÿ˜‰ in the text, photo of me smiling or winking will show.

It doesn’t have to be a face, it could be topic/category images. And I don’t see why tweet-specific images couldn’t be displayed since Twitter already sends out image URL with each tweet (inside ‘user’).

On Twitter’s OAuth Fix

While the OAuth team is working on addressing the OAuth session fixation vulnerability at the spec level, Twitter made following changes to reduce the exposure window:

  • Shorter Request Token timeout – This is good practice in general. Developers tend to be too generous and, all too often, forget to enforce or verify enforcement.
  • Ignore oauth_callback, in favor of URL set at regration time – this prevents hackers from intercepting callback.

Double-callback is still possible though which means Twitter OAuth Consumers will have to detect extraneous callbacks and invalidate access to everyone involved because they have no way of telling who is who.

Remaining exposure to the vulnerability is when hacker’s simulated callback arrives before the user. We are talking temporal exposure of a couple of seconds at most which, given current Twitter use-cases, is not that big a deal. I wouldn’t do banking over Twitter though. ๐Ÿ˜‰

On OAuth Vulnerability

Twitter’s OAuth problem turned out to be a general problem affecting other OAuth service providers and well as consumers using ‘3-legged’ OAuth use-case. For details, you should read not only the relevant advisory but Eran Hammer-Lahav’s post Explaining the OAuth Session Fixation Attack.

First hint of the vulnerability surfaced last November as a CSRF-attack at Clickset Social Blog which was initially diagnosed as an implementation-level issue. Well, it turned out to be a design flaw requiring some changes to the protocol.

There are actually two flaws.

The first flaw is that parameters of HTTP redirects used in OAuth can be tempered with or replayed.

This flaw allows hackers to capture, replay, and mediate conversations between OAuth Consumer and Service Provider flowing over the surface of User’s browser between the User, Consumer, Service Provider.

I think the easiest general remedy for this flaw is including a hash of the HTTP redirect parameters and some shared secret like consumer secret. A more general solution like evolving tokens could be done as well but inappropriate as a quick remedy.

This flaw should not affect OAuth service providers that manage and monitor callback URLs rigorously.

The second and more serious flaw is thatย the User talking to the Consumer may *not* be the same User talking to the Service Provider.

This means that a hacker can start a session with then phish someone to authorize at Twitter to gain access to as that someone without stealing password or session-jacking.

Solving the first flaw simplifies the solution to the second flaw by reducing the possibility of the hacker intercepting callback from Service Provider to Consumer which is not supposed to have any sensitive information but some implementations might include. Wire sniffing is a concern if HTTPS is not used but the relevant concerns for the flaw are integrity and identity, not secrecy which is an application factor.

Removing the possibility of callback URL tempering leaves double callback, meaning that the hacker start things off, tricks someone into authorizing without intercepting the callback, then simulate a callback to Consumer. Note that the Consumer would have started a HTTP session with the hacker, session associated with the RequestToken in the callback. Even if HTTP session is not created until the callback is received, there is no way for the Consumer to tell who is who.

I think Service Provider have to send back a verifiable token, like a hash of the RequestToken and consumer secret so the hacker can’t simulate the callback.

Regardless of which solutions OAuth guys decide on, one thing is clear. It will take time, many weeks at least, if not months. That’s going to put quite a damper on developers in the Consumer side of the OAuth as well as the Service Provider side.

Sex and Status: Twitter and Facebook

For the past six months, I’ve been thinking about sex. Not the sweaty kind, you perv — wink wink, nudge nudge — but about perspective differences between sexes and what that means to the Web at large. I am drawn to the differences to identify new business opportunities instead of trying to save the world or make it a better place or anything but I’ll take the bonus points if it’s on the way.

Fred Wilson asked rhetorically Hasn’t It Always Been About Status? in his post about Facebook opening up their status update API more. My answer from the sex-difference perspective is: Yes, for guys, not as much for girls.

I think status updates offer two things:

  • Awareness
  • Presence


Back when we had more hair than brain, awareness had direct impact on survival, resulting in the need to be aware carved into our veins. As civilizations advanced, focus of awareness expanded from elements and beasts to include awareness of what others are doing, moving from dodging predators and bashing skulls to keeping an eye on strangers and smelling whiffs of wars in distand lands.

The twin brother of Need is Fear. Even while drowning in constant avalanche of information, modern man fears not knowing enough soon enough.


Whether it’s simply brushing shoulders or social status, men feel the need to be acknowledged and, if given a chance, respected. I don’t think it’s pride but more to do with the dog brain part of us, wolfpack mindset.

My current thinking is that men’s need for awareness and presence are far greater than women. For women, I think things like order and intimacy are more important which could mean that:

  • Twitter is more useful to men than women.
  • Facebook has more general appeal.

Right or wrong, I use this kinds of thoughts like I would a bottle-opener and would like the readers to do the same.

Twittling Away

I’ve been busy crossing the deep jungle of chores that suddenly appears whenever one attempts to launch something. I’ve also been using Twitter whole lot more, partly to test but mainly because the service I am building brings services like Twitter way too easily accessible. It’s the phenomenon I’ve been trying to confirm but, now that I have, I can see how it needs to be leveraged carefully to avoid exposing users to addictive and, potentially, career ruining behaviors.

If you are not following me on Twitter yet. You can follow me at


Yesterday, I went over to checkout Google App Engine and, because GAE made it so easy, ended up writing a little webapp I’ve been thinking about writing for a while. Besides, it’s been a while since I used Python so any excuse would have worked. Currently, it runs only on my laptop because I haven’t added security bits yet but it shouldn’t have any problem on the real thing.

Oh, shit. My MBP’s video memory seems to be on the brink. I am getting random lines on-screen now.

The app is a port/extension of part of the Twitter client functionality I had in Appily, my AIR client from more than a year ago that I shelved before starting SafePage. It scratches a usability itch that prevented me from using twitter more frequently. I wrote it to see how improving accessibility radically affects usage patterns. So far, it’s working but more time will tell.

What I found frustrating while coding for GAE are the usual constraints of sandboxing but, for languages with rich third-party library support like Python, it gets really bad because many of those libraries have to be rewritten or replaced to varying degrees. For example, I couldn’t use existing crop of Twitter client libraries so I had to code the necessary calls myself. Each such incident is no big deal but the difference between hastily handcrafted code and libraries polished over time piles up.

Anyway, it was fun. Hopefully, I’ll still be in playful mood this afternoon so I can add the missing security bits and let others play with it too. Be warned, it’ll be rough as concrete floor as I don’t have the bandwidth to apply normal furnishings over the gears. My intention is to keep churning out snack-size apps like this one until one of them gains some traction then dig-in to see if it has legs, conversing with the users all the way.

Call it, conversational entrepreneuring. ๐Ÿ˜‰

Update: Wonderful. Just in time to catch the newly arriving shortend of the stick. I can understand why Twitter is doing this. They are riding a tiger that’s moving faster and faster, trying to turn it into a golden goose without getting eaten. The problem is that it’s neither impossible nor easy. I say, Hi Ho Silver!