If you, like me, let Firefox 3 create a new profile for you when you installed it over the past week or two, you might want to revisit the step you’ll need to take to fix Firefox’s annoying I’ll-forget-all-your-cookies bug feature. It didn’t hit me until today that the reason my bank site couldn’t remember my login name was because Firefox was dropping the relevant cookie…

It’s amazing that we sit here, four years later, and the same broken behavior is accepted by the Mozilla folks.

I’m overall pretty happy about the release of Firefox 3, but am I the only one who’s seeing sporadic issues on Macs? On my iMac (2.1 GHz PowerPC G5), it’s painfully slow, so slow that I’ve started using Safari as my primary web browser. And on my MacBook Pro (Intel Core 2 Duo), I’ve had at least a dozen instances in the past three or four days where, during the loading of a tab, I get the spinning rainbow beachball of death and have to force-quit the app.

Ugh.

Now that pop-under ads have made a resurgence on the web — and nefarious webheads have managed to figure out how to make them happen even with Firefox or IE locked down pretty tightly — I have an idea that I’d love to see implemented. It’s rooted in the basic problem that by the time a user closes a web browser window and sees all the accumulated pop-under ads, he or she has no clue which website was the cause, and as a result, no idea which website should be the target of unabashed loathing. Simply put, the idea is that any web browser window should have a feature which shows the user the exact website address being viewed in the window that spawned the popup. That way, it would be clear as a bell which website was responsible for accepting ad content (or worse, purposely programming content) which behaves this egregiously, and it’d be much easier for users to then avoid those websites — voting with our pageviews, as it were.

Who’s with me?

This morning, I was greeted by a Firefox alert letting me know that version 2.0.0.4 is available for installation. I decided to read the release notes, and found this gem among the info applicable to all systems:

When trying to print web pages with text areas, if the text area contains a misspelled word and spell checking is enabled, all the following content of the text area will not be printed. You can right-click in the text area and uncheck “Spell check this field” to turn off spell checking temporarily while you print.

Are you kidding me? I mean, we’re not talking about an edge case here — spellcheck is turned on in textarea fields by default, and there are a hell of a lot of people who print various forms they’re about to submit on the web as a form of recordkeeping. The folks at Mozilla decided that this rookie crap isn’t the sort of thing that should be fixed before releasing the browser upgrade? (And better still, it appears the bug was fixed back in December of 2006, but that nobody has deigned to include the fix in the current Firefox builds.) Awesome.

One of the unfortunate facts that derives from not having been in my regular office for the past two weeks: my web browser history is blank, meaning that none of my usual URLs autocomplete in the address bar. Gah!

One little bit of advice: do yourself a favor and give Firefox 2.0 RC3 a try. Over the past month or two, a few people have told me how much faster the new version of Firefox is when compared with the current v1.5, but I didn’t believe them until I finally got around to installing it last night — it’s amazingly peppy, and it’s been rock stable on the few machines on which I’m now running it. I’ve always found the page rendering part of web browsing to be a bit lethargic on my Macs; Firefox 2 feels comparable to Windows browsing, which is mucho mejor. It’s good enough that I’m changing my default Mac browser back from Safari to Firefox.

(And since my biggest fear about the upgrade ended up not being a big deal at all, I’ll mention that all of the extensions I use regularly — the Google Toolbar, Firebug, Greasemonkey, the del.icio.us extension, the Web Developer Extension — have updates available which are compatible with the new Firefox. The only extension in my installation that didn’t have a Firefox 2-compatible version was Live HTTP Headers; it’s not one I use on a day-to-day basis, though, so I’m OK with leaving it out of my install until it comes up to speed.)

I run a web-based email application on my domain, and it’s coming up on time for me to renew the SSL certificate that keeps people’s email sessions secure. For the past four years, I’ve used Thawte to issue the certificate, mostly out of inertia, but looking at their offerings today, I noticed that the price for my type of certificate has somehow increased 20% since the last time I renewed (from $299 to $349 for a two-year certificate). Given that I can’t imagine the actual cost to Thawte of issuing a certificate has increased one cent during that time period, it’s time for me to do a little comparison shopping.

In the past, I’ve stumbled across a few alternatives to Thawte (and Verisign, the questionably-trustworthy company which owns Thawte) when it comes to issuing SSL certificates. There’s InstantSSL, which currently is offering a two-year cert for $100, but which only issues chained-root certs (requiring the installation of additional layers of trust in order to get the whole thing recognized by a web browser as truly secure). It’s a bit cumbersome, and there are a few webservers out there that don’t support chained certificates, so if you’re interested in this route you’ll want to make sure that you check into this. (The certs issued by GoDaddy and DigiCert suffer from the same issue.)

RapidSSL looks like a very reasonable alternative ($70 for one year, $121 for two years), and they’re running a free one-year promotion right now for people switching from Thawte. Their certs are single-root, and provide up to 256-bit encryption, and appear to be well-supported, so they might be getting my business soon.

I have a few weeks to mull all this over; does anyone have any other specific recommendations (or warnings of companies to avoid)?

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.

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.)

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.

Hey Old Navy, Gap, and Banana Republic: Mike Rundle has a message for you. I gotta tell you, I’ve now helped two people move to Mac laptops in the past year, and at least one of them has since told me that he has essentially stopped shopping on your websites, given that you don’t give a crap about supporting the default browser on his machine. Alas.

Shannon and I are pretty big fans of Southwest Airlines, given that they usually let us make our monthly wedding-planning visits to south Jersey for under $60 round-trip. On Thursday morning, I logged into the Southwest website to print our boarding passes, and couldn’t figure out why I wasn’t able to select both of our reservations to print until I closed Safari and logged back in using Firefox. It turns out that Southwest’s website pushes different pages to Safari users than it does to Firefox users, and the difference makes no sense to me at all.

On the left is the reservation selection page in Firefox; on the right is the same page in Safari:

   

See the difference? In Firefox, not only does the site provide checkboxes for selection (a type of form input that allows the user to make multiple selections at the same time), it provides a link that quickly selects all the checkboxes at the same time. On the other hand, in Safari, the site provides radio buttons for selection (a type of form input that only allows the user to make one selection at a time), and omits the select-all link. Looking at the source code for the pages, the server truly does send different form elements, and I’m at a loss to explain why they do so. The one thing I can say is that it makes it that much more difficult for someone with Safari to use the site, which is just plain annoying.

James Bennett published a nice op-ed piece over at Kuro5hin on Friday that tries to get to the bottom of the Google Toolbar shitstorm, and concludes that the large push against it has nothing to do with copyrights, derivative works, or content publishers’ rights, and instead is all about fear and loathing of Google. It’s worth the read, as is the resultant comment thread.

It’s so much fun watching someone like Cory Doctorow completely dissassemble the Google Toolbar nonsense. In a post on Saturday, he outlined the reasons why services that let users decide how to display content are the very reason for the innovation that’s driven the web since the day it appeared; yesterday, he followed that up with a glimpse of other projects out there that provide similar services for users using Google’s own data. And then this morning brought the latest salvo, a two-fer that included a good real-world analogy and a smackdown to a pathetic attempt to raise Cory’s ire.

Every time that the total hacks of the weblog world start to annoy me by simultaneously attempting to rule the terms of debate and ignoring the incredibly nuanced debate that’s occurring all around them (including in their very own comment threads!), it’s refresing to see that people like Cory step into the breach and provide a voice of reason.

This morning (don’t you love that 12:55 PM is “morning”?), I’ll share a few links that found their way into all the tabs I have open, waiting to be read. The sharing is partly because I have to update my web browser, so I’ll be losing all those tabs soon; it’s also partly because they’re all share-worthy.

• The City Record and Boston News-Letter: this is a (TypePad-driven!) site run by Charles Swift and devoted to Boston’s history; Charles came across my June 2003 post about moving to Boston and wanting to spend time delving into the history of the region, and was kind enough to drop me a line overnight letting me know about his site. This is the kind of weblog that sits smack in the middle of my danger territory — I could start reading it, and get so engrossed and so obsessive that I might never come out.
• Guide to Using XmlHttpRequest (with Baby Steps): I posted last Monday about Jesse James Garrett’s piece on Ajax, the newest Big Thing in web development, but lamented that there still wasn’t a user-level guide on implementing it. Well, now Bill Bercik has done that, and I couldn’t be happier. I’m currently finishing off the reimplementation of one of my web applications in PHP, and after reading Bill’s piece, I’ve already started forming a mental checklist of places that I might want to think about using Ajax in v2.1 of the app.
• The MN Musolfs: OK, this one is mostly personal — it’s the new Blogger site of a friend of mine. The part of it that isn’t personal, and what motivated me to include it in the list, is that she (or her husband) is a natural-born blogger; in one page of posts, there are baby pictures, recipes (a hot tuna wrap!), and laments about the cancellation of the NHL season. I can’t wait to see where the site goes, and it’s nice to have the added way of keeping up with long-distance friends.
• Rolling with Ruby on Rails: this is a O’Reilly review of the web development technology that’s being called The Way Of The Future, and while I’ve been at this long enough to know that there’s as much hype as reality in claims like that, I’ve also been at this long enough to know that, at a minimum, being called that means that the technology is at least interesting. And according to this MetaFilter thread, some of my favorite websites were built using RoR. So I’ll give it a read.
• Stage Fright Remedy: this is a brother-sister guitar and vocal duo that Shannon and I heard on the “Talent from Twelve to Twenty” Prairie Home Companion show last weekend, and even though they didn’t win the competition, we really liked them. Turns out that they’ve got music online, and it’s already made its way onto both of our iPods. (Of note, I also loved the bluegrass music of The Lovell Sisters Band, but they’ve got nothing online, so it’s hard for me to keep listening to them!)

I tried to reply to Joe Holcomb’s rant about the Google Toolbar violating the DMCA over on his website, but his comment page won’t accept my comment, so I’ll do it here. This is the comment I tried to post:

Joe, I assume that you mean that Google violates Title V of the DMCA because it creates a copy of a protected design and then republishes it for use in trade; if I’m wrong, then I apologize. But if I’m right, then I feel I need to correct you, because despite you saying that Title V is “the section that protects copyrighted works online,” that’s just not true — Title V protects “certain original designs” (note the lack of the word copyright anywhere in the Title). And to be very specific, Title V only applies to boat hull designs. (The definition is right there in Chapter 13, Section 1301(b)(2): “A ‘useful article’ is a vessel hull, including a plug or mold, which in normal use has an intrinsic utilitarian function that is not merely to portray the appearance of the article or to convey information.”) Perhaps that’s why the short title of Title V is “Vessel Hull Design Protection Act.”

I seriously wish that people would stop trying to redefine reality in order to try to satisfy their position in this argument. Nothing in the behavior of the Toolbar is automatic, the links that the Toolbar creates have characteristics which distinguish them from any and all other links on the page, and the Toolbar never rewrites links that authors have already included in their websites which earn those authors affiliate money. And now, I can add to that list that web pages are not vessel hulls, and Google isn’t profiting on the backs of the poor, mistreated boat hull designers’ work.

UPDATE: It turns out that Joe must have comments set to need moderation before posting, because he’s been putting ‘em up when he posts his replies. And his latest reply is hilarious — he makes up or assumes definitions to fit his idea of what the DMCA should protect. The best example is Joe’s statement that Title V of the DMCA extends its legal protections to “an original design of a useful article,” but then totally omits that Title V very specifically defines what “useful article” means: “a vessel hull, including a plug or mold, which in normal use has an intrinsic utilitarian function that is not merely to portray the appearance of the article or to convey information” (section 1301(b)(2), to be exact). I think I’ve come to the realization that he’s not doing this with total intention to mislead, but rather, he just doesn’t have any idea how to read the law. I guess that’s why there’s a whole cadre of professionals out there who make a living interpreting and defending the law!

Jesse James Garrett has a great new piece up on the Adaptive Path website describing the technology behind the newest generation of web applications. Instead of providing the standard click-and-wait approach to doing things on the web, companies like Google, Ludicorp, and Amazon are implementing apps built on a foundation of asynchronous communication, JavaScript, and XML (hence the nickname “Ajax”); the combination allows the apps to behave more like desktop applications, with fast response times (like being able to move a map around in real time) and a ton of activity on the client side (like autocompleting entries into text fields, or an entire interface implemented at the client like in Gmail). The idea is catching on enough to show up on personal sites, as well — for example, the search functions on Anil’s and Dunstan’s weblogs return results as you type.

Jesse’s right — Ajax is a revolutionary step in the evolution of the web, and it’s certainly going to be fun watching how developers use it to create the kind of applications that make users stop noticing the difference between the web and the desktop. Google Maps and Gmail are already doing this; as soon as there’s an Ajax implementation that’s easy for the lone developer to install and use, the sky’s truly the limit.

Over the past few days, I couldn’t figure out why the portrayal of bloggers as mainstream media checkers didn’t sit well with me, but I knew that something was wrong. After reading a few more bloggers’ versions of what Google’s trying to do to America with their latest Toolbar beta, I now realize what it is: bloggers are just as bad as — and in some ways way, way worse than — the mainstream media about taking an out-and-out falsehood and running with it, usually without doing anything other than taking what they’re told and repeating it more vehemently. In this instance, it seems that all it took was a few people claiming that AutoLink automatically changes the text in web pages, and now that’s all anyone’s saying despite the fact that it isn’t true; website operator forums are literally exploding with outrage, media watchdog bloggers are repeating their complaints without any attempt to verify them, and scores of users are hopping mad that someone would dare mess with their web browsing experience (even though they’re happy to use popup blockers and other tools that modify the display of a web page’s HTML code). The only thing I can conclude is that none of them have even installed the Toolbar, the same conclusion I’d make if someone told me that they hated the graphing calculator feature in AOL Instant Messenger.

Don’t get me wrong — there are a lot of people maintaining weblogs who could factcheck anyone’s ass better than a huge chunk of the mainstream media (for example, cross the folks over at MetaFilter at your own peril!). But at least in most segments of the mainstream media, there are editors who would check to see if what a writer describes has any basis in reality. Then there’s the tabloids, and in the Google Toolbar outrage, that’s what a ton of bloggers are showing themselves to be.

A plea to all the reactionaries who are thinking about jumping onto the anti-Google bandwagon over the latest beta of the Google Toolbar: perhaps you might think about trying the freaking thing before you lambast the company for behavior that you’re inventing?

For those who haven’t come across the brouhaha today, the Toolbar now has a feature, called AutoLink, that is able to search a web page for specific forms of information and then link that information to sites that provide additional detail. (For example, it can turn a FedEx tracking number into a link to FedEx’s package tracking site.) Almost every outrage I’ve read today decries the horror of Google “automatically” rewriting the text of web pages, neglecting to mention that there’s nothing automatic about it, but rather the user has to click on the AutoLink button in the toolbar in order to use the feature. So it’s no different than the “highlight search text” button — it’s a way for the user to choose to modify the information in a web page in a fashion that’s useful to them. It’s also no different than a user choosing to zoom in on images, change the display of nofollow links, or even block popup ads, in that users are making conscious choices to increase the utility of their web browsing experience.

(And understand that even if the user didn’t have to click on the AutoLink button, I’m still of the belief that installing the Toolbar, or any tool, constitutes a choice made by the user to accept the utility offered by the tool. Sure, the maker of the tool should be nice and offer the ability to either turn off or uninstall the tool, and likewise should try to offer ways for content publishers to know that the tool is in use and decide how to handle that, but there’s nothing inherently evil about such tools being available to users!)

So, I’m at the point where I want to take Firefox and shove it straight into my Powerbook’s trashcan. It’s become an unpredictably unreliable application, and it’s not clear to me that there’s anything I can do about it except trawl Bugzilla, add my experiences where possible, and hope and pray that sometime it’ll all get fixed. Some of my current frustrations:

Occasionally, issuing any keyboard-based shortcut command (e.g., CMD-T to open a new tab, or CMD-W to close a tab) issues that command twice. And while this is merely annoying at times, it’s downright infuriating at others — like when I intend to close the currently-open tab, but Firefox instead closes it and the one beside it containing something on which I’m actively working, completely losing whatever it was I was doing. (Oddly, when Firefox finds itself in this state, certain other keyboard shortcuts stop working entirely, like CMD-Q to quit.) There’s an entry on Bugzilla for this, but it’s still listed as an unconfirmed bug. That entry also links the behavior to the use of Java, which I’m not sure is the only cause, since there are times that I’ve seen the behavior when there isn’t anything Java-related open in any tab or window.

At other times, Firefox stops allowing me to enter any text whatsoever into any text box, including the address bar, the search box, or any text input field on a web page in a window. (There are times when I have multiple Firefox windows open, and interestingly, when the bug happens, it only happens in one of the windows.) About 75% of the time, I can “fix” things by switching to another app and then back to Firefox; the other 25% of the time, there’s nothing I can do but close the affected Firefox window entirely, losing all the tabs that are open in that window, including any work I might be doing in those tabs. (There’s a Bugzilla entry on this one, as well.)

Then, there are certain bits of Flash content that will bring Mac Firefox to its knees, and (in a common theme) force me to force-quit the browser and lose all of my work. As far as I can tell, there are a bunch of open Bugzilla entries for this (172175, 233702, 244987, and 106397 are the ones I found in my not-so-quick survey), all of which have in common the fact that if you can see the Flash object that’s causing the problem, holding down the mouse button lets it continue to run, but doesn’t let you salvage your browser or your work.

And lastly, there’s the occasional thing that, while still a bug, has less to do with reliability and more to do with good ol’ missing, broken, or just plain odd functionality. My best example of this is that on the Mac version of Firefox, you cannot open a new window — or do any menu-based tasks — when the only window open is the either the Download Manager or the Preferences window. The interesting thing to note about this is that, in its most basic causal form, the original bug was filed on December 9th, 1999, and around 50 other bug reports have been marked as duplicates of this bug, meaning that people have run into it over and over again without the error being fixed. (And that doesn’t count the five or six currently open bugs that look like they’re headed to being classified as duplicates, nor does it count the bugs that were classified as duplicates of other bugs which were then classified as duplicates of this one. Holy recursion!)

So, lately I’ve found myself having both Safari and Firefox open, and using Safari whenever I need to do any real work. That’s sad; I like having the same browser on my Macs and PCs, and I like the openness of Firefox, but I don’t like the number of times I’ve lost important sites or work to its bugginess.