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

[Pierre Laperdrix]

Hi Gunes,

Thanks a lot for the feedback!

On 03/16/2016 03:30 PM, gunes acar wrote:
> Hi Pierre,
> 
> Thanks for the very well thought proposal!
> 
> I'm curious about your ideas on the "returning device problem." EFF's
> Panopticlick and AmIUnique.org use a combination of cookies and IP
> address to recognize returning users - so that their fingerprints are
> not "double-counted."
> 
> Since these signals will not available anymore (unless the user opt-ins
> to retain the cookie), I wonder what'd be your ideas to address this issue.

This one is a really interesting question but a tricky one because we
can't really rely on the cookies+IP combination with the Tor browser.
My answer here is simple: it all depends on the goal we set for the website.

Do we want to learn how many different values there are for a specific
test so that we can reduce diversity among Tor users? In that case, the
site would not store duplicated fingerprints or it could be
finer-grained and not store duplicated values for each test.

Or do we want to go further and know the actual distribution of values
among Tor users so that it may guide the development of a potential
defense? In this case, the site must identify returning users and it is
a lot harder to do here. The only method that comes to mind and that
would be accurate enough to work in this situation would be to put the
test suite behind some kind of registration system. The problem is that
a mandatory registration goes in the complete opposite direction of what
Tor is about and it would greatly limit the number of participating
users (or even render the site useless before it is even launched). A
solution in the middle would be not to store duplicated fingerprints but
I really don't know how much it would affect the statistics in the long
run. Would it be marginal and affect like 2/3/4% of collected
fingerprints or would it be a lot more and go above 20% or else?

Finally, I thought about using additional means of identification like
canvas fingerprinting but I don't think there would be enough diversity
here to identify a browser.


> 
> Please find other responses below.
> 
> Best,
> Gunes
> 
> On 2016-03-15 04:46, Pierre Laperdrix wrote:
>> Hi Tor Community,
>> ....
>> - How closed/private/transparent should the website be about its tests
>> and the results? Should every tests be clearly indicated on the webpage
>> with their own description? or should some tests stay hidden to prevent
>> spreading usable tests to fingerprint Tor users?
> 
> I think the site should be transparent about the tests it runs. Perhaps
> the majority of the fingerprinting tests/code will run on the client
> side and can be easily captured by anyone with necessary skills (even if
> you obfuscate them).
> 

You are right on that. It makes sense to be transparent since obfuscated
JS code can be deciphered by someone with the necessary skills.
Also, if tests are hidden, most Tor users would rightfully be wary on
what is exactly being executed in their browser and they would simply
not take the test. In that case, the impact of the website would be
greatly limited. Being transparent really seems to be the right way to
go here.

>> - Should a statistics page exist? Should we give a read access to the
>> database to every user (like in the form of a REST API or other solutions)?
> 
> I think aggregate statistics should be available publicly but exposing
> individual fingerprints publicly may not be necessary.
> 

Like you said, aggregate statistics seem to be the best solution here.
Then, I'm wondering if it would be possible to offer the complete list
of values for each attribute separately from others. Then, my concern is
how easy it would be to correlate separate attributes to recreate
fingerprints, even partial ones.

Regards,
Pierre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160316/81896d40/attachment.sig>