[tor-talk] Spoofing a browser profile to prevent fingerprinting

Mon Jul 28 20:34:56 UTC 2014

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thank you for your answer!

I've just thought a bit about various methods to prevent
fingerprinting browser profile (incl. UA/screen resolution/time
zone/fonts/etc.), and here is two ways I've found:

a) all tor-users have the same browser profile
b) all tor-users have random temporary browser profile

In my opinion our current strategy to reduce among all tor-users
fingerprintable differences is correct. In such case the only that can
 an attacker do to determine one user from other is their Tor IP
address, but if you will often change between them it becomes
impossible for the attacker.
And for variant b), it's much easier to do. A lot of users connect to
web-sites from one exit-relay and have the same Tor IP address, but
different profiles. So even if you will randomly generate new profile
every minute, you have your unique profile so the attacker can easily
determine: this actions made by different users. In contrary, when
everybody has the same profile, it's much harder to do.

About Referer: we shouldn't disable the Referer by default because
many sites rely on it, but I think we should add an option to the
TorButton settings list "Disable the Referer Header". How can I
contact TorButton developers or do it by myself?

On 27.07.2014 0:43, Sebastian G. <bastik.tor> wrote:
> Am 26.07.2014 um 20:14 Craw:
>> Hello everybody,
> 
> Hello,
> 
> you may want to read the design document of the TorBrowser [1].
> 
>> You know, there are some various methods of fingerprinting a 
>> browser. Plugins and plugin-provided information are still the 
>> most useful in uniquely identifying a browser, but there are
>> also some other information that can be used to fingerprint a
>> Tor user, like user agent, screen resolution, time zone, etc.
>> 
>> I think it can be helpful to spoof real browser profile to random
>> temporary one.
> 
> I think it has been suggested before.
> 
>> Each browser profile includes user-agent (browser name/version), 
>> platform (OS name/version), screen resolution, time zone
>> (depends on country of an exit-relay, so, perhaps, mismatch of it
>> can cause suspicion?). So, my suggestion is to generate random 
>> browser profile during each identity session, or randomly switch 
>> them after a chosen period of time has expired. By making this, 
>> some important info about users will be unreachable for an 
>> attacker and fingerprinting will be more difficult. Here's a
>> link on open-source repository of Firefox add-one which code we
>> can use for Tor Browser - 
>> https://github.com/dillbyrne/random-agent-spoofer
> 
> The idea of the TorBrowser is to make all users look alike.
> 
> For the user-agent the design doc [1] has the goal:
> 
> "Design Goal: All Tor Browser users MUST provide websites with an 
> identical user agent and HTTP header set for a given request type. 
> We omit the Firefox minor revision, and report a popular Windows 
> platform. If the software is kept up to date, these headers should 
> remain identical across the population even when updated."
> 
> I think "4.6. Cross-Origin Fingerprinting Unlinkability" covers
> it, for the most part, if not for everything.
> 
> I would think a random user-agent doesn't add anything to it. If I 
> see a Tor Browser user-agent with a Tor IP address now and 30 
> minutes later another (the same) Tor Browser user-agent with a Tor 
> IP address (either the same or another) it doesn't help me to 
> determine if the request comes from the same user. On the other 
> hand if I see a random user-agent with a Tor IP address now and 30 
> minutes later another random (different) user-agent with a Tor IP 
> address (either the same or another) I would guess that this isn't 
> any better than the former case.
> 
> With enough requests it might be that statistical differences
> occur and one could guess that the random user-agents belong to
> different users or that they a just one user.
> 
> That appears to be true for two users accessing the same website 
> over the same exit node at the same time. If they both have 
> different user-agents, they can be easily told apart.
> 
> Does anyone think I missed something?
> 
>> Also I suggest to: - forbid HTML5 Canvas by default 
>> (http://cseweb.ucsd.edu/~hovav/dist/canvas.pdf)
> 
> See "4.6. Cross-Origin Fingerprinting Unlinkability", specifically
>  "Fingerprinting defenses in the Tor Browser" Point 2.
> 
> Tor Browser returns empty canvas data, so it is not possible to be
>  fingerprinted on them. Tor Browser prompts the user, along with a
>  message about just having returned empty canvas data, for
> allowing or disallowing access to canvas data.
> 
>> - use only standard font set (can be used for fingerprinting)
> 
> "Fingerprinting defenses in the Tor Browser" Point 4.
> 
> Quote: "[...] we limit both the number of font queries from CSS,
> as well as the total number of fonts that can be used in a
> document with a Firefox patch. We create two prefs, 
> browser.display.max_font_attempts and 
> browser.display.max_font_count for this purpose. Once these limits 
> are reached, the browser behaves as if 
> browser.display.use_document_fonts was set. We are still working
> to determine optimal values for these prefs."
> 
>> - set network.http.sendRefererHeader value "0" by default (allows
>> sites to track referer, but some sites can be broken! add ability
>> to switch on/off referer?)
> 
> I'm not involved with development, but I'd opt for being able 
> disable referers.
> 
> The design document [1] says at "A.1. Deprecation Wishlist"
> 
> Quote:
> 
> "The Referer Header
> 
> We haven't disabled or restricted the Referer ourselves because of 
> the non-trivial number of sites that rely on the Referer header to
>  "authenticate" image requests and deep-link navigation on their 
> sites. Furthermore, there seems to be no real privacy benefit to 
> taking this action by itself in a vacuum, because many sites have 
> begun encoding Referer URL information into GET parameters when 
> they need it to cross http to https scheme transitions. Google's
> +1 buttons are the best example of this activity.
> 
> Because of the availability of these other explicit vectors, we 
> believe the main risk of the Referer header is through inadvertent 
> and/or covert data leakage. In fact, a great deal of personal data 
> is inadvertently leaked to third parties through the source URL 
> parameters.
> 
> We believe the Referer header should be made explicit. If a site 
> wishes to transmit its URL to third party content elements during 
> load or during link-click, it should have to specify this as a 
> property of the associated HTML tag. With an explicit property, it 
> would then be possible for the user agent to inform the user if 
> they are about to click on a link that will transmit Referer 
> information (perhaps through something as subtle as a different 
> color in the lower toolbar for the destination URL). This same UI 
> notification can also be used for links with the "ping" 
> attribute."
> 
>> Let me know about your thoughts,
> 
> Thank you for your thoughts and your input on how to improve the 
> Tor Browser.
> 
>> Looking forward to hear from you, Pavel.
> 
> I hope you get some more feedback. Especially from people working 
> on the Tor Browser.
> 
> Best Regards, Sebastian G.
> 
> 
> [1] https://www.torproject.org/projects/torbrowser/design/
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.21 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJT1rPtAAoJEHoSQ4zXvBr4MMQH/jFuo3NOtjMzB4p5kd6PtJWz
yvcI71pc6mIbiFK0fEMRdtxQ/DYYN0wgqpO0Nzqncag/c8hAasv6ETsaGGALyPeY
Wk7q2S0WBDj9QaQHqN3aODTDa/fIBEUzDBz7nfXkV0lCV+qyKkrzi7NoVXzwHELk
BYqEisw8XewwzmjPWML+MOqlxFR8XgdPtJZMA4pRl10HhZw1Z+e9Y5BqH77uJZpN
TrSToBwah+zScYYznITbx7w/jRQqIUdZULfaiB1LYWN2w77fwRfEg1IvSPIHTb5N
6gitaT23SXWKkJp1SgbykL0yU4jrSince/syEqemCMfuk528EDh7x3Hpo4B7H9M=
=ps5b
-----END PGP SIGNATURE-----