Ever since the Web went commercial back in the mid ’90s cookies, HTTP’s sorry excuse for connection persistency, have been used, abused, vilified, and reviled.
Cookies, as I’m sure the majority of readers of the Network World Web Applications Alert newsletter are aware, are small chunks of data that a Web server can request a Web browser to save on a client machine and retrieve whenever the client using the same browser reconnects to that same Web server.
In other words, cookies provide a way for a Web server to track a browser user between connections and sessions and it is the possibility of users losing privacy that has caused much of the furor over the technique. Some users block cookies completely, others selectively allow cookies for specific sites, while other users accept cookies but occasionally or routinely delete them all.
The first user group, those who block all cookies are fairly rare because the user experience of many Web sites (aspects such as login persistency, customization, and in a few rare cases, being able to access the site at all) requires the feature to be available.
Users who block all but certain sites from uses cookies are equally rare but those users who “nuke” their cookies are much more common. There’s also the possibility that cookies can be deleted by any number of unpredictable client-side events. In short, cookies lack reliability.
For Web application designers this lack of reliability is a problem. The essence of effective e-commerce is to know as much as possible about your prospects and customers so being able to identify them between sessions is crucial.
Now it is true that every end user browser can be profiled and, according to Electronic Frontier Foundation’s Panopticlick, every browser they have tested – a total of 1,196,366 so far – has a unique “fingerprint” (the combination of browser configuration details including browser type and version, installed plugins, fonts available, time zone, screen resolution and color depth, and system details such as host operating system and version). The problem with this profiling technique is that it is complicated and new enough to be pretty much unexplored.
So, rather than creating new client persistence technologies why not improve on what we already have? That’s exactly what one Samy Kamkar has done with a free JavaScript script called Evercookie.
What Kamkar has done is to create a system that makes cookies incredibly “durable”: ” evercookie is a javascript API available that produces extremely persistent cookies in a browser. Its goal is to [make it possible to] identify a client even after they’ve removed standard cookies, Flash cookies (Local Shared Objects or LSOs), and others.”
Kamkar’s system ensures that when a new cookie is created it uses not only the standard HTTP cookies but also Flash Cookies, cookies implemented as RGB values of auto-generated, force-cached PNGs using HTML5 Canvas tag to read pixels (what are now cookies), cookie-like data in the browser’s Web History, HTTP ETags, and Internet Explorer userData storage, as well as HTML5’s Session Storage, Local Storage, Global Storage, and database storage via SQLite.
Future cookie mechanisms planned include Silverlight Isolated Storage, window.name caching, and “using Java to produce a unique key based off of NIC info”.
Because the various cookies exist in different client-side subsystems they are unlikely to all be deleted at once so when the page is reloaded the script runs again and if only one of the cookies still exists on the client, the script will recreate all of the other cookies!
Evercookie is almost fiendishly clever and for Web applications developers, Evercookie makes it possible to improve client state persistence and client “trackability.” For browser users, the script is another indicator of just how hard it is to avoid being tracked on line.
