Create our own instance of Panopticlick
We have issues with how EFF's Panopticlick is run. It has inherent bias against any change from established norms, even if that change is in the direction of uniformity amongst a population.
See for example legacy/trac#4810 (moved).
As an alternative, perhaps we should set up our own instance of Panopticlick to measure the variance among TBB users?
We could then add our own fingerprinting tests to this site as we see fit.
Activity
added TorBrowserTeam201801 in Legacy / Trac component::applications/quality assurance and testing in Legacy / Trac owner::boklm in Legacy / Trac parent::5292 in Legacy / Trac priority::very high in Legacy / Trac resolution::fixed in Legacy / Trac severity::normal in Legacy / Trac sponsor::4 in Legacy / Trac status::closed in Legacy / Trac tbb-fingerprinting in Legacy / Trac type::project in Legacy / Trac labels
pde: Actually, perhaps there should be some kind of per-useragent Panopticlick dropdown query interface? That would also allow the major browser vendors to attempt to instill uniformity amongst their userbase, too. It would also solve the "But we just fixed that fingerprinting bug in our latest major release, and now our users think we're worse off?" paradox.
Trac:
Cc: pde, runa to pde, runa, g.koppen@jondos.de-
Yes, at this point it is way more useful to allow web browsers to create their own tests and to evaluate defenses.
We don't need your existing database full of user data (in fact, I think most sane people will tell you not to publish that). We just want the schema + source code dumped at a url somewhere. We're going to have to rely on the community for this one for at least the next few months anyways.
If we're lucky, maybe someone will take the tarball and run with it on their own VM or something so we can start testing against a clean instance populated only with TBB data.
I think it's important to do it as soon as possible.
Trac:
Priority: major to criticalReplying to pde:
Open sourcing panopticlick is something I've been thinking about doing for years. While there are concerns with it, the cat was out of the bag before we even did the project.
Any updates on that? Just publish the code. Don't publish the database.
Replying to cypherpunks:
I think it's important to do it as soon as possible.
Please don't mess with the priority, just as you did in legacy/trac#6146 (closed), because you personally care about this issue.
I personally think that legacy/trac#8312 (closed) is most dangerous for most Tor users at the moment, legacy/trac#8170 (moved) is a simple and powerful attack and legacy/trac#3688 (closed) should be done yesterday already.
What I want to say, from all the different very important things to do, it's difficult to get started somewhere and get something done in an acceptable way.
Thanks for reporting bugs, anonymous user. Other things you can do is learning to code and help fixing the issues, paying others to fix it or to learn more about all these things, summarize and publish (papers, news pages) so the awareness for these problems increases. (At the moment still "Tor is fine and just use Tor with normal Firefox" still spreads, while critical issues are still outstanding.)
Trac:
Cc: pde, runa, g.koppen@jondos.de to pde, runa, g.koppen@jondos.de, adrelanos@riseup.net-
Replying to pde:
Open sourcing panopticlick is something I've been thinking about doing for years.
pde: What is the state here? Is this going to happen soon?
Trac:
Cc: pde, runa, g.koppen@jondos.de, adrelanos@riseup.net to pde, runa, g.koppen@jondos.de, adrelanos@riseup.net, arthuredelstein@gmail.com
Trac:
Username: qSKvY
Cc: pde, runa, g.koppen@jondos.de, adrelanos@riseup.net, arthuredelstein@gmail.com to pde, runa, g.koppen@jondos.de, adrelanos@riseup.net, arthuredelstein@gmail.com, tD66BSHWU@gmail.com-
Replying to cypherpunks:
browserspy.dk provided the code for Panopticlick, and offers a number of useful tests. Contacting them to discuss a partnership/setting up a new database based on their tests might be a good idea.
Thanks.
Trac:
Username: feverDream -
I've started a project called Libre-Panopticlick. It's available here: https://code.google.com/p/libre-panopticlick/ It's written in Java and is currently in a functional state, however it could use a bit of polish. If anybody has any suggestions for new fingerprint tests I'd be interested to hear them.
Trac:
Username: qSKvY -
The short answer is look through: https://trac.torproject.org/projects/tor/query?keywords=~tbb-fingerprinting
-
I've been working for a while on my fingerprinting website, Libre-Panopticlick (name subject to change when a better one is thought up; suggestions are appreciated). It's resembles Panopticlick and AmIUnique except that it has a few tests designed specifically for Tor users, based on Tor trac tickets. Those are:
- Whether the client is using Tor. Checked by performing a TorDNSEL request on the client / server combo.
- The time difference between the client and server in minutes.
- The output of toLocaleString() called on the UNIX epoch. The output of this differs based on browser locale, timezone, and browser, and has been confirmed to differ between instances of the Tor browser running on Linux and Windows.
- The output of Math.tan(-1e300), which differs based on operating system and reveals the underlying operating system that the Tor browser is being run on. This leaks the underlying platform that the TBB is being run on. For instance on a 64bit Linux machine it produces the value -1.4214488238747245 and on a Windows machine it produces the value -4.987183803371025.
At the moment it's in workable order and ready for at least a beta test. I'd like to get an initial instance of it set up and running within the next two weeks. I can provide hosting but I was wondering whether, when it's set up, I could get the Tor Project to direct some traffic towards it, since it was designed with the Tor project in mind.
Trac:
Username: qSKvY -
Replying to qSKvY:
I've been working for a while on my fingerprinting website, Libre-Panopticlick (name subject to change when a better one is thought up; suggestions are appreciated). It's resembles Panopticlick and AmIUnique except that it has a few tests designed specifically for Tor users, based on Tor trac tickets. Those are:
- Whether the client is using Tor. Checked by performing a TorDNSEL request on the client / server combo.
- The time difference between the client and server in minutes.
- The output of toLocaleString() called on the UNIX epoch. The output of this differs based on browser locale, timezone, and browser, and has been confirmed to differ between instances of the Tor browser running on Linux and Windows.
- The output of Math.tan(-1e300), which differs based on operating system and reveals the underlying operating system that the Tor browser is being run on. This leaks the underlying platform that the TBB is being run on. For instance on a 64bit Linux machine it produces the value -1.4214488238747245 and on a Windows machine it produces the value -4.987183803371025.
At the moment it's in workable order and ready for at least a beta test.
Exciting. Do you have a link to the code you are using for it? And one where it is running? You might as well be interested in https://lists.torproject.org/pipermail/tor-dev/2014-March/006486.html where we discussed things around Panopticlick more or less recently.
I'd like to get an initial instance of it set up and running within the next two weeks. I can provide hosting but I was wondering whether, when it's set up, I could get the Tor Project to direct some traffic towards it, since it was designed with the Tor project in mind.
What do you have in mind if you are saying "direct some traffic towards it"?
-
Replying to gk:
Replying to qSKvY:
Exciting. Do you have a link to the code you are using for it? And one where it is running? The code can be found at https://github.com/qqTYXn7/browserprint The server side stuff is written in Java and it uses MySQL. When it's up the site will probably be running at http://browserprint.info Sadly due to issues getting ethics clearance the site won't be up for at least a couple more months and I won't have much time to work on it in the mean time.
People who are interested may also want to check out https://amiunique.org as their code is also open source and they have more tests than Panopticlick (nothing Tor specific though).
You might as well be interested in https://lists.torproject.org/pipermail/tor-dev/2014-March/006486.html where we discussed things around Panopticlick more or less recently.
Thanks. That email gives me some ideas, such as creating testing for already patched vulnerabilities.
I'd like to get an initial instance of it set up and running within the next two weeks. I can provide hosting but I was wondering whether, when it's set up, I could get the Tor Project to direct some traffic towards it, since it was designed with the Tor project in mind.
What do you have in mind if you are saying "direct some traffic towards it"? I mean, for instance, a mention in the Tor blog, or in the Tor Weekly News.
Trac:
Username: qSKvY -
i think it should not only be directed towards tor users. it should have 2 modes. one compares the browsers with all other browsers like panopticlick and the other compares it to how torbrowser should look like with normal settings. this could help not only users but also developers and researchers because it can be checked if addons or plugins change the fingerprint or if a new version of firefox reintroduces old fingerprints. and finerprints that only occur in unusual circumstances can also be detected with a large userbase. it can also be useful to compare torbrowser to other anonymizing browsers and private browsing modes of mainstream browsers.
data storage should be optional and the user should be given the option to make a bookmark for his fingerprint for later comparison and the option to download the report as textfile.
Trac:
Username: elypter -
Replying to elypter:
i think it should not only be directed towards tor users. it should have 2 modes. one compares the browsers with all other browsers like panopticlick and the other compares it to how torbrowser should look like with normal settings.
Can you elaborate on what you mean by "compares it to how torbrowser should look like with normal settings"?
data storage should be optional and the user should be given the option to make a bookmark for his fingerprint for later comparison
You mean like a web browser bookmark?
I like this idea, but in order to make it possible fingerprints would have to be publicly accessible; I don't think this is a good thing to do by default so perhaps there should be a checkbox before submitting your fingerprint that says "Make my fingerprint public and allow it to be bookmarked".
and the option to download the report as textfile.
Did you have a particular format in mind?
Do you think a plain text format like the following be fine, or do you think going with something fancier like XML or JSON would be better?
--Platform (JavaScript) Linux x86_64 --Time Zone-570 --Screen Size and Color Depth 1920x1080x24
Trac:
Username: qSKvY -
Replying to qSKvY:
Can you elaborate on what you mean by "compares it to how torbrowser should look like with normal settings"? it should show which fingerprints are like the one you would have with a clean install of the newest torbrowser(maybe support multiple versions) and which deviate from the norm. it could be like on ip-check.org or with check marks. so an user can easily detect if an addon changed some browser settings or torbrowser has been modified in any way. things that are expected to e different for each torbrowser should be marked differently (like the exit node ip or the referrer)
You mean like a web browser bookmark? yes or simply a link he can safe
I like this idea, but in order to make it possible fingerprints would have to be publicly accessible; I don't think this is a good thing to do by default so perhaps there should be a checkbox before submitting your fingerprint that says "Make my fingerprint public and allow it to be bookmarked". i think so too but saving doesnt require it to become public if the link has a random id in it that only the user knows(like with google doc editing). it depends on the user if he wants to trust the server. he could be given the choice to not save it, saving only for personal use and saving it and also allowing to to contribute to statistics.
Did you have a particular format in mind?
Do you think a plain text format like the following be fine, or do you think going with something fancier like XML or JSON would be better?
--Platform (JavaScript) Linux x86_64 --Time Zone-570 --Screen Size and Color Depth 1920x1080x24 depends on what the information can be used for. possible uses are storing for later review, storing for uploading it to the site again for later comparison or for bug reporting. dont know if its worth making a database file export and upload function if the user could also save it on the server. the user has to trust the server about the servrside fingerprinting anyway on the other hand javascript produces the majority of information. so i think its your choice if its worth the effort.
about the comparing function in general i thought it would be nice to have the site calculate the amount of overlapping fingerprinting information. with the bits of identifying information you could calcuate with what certainty an adversary could link the 2 fingerprints among the group of all users in the database.
Trac:
Username: elypter -
legacy/trac#18343 (moved) is a duplicate of this.
Trac:
Cc: pde, runa, g.koppen@jondos.de, adrelanos@riseup.net, arthuredelstein@gmail.com, tD66BSHWU@gmail.com to pde, runa, gk, adrelanos@riseup.net, arthuredelstein@gmail.com, tD66BSHWU@gmail.com
Sponsor: N/A to N/A
Severity: N/A to Normal 
Trac:
Cc: pde, runa, gk, adrelanos@riseup.net, arthuredelstein@gmail.com, tD66BSHWU@gmail.com to pde, runa, gk, adrelanos@riseup.net, arthuredelstein@gmail.com, tD66BSHWU@gmail.com, mcs
Trac:
Reviewer: N/A to N/A
Cc: pde, runa, gk, adrelanos@riseup.net, arthuredelstein@gmail.com, tD66BSHWU@gmail.com, mcs to pde, runa, gk, adrelanos@riseup.net, arthuredelstein@gmail.com, tD66BSHWU@gmail.com, mcs, boklm-
So on the volunteer page it says that you'd like to have a machine readable interface to the fingerprinting service, such as JSON. What kind of information would you like to include in that? I mean obviously you want to have the fingerprint details. A barebones JSON interface would be like:
{ "useragent":"Mozilla/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101 Firefox/38.0", "accept-headers":"text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8 gzip, deflate en-AU,en;q=0.7,en-US;q=0.3" ... }
Do you want to include other data such as how many other browsers have the same fingerprint or the same fingerprint property?
Anything else you want to include?
I assume a CAPTCHA would be out of the question (I've been experimenting with fingerprinting people and browsers through CAPTCHAs lately).
Trac:
Username: qSKvY -
After a lot of delays https://browserprint.info is open for business. It's a fingerprinting suite that has a set of tests specifically to catch the Tor Browser Bundle out, based mostly on Tor Trac tickets. I'm still working on new tests but let me know what you think. Nothing would make me happier than my site being useful to the Tor project, and I'm 100% willing to modify it in any way to fit your needs.
Trac:
Username: qSKvY Replying to qSKvY:
After a lot of delays https://browserprint.info is open for business. It's a fingerprinting suite that has a set of tests specifically to catch the Tor Browser Bundle out, based mostly on Tor Trac tickets. I'm still working on new tests but let me know what you think.
This is great. I noticed a bug in the font detection in fingerprintjs2, which I have reported there: https://github.com/Valve/fingerprintjs2/pull/159
Nothing would make me happier than my site being useful to the Tor project, and I'm 100% willing to modify it in any way to fit your needs.
On thing that might be interesting is to look at CSS-only fingerprinting techniques, because users often disable JS in Tor Browser. Tor Browser protects against quite a lot of CSS attacks, but it's possible more protection is needed. I did one such experiment here: https://arthuredelstein.github.io/tordemos/media-query-fingerprint.html
-
Replying to arthuredelstein:
This is great. I noticed a bug in the font detection in fingerprintjs2, which I have reported there: https://github.com/Valve/fingerprintjs2/pull/159
Thanks. I updated the code for that test.
On thing that might be interesting is to look at CSS-only fingerprinting techniques, because users often disable JS in Tor Browser. Tor Browser protects against quite a lot of CSS attacks, but it's possible more protection is needed. I did one such experiment here: https://arthuredelstein.github.io/tordemos/media-query-fingerprint.html That's a neat test. I'd be interested in modifying it and putting it on my site, if you don't mind. Do you have a way of reporting the results back to the server? I think reporting the results back to the server without using JS is a big hurdle, but if it was possible a CSS-only fingerprinting attack would be very powerful.
Trac:
Username: qSKvY Replying to qSKvY:
Replying to arthuredelstein:
This is great. I noticed a bug in the font detection in fingerprintjs2, which I have reported there: https://github.com/Valve/fingerprintjs2/pull/159
Thanks. I updated the code for that test.
On thing that might be interesting is to look at CSS-only fingerprinting techniques, because users often disable JS in Tor Browser. Tor Browser protects against quite a lot of CSS attacks, but it's possible more protection is needed. I did one such experiment here: https://arthuredelstein.github.io/tordemos/media-query-fingerprint.html That's a neat test. I'd be interested in modifying it and putting it on my site, if you don't mind.
Yes, feel free to use it.
Do you have a way of reporting the results back to the server? I think reporting the results back to the server without using JS is a big hurdle, but if it was possible a CSS-only fingerprinting attack would be very powerful.
My demo does report to a server. There's a separate media query that makes a unique HTTP request for each possible width and for each possible height. For example, if the window width is 193px, then the following media query matches:
@media (width: 193px) { #width { background-image: url("https://dummyimage.com/50x30/fff/000&text=193&dim=width"); } }The image [https://dummyimage.com/50x30/fff/000&text=193&dim=width] is therefore requested, which results in the number 193 being displayed in the page. But if you wanted to use this to record screen sizes on your own server instead, you could provide a
background-image: url(...)that points to your server, with the matched width in a query string.Here's the script I used to generate the CSS file: https://raw.githubusercontent.com/arthuredelstein/tordemos/gh-pages/generate-size-query-demo
-
Trac:
Cc: pde, runa, gk, adrelanos@riseup.net, arthuredelstein@gmail.com, tD66BSHWU@gmail.com, mcs, boklm to pde, runa, gk, adrelanos@riseup.net, arthuredelstein@gmail.com, tD66BSHWU@gmail.com, boklm, tbb-team
Owner: cypherpunks to boklm
Status: new to assigned -
I added a section about FPCentral on the TorBrowser/Hacking page: https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Hacking#FPCentral
Trac:
Resolution: N/A to fixed
Status: assigned to closed