>( or at least a site where you can cause JS to run; such as an advertisement )

So you cannot find the identity of a tor user.

* Either the TOR user is a 'newbie' (no offense), and he will use the tor package wich come with a version of firefox where JS is disabled by default

* Either he is a seasoned user and knows that disabling JS while using TOR is mandatory.

I don't know the exact parameters of the competition, but I doubt pretty strongly if the solution is allowed to manipulate the targeted user's behavior, and, oh, by the way, install a high speed listening device on the trunk of every ISP in the world.

If you have to know already which ISP the suspected user is using, you're not really finding the user, you're just confirming their identity.

And as others have pointed out, running with JS enabled is a vulnerability. If the user is that careless, it's probably easier to get them to load a particular file over plain HTTP and just listening to requests for that file.

I assume a Tor user with js turned off would be immune to this?

I don't think so. What you could do is have the webserver set up chunked encoding on a resource (say an image) and vary the size of the chunks for each user.

I thought Tor padded all packets to obscure payload size. Is this not true, or does this method work in some other way I'm not grokking?

I wonder if something similar could be done with detecting specifically sized images?

You're all making this much too complicated. Who needs the client to make multiple requests when you control the server? Client does "GET /" and the server starts sending a large index.html using irregular sized packets at specific intervals.

But suppose we broke it, now we have to fix it, right? Start padding everything to power-of-two size boundaries with a minimum of 16. Or if that would make Tor traffic too identifiable, then instead add random()%packetsize padding to each packet. Either would reduce the number of detectable packet sizes below a 1500 byte MTU to 8 at the cost of less than doubling the bandwidth consumption.

I think this will be a bit harder, as you don't really have control in what order the images are being loaded. They could be loaded in parallel for example. If you try to circumvent it by adding delay's on the server side you quickly block the browser as you will reach the maximum amount of parallel connections.

Even simpler: create a website which responds in a recognizable way, serially rather than concurrently. If person A received recognizable packet P at time T, and the site was serially serving that connection at time T to recognizable-but-pseudonymous person X, then A==X.

> 2. Know which ISP the user is on

How easy would it be to do this (even with JS on)?