I can’t even begin to describe how angry it makes me that many states are considering sanctioning the idea that health care providers can deny people care based on religious beliefs. Forget about pharmacists who exercise their religion at work and refuse to fill prescriptions for birth control medication; the absolute truth — no exaggeration at all — is that “right of refusal” laws like these could grant a doctor the right to put you on a ventilator even if you have a perfectly valid, legal living will stating your preference otherwise, and could allow everyone from doctors to social workers and pharmacists to completely decline care for gay patients. Hell, they’d even let fundamentalist pediatricians and internists refuse to treat sexually-transmitted diseases in unmarried patients, and Jehovah’s Witness physicians could refuse to give patients blood transfusions.

This crap is the perfect illustration of the idiocy of mixing religion and government. With laws allowing medical providers to enforce their religious beliefs on patients, where do you draw the line? What religious beliefs are acceptably covered by these laws? Who determines if some provider’s religious beliefs are worthy of protection? Ultimately it comes down to this: why are a doctor’s religious beliefs more important than the will of the patient?

The Ninth Circuit Court of Appeals ruled yesterday in support of airport regulations demanding the display of identification by travelers — and in support of the existence of secret laws, laws that our government can prohibit people from scrutinizing yet can impose on those same people. (The decision, in PDF form, is here.) As reflected in my feelings back when the case (Gilmore v. Gonzales) was being argued, this is somewhat disappointing; it seems perfectly contrary to the ideals of our country for there to be laws whose words exist behind lock and key, but whose force exists in the lives of each of us.

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.

Does anyone remember ChoicePoint, the data warehousing company that gave criminals access to the personal data of over 150,000 U.S. consumers back in 2004? When the story broke about a year ago, I made note of how ChoicePoint itself actually had been part and parcel of the problem, and lamented the way in which the media was portraying ChoicePoint as a victim rather than as a participant in the destruction of privacy. In light of that, I’m superbly happy to see that the Federal Trade Commission agreed with me today, fining ChoicePoint $10 million and noting that the firm had failed to tighten its internal security despite specific federal warnings going back as far as 2001. The firm also has to pay $5 million into a consumer redress fund, establish comprehensive information security programs, and submit to biennial security audits through the year 2026. (Of course, ChoicePoint netted $147 million in 2004, so part of me would have loved to see even steeper fines; that would have been as clear a message as possible that putting American consumers’ personal data at risk is a corporate practice that will effectively lead to the end of your corporation.)

It’s been a bit of a busy week; I’m part of the faculty group that’s teaching the second-year medical school hematology course right now, meaning that I’ve been waking up about an hour and a half earlier than normal, teaching for most of the morning, starting all the other work I have to do around noon, and getting home feeling like I’ve been run through the ringer a little bit. That being said, teaching is a lot of fun, and it’s a hell of a reminder of how much I’ve learned since I was in the same class eight years ago back in New York.

Oddly, my respite from the world of medicine this week has been task-guided learning of a new programming language, Java. Towards the end of last week, Matt got the idea of starting up a Jabber server linked to his übersite MetaFilter, and really wanted people to be able to use their MetaFilter usernames and passwords to log into new service. He decided to try out a server that’s coded entirely in Java and has an open, extensible architecture, and asked me what I knew about getting it to talk to his user database. I started looking into the app, and quickly realized that Java is built from the same elements as are most of the other languages I know well, something that went a long way towards putting to rest my fears about delving whole-hog into the guts of the server. A few hours later, I had put together the code that Matt needed, and early this week, I wrote an plug-in from scratch which allows regular users to see a list of all the active users of the server. And while I wrote the first set of tools — the authentication modules — in response to Matt’s need, the goal of getting my feet wet in Java motivated my development of the plug-in as much as did the development of a useful tool for the MetaFilter community. For me, that’s the best way to start to learn a new technology: realize a need, discover that the technology is the best way to fulfill that need, and jump in.

Seriously, why is it taking the Yankees (and Major League Baseball) so long to release official Johnny Damon Yankees T-shirts? Being marooned here in the land of the BoSox (and thus having had to tolerate the puppy dog love of the Unfrozen Caveman Lawyer displayed by nearly every Boston woman for the past two years), I really can’t wait to wear a Damon Yankees shirt into the hospital. Alas, the official MLB merchandising juggernaut hasn’t gotten around to making anything but the official (and $190) jersey for the Yankee’s newest outfielder, and while I’m sure that there are plenty of knockoffs along Canal Street in Manhattan, there’s nothing here in Boston but “Johnny Judas” shirts. It’s getting bad enough that I’m considering getting a “Welcome to New York, Johnny” shirt being sold online by Modell’s…

This morning, while I was slowly waking up and surfing the web (totally uncaffeinated, since the reason I was awake was to wait for our grocery delivery, which contained the all-important milk for my coffee!), I read a news story that woke me up in a hurry by getting my blood boiling. The article is about Sam Beaumont, an Oklahoma rancher who, in 1977, met Earl Meadows, fell in love, and lived for over twenty years with the man and his three children. In 1999, Beaumont had a stroke, and Meadows cared for him until he died a year later. Beaumont’s will left everything to Meadows, but the state of Oklahoma invalidated the will because it had one too few witness signatures — and (as you’d expect) Oklahoma has no common-law rules that would allow for Meadows to remain the rightful inheritor. That left everything (their ranch, all the animals) being auctioned off with the proceeds being split among dozens of Beaumont’s cousins. Oddly, though, this is now a common-enough story that it alone is barely enough to enrage people, and isn’t what made my blood pressure explode — what did that was the fact that all the cousins are now suing Meadows for back rent on the property. (The relationship and controversy are among those profiled in the 2003 documentary Tying the Knot.)

Seriously, for all those out there who feel that gay people are going to hell, my rebuttal is that there’s a very special place in hell for people like those cousins, looking to actually profit from their bigotry and closemindedness (and for certain elected representatives of the fair state of Oklahoma who spout hate on the floor of the U.S. Senate).

Back in October, I wrote about some Bank of America customer deciding that he would use my Gmail account’s address as the destination for all of his online banking notices, and about how the BoA reps painstakingly claimed to not be able to do anything to deal with the error. The story ended OK, though — I gave them a second chance by calling back a few days later, and ended up getting a competent manager who found the right accountholder and then called him to ask him to correct his error. For two weeks or so, the notices stopped — but then they started right back up again, with the same last four digits of the account number. The realization that the same person put the wrong email address into his BoA account preferences a second time made my brain hurt, so I just put it on the back burner and hoped that it would sort itself out (ha, ha). Alas, they kept coming, so today, I called BoA again.

In contrast to that first phone call back in October, this time the company performed admirably. The first-tier rep understood how annoying this is and got me to his manager quickly (saying that he didn’t have the authority to browse the account database or cold-call customers). The manager spent a few minutes looking up every accountholder with the same first initial and last name as me (which corresponds to the format of the Gmail account), and in about four minutes, she had him. She promised that as soon as we hung up, she’d again contact him, and she’d also leave a detailed note in my account so that if when this happens again, it won’t even take this long to handle.

As frustrating as bad customer service is, good customer service can be even more gratifying.

Oh, hallelujah — the Internet Explorer dev team has finally decided to fix a bug that’s almost always the cause of excruciating pain to me when I stumble over it, the famous <select> element that doesn’t allow accurate placement within a page’s layers. (For my reference as much as anyone else’s, I tend towards Joe King’s bug workaround, since I can implement it almost exclusively in Javascript, making it easy to peel out of the page when it’s no longer needed.)

Ours is a government of limited power. We learn in elementary school the concept of checks and balances. Those checks do not vanish in wartime; the President’s role as Commander in Chief does not swallow up Congress’s powers or the Bill of Rights. Given the framers’ skepticism about executive power and warmaking—there was no functional standing army at the beginning of the nation, so the President’s powers as Commander in Chief depended on Congress’s willingness to create and expand an army—it is impossible to find in the Constitution unilateral presidential authority to act against US citizens in a way that violates US laws, even in wartime. As Justice Sandra Day O’Connor recently wrote, “A state of war is not a blank check for the President when it comes to the rights of the nation’s citizens.”

Elizabeth Holtzman penned a fantastic piece entitled “The Impeachment of George W. Bush” in this month’s issue of The Nation. Holtzman served in the U.S. House of Representatives from 1973 to 1981, and was a member of the House Judiciary Committee that held hearings on the impeachment of Richard Nixon in 1974. In the piece, she makes a reasonably strong argument for how Bush has carried on in a way detrimental to both the office of the Presidency and the nation as a whole; I’d say that it’s worth a read no matter which side of the political fence you’re on (but of course, I know better than that).

Holy crap — how did I never know about the nightly WebKit builds? (For those of you whose inner geek isn’t as sadly web-centric as mine, WebKit is the framework on which Apple’s Safari web browser is built, and the nightly builds are the versions of the application built every night from the current development codebase.) I stumbled upon them tonight, and immediately fell in love with the Web Inspector, a much nicer implementation of Mozilla’s DOM Inspector. Parts of it haven’t been implemented yet (hence its presence in only the nightly builds!), but it looks to be a great new tool, and a great way to debug my web apps in another browser.

Lately, RCN has been running commercials in the Brookline market that involve a guy coming on-screen and explaining ways that RCN feels people can get more out of their cable internet connections. The guy runs through the steps needed to complete some task that RCN has determined will make using a broadband connection better; the commercials are pretty hysterical, if only because they’re both totally low-rent and pathetically simple-minded. (And better yet, they’re about 50% louder than the content that precedes and follows them, meaning that the guy is always shouting at you.) You’d at least figure that RCN would use the opportunities to address the threats that today’s internet (and specifically broadband) users face — phishing attacks, viruses, port scanning and security exploitation — but in fact, you’d be wrong. The first commercial we saw involved the guy literally explaining — in as rapid-fire a way as posisble — how to set up Outlook Express for an RCN account; the next one actually walked people through power cycling their cable modems. (Shannon turned to me during the tenth or so time we’d seen the power-cycling commercial and asked, “Do you think RCN is aware that they’re the ones responsible for people having to power cycle their cable modems in the first place?” Alas, no, they’re totally unaware of that fact.)

I’m sure that the idea of RCN using its own television bandwidth in a combined effort to promote its service and educate its users looked great on paper, but on the implementation side, it’s pretty awful.

In an effort to cut down on spam email, a few years ago I put together a clean little framework for a contact form, and put it up in all the relevant places so that people could still send me the occasional note through the various websites that I host. Lately, I’ve been getting a bit of spam submitted through the forms, more annoying than voluminous, and then tonight I learned from Matt Haughey that he’s even seeing a steady stream of spam submitted through the “suggest a post” function of his website PVRblog. It’s amazing to me, only inasmuch as it’s clear that the content spammers are now literally shoving their bits into any and all <textarea>s they can find on the web, much like that dog in heat that won’t stop humping your lamppost.

Ok, this makes me sad. I’m a huge macaroni and cheese aficionado; seriously, I’ll eat it almost any time it’s on a menu, and almost descended into clinical depression when one of my favorite local restaurants took its mac and cheese with chorizo off the menu. Imagine how happy I was, then, when the venerated New York Times published a “Crusty Macaroni and Cheese” recipe two weeks ago, alongside an accompanying article that went into a lengthy discussion of how hard a good, homemade mac and cheese is, and how the included recipe managed to make it a lot easier by not using white sauce (the mixture of butter, flour, and milk that helps the cheese achieve a melted, smooth, and gooey state). I printed the recipe and put it aside, intending to give it a whirl in the coming weeks.

Apparently, I’m not the only one that noticed the recipe; along with about a million webloggers, Slate’s Sara Dickerman found it, and was immediately suspicious of its no-white-sauce claims. She made the recipe twice, and got uniformly unsatisfactory results — “leathery shield” and “unpleasantly unctuous” were descriptions she applied to the concoctions she ended up with. That’s dissapointing… but a validation of the fact that there really is no way around putting a moderate amount of work into the perfect mac and cheese. Oh, well!

I think that, with a week’s worth of content under her belt, it’s now time to point out that my mother has joined the world of weblogging. (I can honestly say that that’s a phrase I never thought I’d be saying.) Her site, Paper and Threads, is devoted to her drawing and quilting (hence the title), and I couldn’t be happier to see her taking to the medium like a fish to water.

A bit of backstory: a few months ago (not long after she learned about my site), my mom sent me a link to a weblog run by Danny Gregory. Gregory is the author of Everyday Matters, a part-journal, part-sketchbook that describes how he recovered from his wife’s tragic accident by wandering the streets of New York and drawing. Gregory’s website has become an adjunct of sorts to his book, and has even inspired a Yahoo Group in which participants discuss drawing and even engage in weekly challenges. For a while, a lot of the members were using Flickr to upload their drawings, but when the folks behind Flickr began enforcing a photos-only policy, people found themselves without a home for their artwork. Soon thereafter, my mom asked me if I could help her work out a solution, and it didn’t take long to realize that that solution was a Movable Type site of her very own!

The funny thing about all of this is that it doesn’t feel like it’s been all that long since she turned to me in the car and said, “OK, now tell me all about this internet thing.” We quickly found our way to a local Chinese restaurant, and I spent the better part of the next two hours explaining the web, email, and the general mechanisms that make the internet function. (Of course, sitting down and doing the math, I just realized that that was in either 1995 or 1996 — so about a decade ago!) Over the intervening years, she’s come to understand a ton about the online world, but when I started this site back in 1999, there isn’t a chance in hell I’d have guessed that she would eventually embrace the medium. How far things have come!

Peter Rainer, the film critic at (of all places) the Christian Science Monitor, penned a great piece about the trend towards people treating movie theaters like their living rooms. (Thanks, Rebecca!) Of course, this isn’t as recent a trend as Rainer would have you believe; Anil wrote about it (and made lemonade out of the lemons) nearly four years ago. I certainly see Anil’s point… but I’m also irritated to all hell when the person behind me decides to answer the phone and begin an entire description of his day.

If you’re one of the people who reads this site in an honest-to-goodness web browser window (rather than a syndication aggregator), then you’ve probably noticed that I went and redesigned things around here. The last time I went and did that was in February of 2002, so that would explain why I’ve been feeling that my layout was a bit stale. Welcome to the 2006 version of Q Daily News… and keep your eyes peeled around mid-2010 for the next iteration!

A few notes on the design:

• Given that the title and navigation never felt intuitive to me over in a bar along the right, I moved it all up to the top. Not really rocket science, but it certainly went a long way towards making the site feel right to me.
• Over the past year or two, I’ve been trying to use categories when I write posts, if only to help gather similar subjects together on category pages. Of course, I never exposed any of this to viewing through the site (for reasons having more to do with laziness than difficulty), so I fixed that wrong. Likewise, I decided to make entry titles a little more prominent; they used to be visible only on each post’s individual archive page, but now they’re above each entry on the main page and on the monthly and category archive pages.
• Over the past few years, I’ve been squirreling content away in various publicly-accessible web services (like the photo archive Flickr, and the bookmark storage site del.icio.us), something that always made me feel like I was competing with my own weblog. Rather than stop using the web services, it made more sense to me to bring that content back to QDN… so now you’ll see a few content areas in the righthand sidebar that weren’t there before, including the last three pictures I’ve uploaded to Flick, and the last five bookmarks I’ve posted to del.icio.us.
• What you’ll see is now missing from the sidebar is a list of links (a blogroll, as it were); I found that my old link list rapidly got crusty as people shuttered their sites, moved URLs, or generally fell off the web. I’m tinkering with a few ideas about how to add it back and make it more current, so we’ll see what comes of that.
• I used Tim Appnel’s mt-archive-dateheader plugin and a bit of PHP reprocessing to revamp the archive page. The long, thin list of links to month-by-month archives was always just on the barely-tolerable side of acceptable to me; at least displaying them within year blocks seems a bit more logical.
• I was within micrometers of doing away with all TrackBack functionality (given that my last valid TrackBack was sent back in September), but I decided that the spam-filtering code in Movable Type 3.2 makes TrackBacks low-cost enough to keep around for a little while longer. I did tinker around with how they’re gathered and displayed on entry pages, though, which will make it easier to just abandon all TrackBack functionality if that’s what I ultimately decide.

As Shannon and I blew through New York City two days after Christmas, my folks passed along another few batches of old photos that they had culled out of their huge collection. I’ve decided to try to scan a bunch of them for safekeeping, and had to start with this one — to me, it’s a great window into the individuality of me and my siblings. That’s Noah, on the left, looking pretty well-put-together (hair brushed, sleeves carefully rolled up, looking suave with his hands in his pockets), and Rachel on the right looking coy and mischevious. And of course, I’m in the middle, a little more dressed-down, hair wild, and goofing off as usual. Really, it’s perfect.

Looking at the size of the USB thumbdrives Sony announced at CES yesterday (is it possible to use the term “thumbdrive” to describe these, given that they’re smaller than a lot of people’s thumbnails?), it looks reasonably clear that if Apple decides to stick with the iPod Nano form factor, the next generation might well have the same capacity as the current regular iPods. That’s pretty amazing.

You’d have to be living in a cave to not have heard news last week about a Windows security flaw that’s already being talked about as one of the worst, and most dangerous, ever found. (The executive version: there’s a flaw in a part of Windows devoted to interpreting image files that lets those image files contain actual program code which can do Very Bad Things to a computer. And the worst part is that all someone has to do to trick the computer into running that program code is get that computer to display the trojan-horse image — like getting the user to surf to a web page, or even just read an email. Microsoft’s security bulletin is here.) While I’m not usually prone to Microsoft bashing, it’s a pretty pathetic statement that the bug was found last Tuesday, and the danger of the bug was validated the very next day, but we’re now six days later and don’t have a patch from the folks in Redmond. And sadder still, a patch has been written by someone totally unaffiliated with Microsoft, Ilfak Guilfanov. (The well-respected Windows security expert Steve Gibson explains how Ilfak’s patch works here.) If I were administering a slew of Windows machines, I’d have to think long and hard about not distributing Ilfak’s patch as soon as possible, and then uninstalling it once Microsoft gets around to issuing something more official.

Update: now that the folks at SANS (possibly the most knowledgeable and well-respected computer security experts in existence) are recommending using Ilfak Guilfanov’s patch, I think that sysadmins who choose not to use it are asking for their networks to get compromised. They’ve also produced an MSI installer that is suitable for unattended installation via policy files, something that should make most admins of large Windows sites pretty happy.

I’ve been told by friends that know my music tastes that I’d really enjoy Coldplay. (Mind you, it’s not like I’ve never heard the band, but all I have heard is the songs that get playtime on Boston radio.) It appears, though, that Coldplay has included in their latest album an entire list of things you’re not allowed to do with it, a list which includes a ban against converting the songs to MP3s (meaning you cannot load it onto your iPod or into iTunes). It also warns you that the technology used to “protect” the CD might prevent it from playing in a whole slew of everyday CD players… and the best thing is that this whole list is on the inside of the jewel case, and inaccessible to buyers until after they’ve forked over their money. (On the album’s Amazon page, it turns out that there are a few reviews warning against this very thing.)

It’ll be so nice when bands and their labels come together to stop screwing consumers. Is there any doubt that the simple existence of a vibrant MP3 player market has driven a huge amount of interest in music? What would possess labels to turn their back on all these potential consumers? (Of course, the reason that Coldplay’s restricted-use list appears inside the jewel case is that, were it to be in plain sight on the outside, there would likely be a lot less people buying the album… so in the end, the labels hope that consumers are just too uninformed to know about the screwing until after it’s been done.)