> Randomization, or some one click equivalent, is the only real option here when usability is considered; the manual effort each session is undesirable at the very least :)
The problem you have there, is what to randomize, and how to do it in such a way that it does not itself become identifiable.
To use an example, think about when you run cover traffic (whether over Tor or a VPN), the initial temptation is to have random levels of data travelling over the link. The problem there being it's not a 'natural' looking flow of data when you analyse it. So when you use the link, your natural usage is identifiable in the analysis.
So you go for something more 'natural', but natural's hard to fake, so your cover traffic has an identifiable set of patterns, meaning on analysis you can discount it and still tell when the tunnel is being used for real traffic.
When we're talking about making the browser unidentifiable as TBB, the very act of having something in the fingerprint that changes to prevent correlation between sessions provides an avenue by which it can be identified as TBB:
Let's say you override reported screen width so it lies, and then use TBB to sign in to (sake of example) Facebook. Every time you start a new session and sign in to Facebook, your screen size is going to be different. That's very unusual. User's screen sizes will change from time to time (because they're in a window rather than full-screen, or on a laptop instead of a PC) but to be different every time?
What about if you're signed in to FB in one tab, and browsing news in another. The news page has a Like button on it, and Facebook get a completely different screen size reported. You might just have the news on fullscreen, and FB windowed, but again, for it to happen every time is an unusual pattern.
A bit of research would soon tell them you're using TBB even if they hadn't thought to see if the traffic was coming from an exit node.
> Making people blend into the crowd of regular internet users is best but only if we resolve the traffic source; i.e., Tor exits.
That's quite an issue to solve though. Even if we assume that the IP's of tor nodes weren't being published anymore, analysis of traffic patterns on a busy site would likely soon let you work out the IP's of some exits.
Granted, you wouldn't immediately know whether those sources were Tor exits or simply proxies being used by multiple users, but finding out wouldn't be impossible. A determined adversary wanting to map out Tor exits could simply initiate a lot of connections via Tor and keep a record of where the other end (under their control) sees connections come from.
Not as accurate as downloading the relay list, but depending on your aims you wouldn't need 100% coverage, so in the absence of the list it'd probably do. It raises the cost of identifying Tor exits, but only so long as the resulting list isn't then published (and kept up to date).
As others have said though, the aim isn't to hide that you're using Tor from your destination, and successfully doing so would (IMO) be a pretty non-trivial task