I’ve got a few short takes today, to try to assuage my guilt for being a bit swamped these days (and also to get rid of a few of these tabs in my browser).

Remember the lawsuit Verizon filed against Vonage, threatening to bankrupt the upstart VOIP provider over technology the Baby Bell claimed was its own? It looks like Vonage might have finally rolled out workarounds to all the disputed tech, and also posted better-than-expected financials — which makes me pretty excited, being that I’ve been nothing but satisfied with our service from the company.

I’ve been slowly working my way through Jane Mayer’s amazing New Yorker piece on the CIA “black sites”, and it’s pretty clear that this is a must-read article for those who wish to learn how far our government has taken its torture of detainees in the all-important war on terror. The worst part of it is that at this point, there’s no question that what the public knows only scratches the surface, and that when tomorrow’s historians uncover the full details of this administration’s assaults on fundamental American liberties, we’ll either be aghast or will have long ago given up the right to express our outrage. (Let’s hope for the former.)

It’s amazing, but Apple really does look to be violating the script.aculo.us license on every single page that’s generated by the .Mac photo gallery. Either that, or they’ve struck some licensing agreement with the tool’s author, Thomas Fuchs — but seeing as how script.aculo.us is released under the extremely permissive MIT license, that’d seem unlikely for Apple to have done.

Cool — I hadn’t put two and two together, but Movable Type 4.0 is using Codepress to provide inline syntax highlighting in its template editors, and has extended the tool so that it recognizes all the Movable Type template tags. A long time ago, I bookmarked Codepress so that I’d remember to come back and take a look at it… looks like I don’t have to do that anymore. :)

Finally, this page might be dangerous for me. That is all.

It’s amazing to me that CNN.com is being redesigned and still defaults the search engine to perform a general web search rather than a search of CNN’s own news content. (The current CNN site has been this way since the beginning of 2003.) Are the folks at CNN’s interactive bureau really under the impression that there are people who go to their site in order to search the web? Do they think that nobody wants to search their own content? It’s just weird.

Well, MSNBC has now joined the esteemed group of websites with home pages that play audio and video on page load, without any user intervention, one of the more user-hostile things I can imagine a site doing. When added to the awful embedded IntelliTXT ads that are now appearing throughout most MSNBC.com news stories, it seems that the entire site took a major turn to brazen suckery sometime over the past few weeks. That actually makes me sad — I used to use CNN’s website as my default for news but moved to MSNBC when CNN decided on providing most of the news on the website via video snippets that can’t be played on non-PCs. The video-without-my-requesting-it problem was enough to get me to stop using ESPN’s website for all but a scant few things; now it looks like I’ll have to find a replacement for MSNBC, as well.

While I like his redesign, I gotta admit that I’m a little disappointed Anil didn’t go with the obvious for his in-post screenshot.

Anil's redesign

I mean, why be satisfied with just two headshots on the same page? ;)

For the true geeks among you, you can now scroll through comments and posts on this site by using keyboard shortcuts — pressing ‘.’ (the period key) scrolls forward, and pressing ‘,’ (the comma key) scrolls backward. Thanks to Sam Ruby for inspiring me (and for the Javascript that I used as the basis for my resultant scripts), and to MetaFilter for being a good testing sandbox.

(For those who are interested, the choice in keys comes from reBlog, the web-based syndication aggregator I use. I’ve gotten so used to scrolling between posts with the period and comma keys that I started to unconsciously use them on other sites; that’s when I knew that I should look into how to set up the shortcuts here at home. Convincing Matt to give ‘em a whirl over at MetaFilter wasn’t too hard… seeing as he was the one that turned me onto reBlog!)

Just a quick public note to Dan Cederholm (the man behind SimpleBits), his wife Kerry, and his three-month-old Jack to say glad everything went well! Jack just underwent surgery at the fabulous Children’s Hospital Boston to correct two congenital heart defects, and is recovering quickly enough to be out of the intensive care unit. Go Jack!

During my pediatrics residency, I built a pretty sizable content management system to host educational and curricular material for my department, a system that’s remained in operation for quite a while now. Over the past few months, though, two senior pediatricians (and regular content contributors) let me know that they were unable to log into the system from home; from their descriptions, they were presented with the login form, entered their information and submitted it, and were immediately returned to the same form without any errors. On its face, it made no sense to me, and made even less sense given the fact that there are a hundred or more regular users who weren’t having any problems logging in. The fact that two people were having the same problem, though, made it clear that something was breaking, so I started taking everything apart to see where the problem was rooted. (This was of particular interest to me, since I use the same authentication scheme in a few other web apps of mine, some of which contain patients’ protected health information.)

Looking at the mechanism I had built, the system takes four pieces of information — the username, password, client IP address, and date and time of last site access — and combines them into a series of cookies sent back to the user’s browser in the following manner:

  • the username is put in its own cookie;
  • the username, password, and client IP address are combined and put through a one-way hash function to create an authentication token, a token that’s put into a second cookie;
  • finally, the date and time of the last site access is put into a third cookie.

To me, all four pieces of information represent the minimum set needed for reasonable site security. The username and password are obvious, since without them, anyone could gain access to the site. The client IP address is also important for web-based applications; it’s the insurance that prevents people from being able to use packet sniffers, grab someone else’s cookie as it crosses the network, and then use it to authenticate themselves without even having to know the password (a type of playback attack known as session hijacking). (This isn’t perfect, given the widespread use of networks hidden behind Network Address Translation as well as the feasibility of source IP address spoofing, but it’s a pretty high bar to set.) And finally, incorporating the date and time of a user’s last access allows me to implement a site timeout, preventing someone from scavenging a user’s old cookies and using them to access the site at a later time.

Looking at that system, I struggled to find the bit that might be preventing these two users from being able to log in at home. I already had a check to see if the user’s browser allowed cookies, so I knew that couldn’t be the problem. These same two users were able to log into the site using browsers at the hospital, so I knew that there wasn’t some issue with their user database entries. That left me with a bunch of weird ideas (like that their home browsers were performing odd text transformation between when they typed their login information and when the browser submitted it to the server, or that their browsers were somehow modifying the client IP address that was being seen by my application). None of that made any sense to me, until I got a late-night email from one of the two affected users containing an interesting data point. He related that he was continuing to have problems, and then was able to log in successfully by switching from AOL’s built-in web browser to Internet Explorer. (He has a broadband connection, and mentioned that his normal way of surfing the web is to log onto his AOL-over-broadband account and using the built-in AOL browser.) When the other affected user verified the same behavior for me, I was able to figure out what was going on.

It turns out that when someone surfs the web using the browser built into AOL’s desktop software, their requests don’t go directly from their desktop to the web servers. Instead, AOL has a series of proxy machines that sit on their network, and most client requests go through these machines. (This means that the web browser sends its request to a proxy server, which then requests the information from the distant web server, receives it back, and finally passes it on to the client.) The maddening thing is that during a single web surfing session, the traffic from a single client might go through dozens of different proxy servers, and this means that to one web server, that single client might appear to be coming from dozens of different IP addresses. And remembering that the client IP address is a static part of my authentication token, the changing IP address makes every token invalid, so the user is logged out of their session and returned to the login page.

Thinking about this, it hit me that there are precious few ways that an authentication scheme could play well with AOL’s method of providing web access. For example:

  • The scheme could just do away with a reliance on the client’s IP address; this, though, would mean that the site would be entirely susceptible to session hikacking.
  • The scheme could use a looser IP address check, checking only to make sure the client was in the same range of IP addresses from request to request; this would likewise open the site up to (a more limited scope of) session hijacking, and would be a completely arbitrary implementation of the idea that proxy requests will always take place within some generic range of IP addresses. (Of note, it appears this is how the popular web forum software phpBB has decided to deal with this same problem, only checking the first 24 bits of the IP address.)
  • The scheme could replace its checks of the client IP address with checks of other random HTTP headers (like the User-Agent, the Accept-Charset, etc.); to me, though, any competent hacker wouldn’t just playback the cookie header, he would play back all the headers from the request, and would easily defeat this check without even knowing it.
  • Lastly, the scheme could get rid of the client IP address check but demand encryption of all its traffic (using secure HTTP); this would work great and prevent network capture of the cookies, but would require an HTTPS server and would demand that the people running the app spend money annually to get a security certificate, all just to work around AOL’s decision on how the web should work.

In the end, I added a preference to my scheme that allows any single application to decide on one of two behaviors, either completely rejecting clients that are coming through AOL proxy servers (not shockingly, the way that many others have decided to deal with the problem), or allowing them by lessening the security bar for them and them alone. I check whether a given client is coming from AOL via a two-pronged test: first, I check to see if the User-Agent string contains “AOL”, and if it does, I check to see if the client IP address is within the known blocks of AOL proxy servers. If the client is found to be an AOL proxy server, then (depending on the chosen behavior) I either return the user to the login page with a message that explains why his browser can’t connect to my app, or I build my authentication token without the client IP address and then pass the user into the application.

Finding myself in a situation where users were inexplicably unable to access one of my web apps was reasonably irritating, sure, but the end explanation was way more irritating. Now, I have to maintain a list of known AOL proxy servers in all my apps, and potentially, I have to get involved in teaching users how to bypass the AOL browser for access to any apps that require the stronger level of security. Of course, it’s also helped me understand the places where my authentication scheme can stand to be improved, and that’s not all that bad… but it still makes me want to punish AOL somehow.

Wasn’t ESPN.com supposed to be the great example of a large website that was designed to adhere to standards and valid markup? If so, then someone should check in on the company’s compliance officer; he might have died at his desk.

Seriously, the degeneration of ESPN’s website has reached the point where, on my G4 Powerbook and via a dedicated T1, it takes over 14 seconds to load in Firefox, and over 16 seconds to load in Safari. There’s over 105 Kb of Javascript included in the site’s home page, added to the 114 Kb of images and 58 separate objects loaded from 14 different URLs (not including any additional objects that piggyback along with the Javascript files or Flash movies). That’s all just abhorrent, and the perfect example of the fact that even if they managed to wrangle the site into compliance, it’d still tremendously suck. It’s no wonder the sports URL my brain types out before I have a chance to think about moved to sports.yahoo.com about six months ago.

My favorite broken website of the day: the “Request Credit for a Referral” page of TiVo Rewards.

Back in mid-November, some friends of mine bought a TiVo, and when they activated their service, they put me in as the person who referred them. I got an email from the TiVo Rewards asking if I would like to sign up for an account and get credit for the referral, which I then did. (Irritation #1: despite the fact that I already have an account for my own two TiVos, the company required me to sign up for a separate account because my friends used an email address different than the one I have on file with TiVo. Period, no question, no ability to actually apply those points to the account I’ve had with them for years.)

The referral credit never showed up, so I started doing a little investigation and learned that there’s a way to request credit, but it has to be done within 60 days of my friends activating their service. (Irritation #2: the process requires that I provide the cryptic TiVo Service Number of my friends’ account, meaning that they have to navigate through their TiVo menus to the right place, write down the 15-digit hexadecimal number, and then send that to me.) Today, we were finally able to hook up long enough to get their service number, and I went to the aforementioned page to request the credit… only to find that the field specifying the year of their service activation doesn’t allow you to choose the year 2004. You know — the year that ended less than a week ago, that’s not an option.

Luckily, I was able to call, reach a competent customer service person with less than a ten-minute hold time, and get her to recognize the problem; she spoke to the relevant people and had them apply the credit while I was on the phone. (Irritation #3: the TiVo customer service phone line makes you go through one of those “tell me what you want to do” voice trees, where you have to guess the right phrase that’ll get you on your way.)

What’s the lesson here? Be careful that your customer loyalty programs — like TiVo Rewards — don’t make your customers more irritated with you than they do loyal to you. Having to chase down the credit for my referral, and then being unable to do so through the intended channels, makes me less likely to want to refer people to TiVo again, and thus, ends up having the opposite of its intended effect.

fight clutter with more clutter

This week’s entry in the anyone-can-be-a-website-designer category comes to us via Matt, and is an article about reducing website clutter which is part of a design and usability website that itself is surrounded by nearly two dozen advertisements and similar unrelated blocks of content. Honestly, it actually took me a minute or two to figure out that the whole thing wasn’t an enormous spoof, but alas, it’s real and it’s pretty damn sad.

While waiting for some gene expression data to model today, I whipped up a few block-based mockups of the web page. As a legend, the green blocks contain actual content, the blue contain website framing elements, the yellow contain what seems to be useless or misplaced bits of clutter, and the red contains out-and-out advertisements. Here’s a small, purely colorblocked version of the entire webpage, and an image of the actual website with the translucent colorblocks laid over it (there are also full-size versions of each image available). Looking at those, I’m certain that if a set of reviewers didn’t have a color key available, I’m sure they wouldn’t have any idea which color corresponded to actual content. In particular, note the little bits of red within the main green content block, all of which are embedded advertisements that I didn’t even recognize as such until they were pointed out to me earlier today.

To add insult to injury, it now looks like a moderator of the website has started deleting comments pointing out the irony of the situation. (You can see the titles of the deleted comments by viewing the front page of the article and scrolling down to the orange “Discuss More Website Knick Knack” box.) Methinks a better strategy might be to, you know, follow the advice of the article and redesign the godawful site, but what the hell do I know?