[tor-talk] Tor Weekly News — October 23th, 2013

[Joe Btfsplk]

On 2013-10-24 10:26, Joe Btfsplk wrote:
>> On 10/23/2013 8:04 AM, Lunar wrote:
>>> Tor Weekly News                                       October 23th,
>>> 2013
>>>
>>> “some circuits are going to be compromised, but it’s better to
>>> increase your
>>> probability of having no compromised circuits at the expense of also
>>> _INCREASING THE PROPORTION_ of your circuits that will be compromised
>>> if
>>> any of them are.”
>> I read the paper -  slept since then.
>>
>> Would someone please clarify this general statement & that part of
>> the design concept?
>>
>> The statement in https://www.torproject.org/docs/faq#EntryGuards is a
>> bit confusing.
>> /"But profiling is, for most users, as bad as being traced all the
>> time: they want to do something often without an attacker noticing,
>> and the attacker noticing once is as bad as the attacker noticing more
>> often."/
>>
>> How is being "noticed" once, perhaps for 15 seconds,  visiting one
>> website - that yields very little info, better than being noticed many
>> times, over a long period?
>>
>> Is it that once an adversary correlates your machine (fingerprint) w/
>> an originating IP & a Tor entry / exit, they could theoretically ID
>> you?
>>
>> If so, doesn't that beg the question of why does TBB keep the same
>> browser fingerprint from entry to exit?
>> Why (have or allow TBB to) keep the same fingerprint over long
>> periods, even if some of that data is spoofed, rather than TBB
>> randomly change (spoof) the fingerprint, from end to end on one
>> circuit and / or over time?
>>
>> One big problem as I understand, is a Tor user (specific browser on
>> specific machine) is potentially identifiable from entry to exit, by
>> having the same fingerprint.
>> Why not change the fingerprint?  Put on a "hat & glasses" or
>> "different colored coat" part way through the circuit?  TBB already
>> spoofs SOME browser data - it just remains constant.  Maybe other
>> tracking issues completely over shadow this.
>>
>> Even if having TBB change fingerprints along a circuit and / or at
>> other times doesn't solve all problems, could it be a *part* of
>> reducing fingerprinting and / or tracking?
> On 10/24/2013 1:21 PM, author at anonymousbitcoinbook.com wrote:
>> By changing the browser fingerprint, do you mean altering the HTTP
>> request headers, such as the User-agent? You'd need to decrypt SSL/TLS
>> traffic in order to modify the headers of any request sent over SSL/TLS,
>> so that limits you to plaintext HTTP traffic.
>>
>> You COULD alter HTTP request headers at each hop, but let me raise a
>> potential objection: A considerable number of websites return different
>> HTTP responses based on the contents of HTTP request headers, so you'd
>> be potentially mucking up the deterministic output of web applications.
>> A common example is returning a different version of a website when the
>> User-Agent indicates a mobile device. One obvious part of the browser
>> fingerprint is unique cookie values, such as those set by third-party ad
>> domains. Cookies would be one of the trickiest to modify, because they
>> are integral to the function of the vast majority of websites, and it
>> would be difficult when to mutate a cookie value without negatively
>> impacting the function of the web application.
>>
>> -Kristov
Thanks.  I moved your top post to underneath my post.

Request header is only one of many things that would (may?) make up 
browser fingerprints (IIRC).  Many other data could be changed. Whether 
they could be changed in transit on one circuit & if it would be *any* 
benefit, is the question.  I'm not talking about changing browser 
fingerprint data that would "mess up" the returned content (for mobile 
device, etc.).  Maybe this isn't possible, but worth asking.

IF... the request header can NOT be changed, or requested & returned 
data won't work AND if the request header *alone* is enough for very 
sophisticated adversaries to track users end to end, then all bets may 
be off.

If request header is all adversaries need, then the constant talk of 
/"don't change [this] in TBB, or your browser fingerprint will make you 
(more) unique,"/ is pointless.  So, I assume that request headers aren't 
everything, for tracking / fingerprinting.

If TBB users allow 3rd party cookies (& some other actions), they 
probably have other concerns & fingerprinting may be a moot point for 
them.  One assumes there's a certain point that preventing TBB users 
from shooting themselves in the foot is impossible.