The article linked to by slashdot does not fit the technical aptitude of many of the readers. It lacks on details. Fortunately, it does link to the actual 15 page paper. The official page link with abstract is here. The full 15-page text is available in PDF.
With regards to your question about accuracy, here is a snippet from the actual paper(PDF)
To understand the effects of topology and access technology on our skew estimates, we fixed the location of the fingerprinter and applied our TCP timestamps-based technique to a single laptop in multiple locations, on both North American coasts, from wired, wireless, and dialup locations, and from home, business, and campus environments (Table 3). All clock skew estimates for the laptop were close-- the difference between the maximum and the minimum skew estimate was only 0.67 ppm. We also simultaneously measured the clock skew of the laptop and another machine from multiple PlanetLab nodes throughout the world, as well as from a machine of our own with a CDMA-synchronized Dag card [1, 9, 11, 17] for taking network traces with precise timestamps (Table 4). With the exception of the measurements taken by a PlanetLab machine in India (over 300 ms round trip time away), for each experiment, all the fingerprinters (in North America, Europe, and Asia) reported skew estimates within only 0.56 ppm of each other. These experiments suggest that, except for extreme cases, the results of our clock skew estimation techniques are independent of access technology and topology.
This is an incredibly accurate and precise method of verrifying if the computer is the same.
Some people have also mentioned NTP subverting this method. Here are a coupole of key quotes about NTP.
For example, default Windows XP Professional installations only synchronize their system times with Microsoft's NTP server when they boot and once a week thereafter. Default Red Hat 9.0 Linux installations do not use NTP by default, though they do present the user with the option of entering an NTP server. Default Debian 3.0, FreeBSD 5.2.1, and OpenBSD 3.5 systems, at least under the configurations that we selected (e.g., "typical user"), do not even present the user with the option of installing ntpd. For such a non-professionallyadministered machine, if an adversary can learn the values of the machine's system clock at multiple points in time, the adversary will be able to infer information about the device's system clock skew...
Additionally, the method described can be used with the TCP timestamps option which
for popular operating systems like Windows XP, Linux, and FreeBSD, a device's TSopt clock may be unaffected by adjustments to the device's system clock via NTP. To sample some popular operating systems, standard Red Hat 9.0 and Debian 3.0 Linux distributions2 and FreeBSD 5.2.1 machines have TSopt clocks with 10 ms resolution, OS X Panther and OpenBSD 3.5 machines have TSopt clocks with 500 ms resolution, and Microsoft Windows 2000, XP, and Pocket PC 2002 systems have TSopt clocks with 100 ms resolution. Most systems reset their TSopt clock to zero upon reboot; on these systems i[Ctcp] is the time at which the system booted. If an adversary can learn the values of a device's TSopt clock at multiple points in time, then the adversary may be able to infer information about the device's TSopt clock skew, s[Ctcp].
Paraphrasing, The article says that this technique can be used by websites, Carnivore-like apps, anybody between you and the computer you are communicating with, banner-ad companies and ISPs (think comcast forcing you to not use a NAT).
This is an incredible, and incredibly scary, way to track a physical computer. Doubtless, many security reforms will become prevelant. Unfortunately, since timestamping ICMP, TCP, etc. is very standard in the way it operates, it may take some time to implement methods to eliminate these clock skews. If you are keen on details, this article is full of them. Read it.