Hi,
here comes feedback to the remaining part of the proposal.
Pierre Laperdrix:
[snip]
Code sample In 2014, I developed the entire AmIUnique.org website from scratch. Its aim is to collect fingerprints to study the current diversity of fingerprints on the Internet while providing full details to users on this subject. It was the first time that I built a complete website from the design phase to its deployment online. One of the first challenge that I encountered was to build a script that would not only use state-of-the-art techniques but that could simply work on the widest variety of browsers. Testing a script for a recent version of a major browser like Chrome and Firefox is an easy task since they implement the latest HTML and JavaScript technologies but making sure that the script runs correctly on older browsers like Internet Explorer is another story. Juggling with a dozen different virtual machines was necessary to obtain a bug-free and stable version of the script. A small beta-test was required to make sure that everything was good to go for what is now the foundations of the AmIUnique website. The totality of the source code for AmIUnique and my other projects can be found on GitHub. A second challenge that I faced was to deal with the increasing load of users so that the server could return personalized statistics to visitors in a timely manner (less than 2/3s). By having a separate entity that updates statistics in real time on top of the database, I managed to drastically reduce the server load. With the number of Tor users around the world, the website needs from the get go to handle a high load of visitors and statistics computation and my previous experience on that specific task will prove useful.
For the very first version of Torprinter, I plan on testing well-known and widespread fingerprinting techniques to make sure that there is no variation among Tor users. These include HTTP headers and known JavaScript objects. There should be no need for any Flash attributes since plugins are not present in the Tor browser (thus removing complex code in charge of correctly loading the Flash object).
We might think about that a bit. We have a bunch of users it seems that are still trying to go through all the hassle and are getting Flash going in Tor Browser. It might be enough to detect them by just enumerating available plugins.
For this proposal, I have also developed a special page with 7 different tests that are mainly targeted at the Tor browser to give an idea of what tests can be included that are more suited to the Tor users. Tests n°5, n°6 and n°7 are broader and also concerns the Firefox browser. You can found a working version of the script on a special webpage (need to scroll to make the results appear): https://plaperdr.github.io/torScript.html The script can be found here: https://plaperdr.github.io/assets/tor/tor.js
Test n°1 Test the size of the current window - As reported by ticket n°14098 https://trac.torproject.org/projects/tor/ticket/14098
FWIW: that test is not working correctly. We cap the width and the height at 1000px and round the window to a multiple of 200pxx100px.
Test n°2 Test the support of emoji - As reported by ticket n°18172 https://trac.torproject.org/projects/tor/ticket/18172 Test n°3 Analysis of the "scroll" behavior of the window - As investiagted by http://jcarlosnorte.com/security/2016/03/06/advanced-tor-browser-fingerprint... Test n°4 Test the size of current fallback font by using the canvas API to render some text (no need for user permission like canvas extraction) - Custom test Test n°5 Test the difference between OS on the maximum font size - Custom test Test n°6 Test the difference between OS on the Date API - As reported by ticket n°15473 https://trac.torproject.org/projects/tor/ticket/15473 Test n°7 Test the difference between OS on the Math class - As reported by ticket n° 13018 https://trac.torproject.org/projects/tor/ticket/13018
Any remarks, suggestions or ideas are very welcome!
We are currently not doing much against OS fingerprinting. So we'll see how useful tests like test 5,6,7 are. Maybe they show us that we should prioritize those things. But on the other hand we still suspect that there are other things out there providing more entropy.
A general thing to think about while writing the tests would be having them modular as well: a library could contain the functionality used by more than one test (like providing a canvas) while particalar tests would make use of it for specific purposes. This would prevent code duplication and should help making the project more maintainable.
Georg