[tor-dev] GSoC'16 proposal: the Torprinter project (a Panopticlick-like website)

Mon Mar 21 17:07:51 UTC 2016

Hi,

Thanks for the rest of the feedback and for taking the time to read
everything! I'll update my proposal accordingly.
I have added some small comments below.

Pierre

On 03/21/2016 04:23 PM, Georg Koppen wrote:
> 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.
> 

I have updated the test to reflect this, I didn't have all the numbers
right. It should be fixed now.
I was a little bit surprised to find out that the Tor browser gives the
exact size of the window with pixel precision (even if I completely
understand why). On Firefox, even in windowed mode, the browser reports
the full size of the screen. With a test like this, we could see if the
rounding works correctly for all users and find out the percentage of
users who resize their windows.

>> 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-fingerprinting.html
>> 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.
> 
I'm with you on the fact that other tests should provide more entropy.
I'm still curious to see if some tests like the one on the Math class is
just about OS fingerprinting and that no differences can be observed
with users on the same OS.

> 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.
> 

This sounds like a good idea. If several tests use the same browser API,
we could have utility/library functions to set them up and reduce code
duplication.

> Georg
> 
> 
> 
> 
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> 