I read Jeremiah's post about tracking users without cookies and had a conversation with him about it and how ad services companies could track users when cookies are not available. While the Basic auth method works it will only work with firefox since IE has disabled this ability after years of being abused by phishers/fraudsters. Recently I had the opportunity to learn more about machineid products and the various methods in which they operate. One popular method involves setting a cookie and the other involves gathering of 30 or so machine information points. In a nutshell they gather 30 or so pieces of information to identify your machine and compare it to a known list of your 'trusted machines'. This includes things such as browser version, plugin versions, ip, etc.... If you've ever used bank of america for you know that the site knows who you are when you login from the same machine and performs additional challenge responses when you try logging in from another one. For the context of this post I won't get into tracking when components are upgraded and how that comes into play.
I started thinking about this from the perspective of an ad company wishing to track users when cookies where disabled. While you can utilize sessionid tracking in urls on the same site, carrying this information over from sitea loading an ad, to siteb loading an ad isn't possible (without a cookie). However combining some of the ways machineid technologies work would allow for some tracking. From the context of an ad company they would want to know what sites hosting their ads you've visited.
You could grab those checkpoints in a similair fashion to the machineid technologies, and send them off to an ad server over ssl in a query string (Disclaimer: sensitive urls in GETs are a bad idea!). If example.com hosts ads from adserver.com the code in example.com could fetch adserver.com code to first gather this info, dynamically generate a url and css history theft to see if that uniq user has visited the specific adserver.com url. If they had visited it then the user had loaded an ad from adserver.com in the past. At that point additional JS could fire performing a request to adserver.com with the name of the URL being visited or obtain this information via a referer header.
Next the user visits cnn.com it also has the same code/src include, generates the same url, css history theft compares then continues doing the same thing. The adserver company now can track without cookies which sites the specific user has visited regardless of browser or IP.