Opened 6 years ago

Closed 12 days ago

Last modified 11 days ago

#11949 closed enhancement (wontfix)

Randomize Tor Browser Fingerprint

Reported by: mt2014 Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-firefox-patch
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

TorBrowser still can be easily fingerprinted:

  1. check your fingerprint ID here & copy it to notepad:

http://fingerprint.pet-portal.eu/
http://www.browserleaks.com/canvas

  1. Do whatever you can to delete your trace (dom storage, html5 storage, cookie, flash cookie, reinstall browser)
  1. check your fingerprint once more from above sites. 99% it will still be same!

Most advertising company loves this kind of static fingerprinting, so they can track their user. , especially by big company like google. I have many clients who experienced opening adwords account then for whatever reason their account is banned for life by google, then they open new account by using all new identity (brand new unrelated browser, new credit card identity with different name, new address, new internet connection, the only difference is using same computer), you know what happend? couple days later this brand new account banned because they know it is old user that they banned before. Sometimes I dont know how can they find out, but as far as I know this guys is really really good when fingerprinting everysingle user they have. the only failproof solution is also using completely new computer or using new virtual computer using VPN provider.

Static fingerprint like this also threatening small privacy browser like torbrowser & jondofox, if big companies feel that this privacy browsers a threat they can just easily blocked all access by this browsers using their fingerprint. User will fell it is browser's bug then change another browser. It happens with opera once. This opera browser was growing fastly couple years ago and it becoming a threat for google chrome growth, so google blocked all access to most google service by opera browser then recommend big 4 browser instead.

http://dev.opera.com/blog/google-browser-sniffing-and-the-open-web/

Now what happens? opera becomes google's bootlicker. Now they agree whatever google wants them to do. See all opera browser you will notice many google product is there now. Even opera now uses Google's Blink as their engine.

maybe TorBrowser should randomizing some browser data per browser session like using "Firegloves", "Random Agent Spoofer" & "IpFlood" addon? This asddon works by randomizing some browser data such as timezone, screen dimension, useragent, etc.

RAS also send fake "X-Forwarded-For" & "Via" Header (Usually used by transparent proxy to let the sites know the real ip address), if we send this fake header, the site will think that our real ip address is just a transparent proxy server.

Thank you for taking the time to read this.

Child Tickets

Change History (8)

comment:1 in reply to:  description Changed 6 years ago by gk

Component: TorbuttonFirefox Patch Issues
Priority: blockernormal
Summary: Randomize Browser Fingerprint..Randomize Tor Browser Fingerprint

Replying to mt2014:

TorBrowser still can be easily fingerprinted:

  1. check your fingerprint ID here & copy it to notepad:

http://fingerprint.pet-portal.eu/
http://www.browserleaks.com/canvas

  1. Do whatever you can to delete your trace (dom storage, html5 storage, cookie, flash cookie, reinstall browser)
  1. check your fingerprint once more from above sites. 99% it will still be same!

That's exactly the idea and not a bug: if we make it possible that all Tor Browser users look the same we have defeated the fingerprinting as no particular Tor Browser user may be singled out due to some deviation from the Tor Browser "norm". See again the current design documentation https://www.torproject.org/projects/torbrowser/design/#fingerprinting-linkability .

That said, there is research going on whether we can't defeat fingerprinting by randomizing properties as you suggest. So far, I am not convinced by the approaches and analysis yet.

comment:2 Changed 6 years ago by mt2014

For Single/Static fingerprint to work the userbase must be very very large. If not big company/government will just block access to that one fingerprint. Not hurting their income, its just very very very tiny market.

If you randomize your fingerprint with other big 4 browsers (with default setting), Big company cant just block you, if they do, they will also block very large userbase. which unlikely they will choose that route.

When speaking Anonymity static fingerprint will never gonna provide true Anonymity. Because every big company/government know how to block TorBrowser & Jondofox if they want.

Here's some prove:
-) all chinese user cant access anything when using jondofox and torbrowser, because its easily recognized and blocked by government.
-) user cant login/signup to getpocket.com using every single "true" privacy browser like dooble, torbrowser, jondofox)
-) you cant signup google adwords account using torbrowser, your account will be banned in no time.

true anonymity is "everything randomize" which means they dont know what browser you are using, or any info about you, because it keeps changing. you are like a ghost, they cant recognize/block you.

comment:3 Changed 6 years ago by erinn

Component: Firefox Patch IssuesTor Browser
Keywords: tbb-firefox-patch added
Owner: changed from mikeperry to tbb-team

comment:4 Changed 2 years ago by teor

Severity: Normal

Set all open tickets without a severity to "Normal"

comment:5 Changed 10 months ago by cypherpunks

we do suggest the opposite. Don't Randomize Tor Browser Fingerprint. Make all user look identical. Only gives you ability to be a needle in a haystack.

comment:6 Changed 12 days ago by gk

Resolution: wontfix
Status: newclosed
Last edited 12 days ago by gk (previous) (diff)

comment:7 Changed 12 days ago by gk

(Before we actually go that route we should have some hard data showing that randomizing is superior for our use-case)

comment:8 in reply to:  7 Changed 11 days ago by Thorin

Replying to gk:

(Before we actually go that route we should have some hard data showing that randomizing is superior for our use-case)

IMO, you don't need hard data - math alone can illustrate it perfectly :) You only need hard data to know how "bad" an existing metric is, and maybe experiments after. As long as the entropy is high enough, it's actually more effective IMO.

The question/problem is that the anti-fingerprinting measure taken needs to be decided based on what is being protected: e.g it would be silly to randomize language/locale (too complex, not very user friendly, etc) or to randomize the UA/platform (because these are already obtainable other ways, breakage, the entropy is too small). But randomizing something like canvas is arguably better than returning a white canvas - it produces less breakage and removes the tell-tale white canvas hash (not that TB is trying to hide that it's TB).

Generally speaking, spoofing to lower by using the most common value (or one value per platform) is the simplest fix, whereas randomizing is much more complex - and the implementation can lead to unintended leaks, information paradoxes, breakage etc.

That said: tor project has always taken the lower entropy route, but I just want to point out that randomizing should be considered in some cases. Because non-random means a stable metric can always be used against you (even where no entropy exists: e.g. oh, a white canvas, no service for you then), whereas randomizing should completely ruin it

  • take for example the script at #32861 where any change to the window size caused a hash change (I'm not saying to randomize window sizes - just showing how that script becomes unreliable)

It really depends on what is being protected and the pros/cons weight up (especially the maintenance and complexity), but imagine if canvas, audio, clientrects and screen (not inner) were always randomized - this would really wreck almost every script out there, and I'm all for that :)

One area I think randomizing should be considered is in clientrects: all those high precision measurements which keep coming up in FP PoCs

Note: See TracTickets for help on using tickets.