Well the paper I linked to actually showed that the technique you mentioned (called traffic morphing) is good enough to prevent website fingerprinting attacks. I imagine it is effective, to various degrees, to reduce the effectiveness of interpacket watermarking attacks as well. But it isn't enough to save the day by itself (just like invariant traffic characteristics isn't enough to save the day by itself, it is just one part of the puzzle). I will need to read more papers on traffic morphing to come to any set conclusion on it, it certainly is useful for a variety of things, but it isn't the route I want to go in any case, and it isn't going to be more effective than interpacket timing uniformity. If your flow is totally morphed they cannot do that. The paper I linked to talked about traffic classifiers, which are used for website fingerprinting and other things. Morphing traffic helped prevent classifier attacks, as their paper shows. So if a relay loads google, and then record the exact stream characteristics, and then when your watermarked traffic passes through them they hold it long enough to modify it so that it looks like the stream they loaded from Google, it should destroy the watermark in the stream and actually make it look like you are loading Google if somebody is running a classifier against that individual stream. But adding random interpacket delays to try to destroy the watermark will be more difficult than morphing the stream to look exactly like another stream, and it has been shown already that attempts to do this in low latency have failed to remove interpacket timing watermarks. The difference is between traffic morphing (making one stream look exactly like another previously seen stream) and adding random jitter (randomly delaying packets for small amounts of time). I think if traffic is perfectly morphed it destroys interpacket timing watermarks, but randomly added jitter can usually be filtered, especially if you want to maintain low latency. Because it only takes identification of a very few bits of information to identify a watermark. Even if it is horribly mangled, the few bits of the watermark that get through will betray you. Of course if you morph one stream to have the exact characteristics of another, that will destroy the watermark. But if you just add random noise, that will not usually be enough to save the day and it can often be filtered, just like cryptographic timing attacks can be slowed down by adding random delays to crypographic functions but the random delays can still be filtered. The solution with cryptographic functions is to make them constant time, ie: uniform time to complete regardless of input, the solution with traffic is to make it uniform or to morph it to look exactly like some other traffic. If you perfectly randomized the interpacket timing characteristics it would work perhaps, I will need to try to find some paper on this, but generally you don't want to add noise to gain security, because noise can often be filtered but uniformity cannot. The only time you would want to add noise as your primary security technique, would be in cases where adding noise is required to obtain uniformity. Most of the research I found on traffic morphing is to counter classifiers not to counter watermarks, but I imagine it will work for either. Tor is hopefully a lot more effective than public WiFi at hiding identifies. Tor hidden services have actually been notorious for being the least secure part of Tor.