[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[tor-dev] torbutton user agent update scheme idea



Sorry for always picking random stuff from the volunteer page, but having read this,

<quote>
Programs like Torbutton aim to hide your browser's UserAgent string by replacing it with a uniform answer for every Tor user. That way the attacker can't splinter Tor's anonymity set by looking at that header. It tries to pick a string that is commonly used by non-Tor users too, so it doesn't stand out. Question one: how badly do we hurt ourselves by periodically updating the version of Firefox that Torbutton claims to be? If we update it too often, we splinter the anonymity sets ourselves. If we don't update it often enough, then all the Tor users stand out because they claim to be running a quite old version of Firefox. The answer here probably depends on the Firefox versions seen in the wild. Question two: periodically people ask us to cycle through N UserAgent strings rather than stick with one. Does this approach help, hurt, or not matter? Consider: cookies and recognizing Torbutton users by their rotating UserAgents; malicious websites who only attack certain browsers; and whether the answers to question one impact this answer.
</quote>

I think the best answer is simple, although a little more than trivial to implement.

If you want to anonymize the user agent, you need to mimic the user agent changes made by normal users across the web, and I'm positing that in any statistically significant sample of web users, the behavior will be similar and simple enough on nearly all orders of magnitude available, i.e., normally distributed in any analytical dimension.

Think about the natural evolution of a typical web user's user agent. What are the factors that will result in a change of user agent?

1) A user may have more than one browser that they use on the same computer,
2) they may use the web on more than one device (phone, tablet, laptop, desktop),
3) and typical, stochastic upgrade patterns.

For (1) and (2) there is not much torbutton could do to coordinate reasonable obfuscation among multiple version, logical, space, and time separated instances without way more effort than would be profitable. In fact, (1) and (2) ought to naturally provide most if not all the anonymizing that can reasonably be accomplished from torbutton's perspective without any action at all on torbutton's part.

For (3), though, there is something that could be done by torbutton. Some factors to consider in constructing a stochastic user agent updater are:
- which browsers automatically upgrade themselves?
- which browsers bother the user to upgrade?
- what are the typical user response patterns towards browser upgrades?

Remember, we're thinking about a single browser on a single system. If there are things going on for that user external to this (reinstall windows, upgrade ubuntu, get a new computer, etc.) those effects are already accounted for by (1) and (2).

Some investigative questions/statements to lead an analysis on this could be something like:

'what is the distribution of browsers for human web users?'
'what is the distribution of systems and system versions for human web users?' 'what are the significant correlations on the cartesian product of these two dimensions?'
'how do the browser versions in this product space evolve through time?'
...
'2/3 of firefox users are on windows and their upgrade habits follow a temporal distribution that is a spike followed by an exponential decay of order 2.3', '0.8 of the remaining firefox users are on linux and their update habits are dominated by package management systems',
etc.

Then, upon finding the most significant trends in browser update patterns, construct a mechanism for torbutton that mimics them on a per user basis: Once a user installs torbutton, it samples (selects) a browser from the distribution of browsers and then follows that browser's typical upgrade pattern. The problem with this idea, I guess, is that torbutton will have to phone home to find out when browser updates are adopted by users so that it can make its change at the expectation value or whatever.

The goal being to distribute torbutton users according to the distribution of all web users among all user agents, you must first find out what that latter distribution is and how it is likely to evolve. This second part is not so bad as it seems because I'm guessing that some forward standard deviations of the expectation value in the temporal sense will occur late enough after the browser update that torbutton can push it out to most installed instances (it's not going to happen before, causality and all).


Justin
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev