Concept

First: do you already understand the Javascript-free variant of the CSS History hack? No? Go read this first. Alrighty then...the concept is simple: generate a user ID and transmit the individual bits of this ID via the CSS History hack. For example, these URLs could be used to represent a 32-bit user ID:

http://www.example.com/userid/bit0
http://www.example.com/userid/bit1
http://www.example.com/userid/bit2
...
http://www.example.com/userid/bit30
http://www.example.com/userid/bit31

Thus, the user ID is composed of the set of URLs the specific user has "visited". For example, to transmit the user ID 4711 the following URLs must be invoked: ".../userid/bit11" (4096), ".../userid/bit8" (512), ".../userid/bit5" (64), ".../userid/bit4" (32), ".../userid/bit2" (4), ".../userid/bit1" (2) and ".../userid/bit0" (1) -- for the mathematically challenged: 4711=4096+512+64+32+4+2+1.

Implementation

I've decided to implement this demo in Neko (running on mod_neko inside Apache). All data is stored in a MySQL database. Only a couple of files are required for this:

index.n(eko)
css.n(eko)
bit.n(eko)
dummy.n(eko)

The index.neko shows the main page and determines, whether the user has visited any of the "bit" URLs. For this, it contains the corresponding URLS and also a CSS reference (css.neko). The index.neko generates those parts of the HTML page, flushes it and puts itself to sleep. In the meantime, the browser receives and parses the (partial) HTML document, resolves the CSS include (@import) and invokes the "bit" URLs for fetching the CSS background images for any already "visited" links. The CSS induced loading of background images is handled by bit.neko, which simply logs the specific requests in the database. After a while (this is sort of sketchy) the index.neko script wakes up and looks in the database to figure out which of these "bit" URLs the user has already "visitied". In case the user has not "visited" any then it displays a message stating that the user is unknown; otherwise it calculates the user ID by (the combination of all loaded "bit" URLs) and looks up the stored username in the database under that user ID.

The last thing to talk about is user registration: in case index.neko determines the user is unknown (no logged invokations of "bit.neko") it shows a HTML form asking for a name. This form is submitted to index.neko and in this invokation it stores the username in the database and determines the user ID via auto_increment. This user ID is split up into its bits and for each set bit an <iframe> tag including the corresponding "bit" URL is generated - that's the initial user "registration".

I haven't been quite honest: there is a lot of technical grunge happening below the described "surface". If you really must know, click here.

Sources

Not just yet.