Forum Moderators: open
It's not often that something innovative comes out of the JavaScript world, but here's one that raised my eyebrows. Developers have been searching for eons for a way to sessionize users that have cookies disabled. Thomas Frank (as reported today at Ajaxian) has invented a way to do it.
The window object has a property name which we rarely use any more... it's still handy when writing multipane, multiwindow applications, but in most situations dialog boxes speak to their fellow windows using window.opener or other properties, and name is merely a convenience for targeting open windows or preventing the opening of multiple modal dialogs. However Thomas Frank wrote a wee library that employs the window name as a kind of session object. How it works is forehead-slappingly simple: it reads and writes serialized data (really it's a "stringified" fragment of JSON) in the window.name property, a property which maintains state for the life of the window. No cookies required.
you can store up to two megabytes of data in window.name. As this(source: http://ajaxian.com/archives/whats-in-a-windowname [ajaxian.com])
property is available across page reloads it is a sort of session
2MB of data in a cookieless session? that's a little insane, but not impractical... at least we know the upper limit is stratospheric and unlikely to hamper our enthusiasm for using it.
However - and this is a BIG however - there are security concerns using this method, which Frank admits and warns us about. Unlike cookies, the window.name property is not just available to the domain that assigned the property. It's readable by any domain loaded in that window, whether it be your application or someone else's. Any open window can link (or be forced to open) any URL, and that window will still be named what it's named. Thus any data you drop into the window.name is ultimately readable by anyone, so take care not to put anything sensitive in there.
Another thing that makes it different from cookies: naturally the window.name disappears when the window is closed. Cookies persist longer. Thus this technique is only truly useful for extremely transitory data, like options or settings that only have meaning within the current window lifespan.
Despite these liabilities, the technique does have an apparent upside:
But in some aspects sessvars.js is safer than cookies: The content of window.name(source: http://www.thomasfrank.se/sessionvars.html [thomasfrank.se])
does not get sent to the server in the header request
Well, sure that is true. However I don't see this as being much of a concern; cookies are only sent to requests within the same domain, so situations where a developer would be concerned about cookies in the header are ... rare.
I'm not advocating that anyone use this technique. But it's a nifty trick to know about. Maybe it's a hammer waiting for the right nail to pass by.
Personally I think this technique might have some real potential for use in analytics, click tracking, conversion tracking, and ROI tools for referring traffic generation campaigns, where all the "action" almost always happens within one window lifespan.
So theoretically you could track across multiple websites
I already have one application in mind which is perfect for this technique - the hammer has found its nail - let's call it... an analytics itch that needs to be scratched. I'll be able to report back in a day or two whether it's working.
Let's say site X drops some data into window.name. Unless it's deliberately removed, it'll stay there for as long as the window's open as I browse other sites. In a way, it's like dropping a little secret message for any other sites who care to look for it - like slapping a post-it on the user's back as they pass through your site.
This would also be GREAT as a cookieless backup tracking system for affiliate programs. Drop your aff ID into a cookie, but also drop something in window.name - in case the user has cookies disabled, you have a backup system you can use to track the provenance of your traffic.
