Huh, I always thought that Tor breaks up traffic in a random, but deterministic (not data dependent) way - sometimes joining data from two packets into one netw

Huh, I always thought that Tor breaks up traffic in a random, but deterministic (not data dependent) way - sometimes joining data from two packets into one network packet, sometimes splitting packets and holding data for a while [x]. That's how I explained the jitter to myself. Sometimes a connection would be really fast, and sometimes it would hang on a single packet for hundreds of ms. Seems I was mistaken. In this case, it would have helped a bit, since an attacker would not have seen the characteristic staccato of the reCAPTCHA exchange. They would have seen a few kB in either direction, in 40-100 packets, over a period of a few seconds. If the implementation is clever, on end would even have a different signature than the other. At least this is something I would have included in Tor. Now that I think about it, randomly introduced delays (from the outside) might actually be a technique to deanonymize users.... ([x] You'd generate packet sizes and minimum transmission times from a known seed. First packet is 501 B, 24 ms later a packet of 2048 B, then 15 ms later one of 1718 B, and so on. If there is not enough data after a grace period, pad with junk. If you constantly need more time to send packets than allowed, or need to pad, then adjust the model. Also choose the model to match regular traffic if possible. Disclaimer: I'm just making this up on the spot and am no expert, but it seems plausible and obvious to me.)