Lunch-time fun with QR codes

Starting with a B/W Oscar the Grouch image, and running it through the QArt Coder, got me here http://research.swtch.com/qr/show/e27c9ec04e3013fe - Paint.net took me the rest of the way...

Read about how this works at http://research.swtch.com/qart

I <3 IE8

No, not really. 

On our recently completed Vogue Archive project, IE8 support was a requirement, due to a large number of potential users being stuck at the office on Windows XP with no freedom to install a better browser.  (We had a similar requirement for Firefox 3.6 support, but nowhere near the same kind of trouble with that browser though it was definitely the second worst browser in our field).

Background

The Vogue archive is an HTML5^* + Silverlight application: we have two viewers, one built in HTML5 (for tablets and desktop browsers that support it), one built in Silverlight (for all desktop browsers). Both viewers are housed within the same HTML5 "chrome" - see yellow sections in the image below:

IE8, of course, was released years before HTML5 started its meandering way through the standardization process, so it should hardly be expected that IE8 should support HTML5.

Mmm, Cookies!

It should be expected, however, that IE8 could support HTTP cookies properly.

Not so much.

We got an error report from the field that when IE8 users logged out from the archive, and then logged back again, the logon process went through, and then promptly redirected them back to the unsecured welcome page at the start of the logon process. Hm.  Sure enough it did.  The excellent error report also stated that for some reason they were seeing two authentication cookies, one of which was empty.  Could that have something to do with it?  Huh? 

[Quite some time later]

The problem was indeed related to the double-cookies, but it appears it was actually caused by how IE8 interprets cookie expiration dates:

The standard way to delete a cookie is to create a new cookie with the same name, in the same domain (and path), with an expiration date set to a date in the past.  A pretty standard date to use is the 'epoch' start date (JavaScript's beginning of time) - midnight of 1/1/1970, GMT, represented as "Thu, 01-Jan-70 00:00:01 GMT;"

For whatever reason, IE8 sees this date, and attempts to convert it to local time - in our case (EDT) 4hrs earlier: 12-31-69 08:00:01 PM.  Slight problem - since '69 was before the start of the epoch, this is then further interpreted as meaning 2069 (never mind the second bug that a winter time should be converted using EST - aka GMT-5hrs).  So rather than creating a new cookie that immediately expired and thus was deleted, we ended up with a new very long-lived cookie.

To complicate things further, as a brute force way for us to make sure we delete both local and domain cookies (we don't know the preference of the client), in our delete-cookie script we actually create two expired cookies, one for each domain (i.e. vogue.com and archive.vogue.com).  It appears the login/logout process got confused and sometimes read one cookie (empty, expiring in 2069) and sometimes the other (valid session cookie).

Solution

While the analysis was complex, the solution was simple - we now use an expiration date of 1/1/2000 rather than 1/1/1970 - now IE can convert times all it wants, and it still stays a date in the past, and the cookie is expired.

Tell Them Again

I <3 IE8.

idea: bookmarklet to persist personal form data in localStorage

As a developer, I frequently have to clear my browsers cache, and also cookies, in order to test a site.  This is a PITA as now I'm logged out from Google, PivotalTracker, etc, etc.

It also showcases how very few sites store login information in localStorage by default (note to devs, if you're to offer a "Remember Me" button, use localStorage, not a cookie). 

So my idea is this: a set of two bookmarklets: the first would retrieve any form data entered in a form (prior to you submitting it) and store that data in localStorage, then the second would fill out a form using the data stored in localStorage for that site.

What about security you might ask?  Well, clearly this should only be used on a personal computer - and maybe password fields should be excluded in any case.  But this is stored locally, it is not transmitted anywhere, and the data is not accessible to any other site, so the data should stay between you and your computer.  One exception would be any potentially malicious script hosted on the site, but that seems like a risk in itself - the same script could much more effectively simply grab the form data on entry.

So - good idea or bad?

Rolling Stone Federated Search

RollingStone.com just deployed a new federated search feature, showing top results from the Rolling Stone Archive along with the regular site search.

My team member David Benson created the search service used in the federated search, a stand-alone Archive search page, and all the necessary glue to automatically direct users back to the intended content after authenticating.

The end result is a great way to tie the archive deeper into the Rolling Stone site, and to provide historical context to a user’s search:

When clicking on an archive link, if not authenticated, you are presented with an upsell/login page.

Once signed in you are then shown the article you clicked on:

Or if you clicked the View All items link, the full archive search, with facet filters and sorting options:

Enjoy!

Vogue Archive On CBS Sunday Morning

Since we built it, and it's not every day our products appear on national TV here is the obligatory self-congratulating video embed. Enjoy.

from CBS News: Vogue puts its 120-year history online

I’m turning Japanese, I think I’m turning Japanese, I really think so...

To all Japanese/Chinese/Koreans readers out there, my apologies: I have no idea what language this is that Chrome is using. But the song came to mind, and thus the title. The bigger question is: why on earth is this error coming up like this?