[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-talk] Spoofing a browser profile to prevent fingerprinting
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/
--
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk