[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-dev] Tor Project Idea | GSOC 2015 | Panopticlick | fake fingerprint



Thank you all for replying.

I can summarize some points after reading the links provided.

The random fingerprint headless browser should not be connected with
Tor network as this can lead to more frequent blocking of exit
nodes(due to more scraping bots using exit nodes)

A random fingerprint should be better than current approach(single
fingerprint) because a company/government can easily block access to
that one static/single while this will be unlikely for a random
fingerprint from a very large dataset.(This will be very good for
headless browsing)

Faking a fingerprint requires several properties. But most of them can
be overwritten. Some of the ones with most problems:
1.) Faking fonts: webkit does not provide way to manually
disable/enable selected fonts to be used. A way around this could be
to disable all fonts and then load random fonts using @font-face just
after javascriptObjectCleared, for each request.
2.) Timezone could easily be faked after overwriting Date object.
3.) Plugins/MimeTypes/navigator/colorDepth can be faked by overwriting
their object.
4.) Window and Screen objects including
innerHeight/screenWidth/ScreenHeight can also be overwritten but only
for headless browsing as changing these will hinder the user view
experience.
5.) Almost all browser unique features like
screen.mozBrightness,navigator.mozSms,InstallTrigger[FIREFOX],
navigator.webkitStartActivity,navigator.getStorageUpdates,window.chrome[CHROME]
can be added explicitly to dom for corresponding browser specific
fingerprint.
6.) The fingerprint properties should be location specific(eg. the
accept-language headers should including the langauges of the
location) so as to avoid statistics based attack(based on location
data)
7.) To avoid timing attack, a local proxy can be used which will add
an extra random delay time(based on location) in all TCP/IP packets
sent(including syn/ack)
8.) Flash/Java has to disabled to avoid information leakage. While the
plugins can still be faked as available in the Plugins Object.
9.) To avoid mouse cursor statistics based attack for headless
browser, mouse movements can be faked with certain degree of
randomness like a human.(several libraries are available for this.)

The headless bot can be built on a framework like qtwebkit.


Do you think headless browser with random fingerprint without Tor
usage will be a useful project?

-
Rohit Dua




On 2/12/15, Gunes Acar <gunes.acar@xxxxxxxxxxxxxxxx> wrote:
> Hi Rohit,
>
> Please check the ticket #11949 and the comment by Georg:
> https://trac.torproject.org/projects/tor/ticket/11949#comment:1
>
> TL;DR research on the advantages of randomization over the current
> approach (making everyone look like same) may be useful before starting
> with the actual implementation.
>
> Also, please check this thread on the limitations of JS hooks:
> https://lists.torproject.org/pipermail/tbb-dev/2014-June/000073.html
>
> You can fool some fingerprinters by spoofing browser properties but more
> advanced scripts can easily uncover the real browser/device attributes
> by checking specific functionality [1] or using "side-channels" [2].
>
> [1] see, "Evolution of functionality" subsection on
> https://seclab.cs.ucsb.edu/media/uploads/papers/sp2013_cookieless.pdf#page=10
>
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=418986, see, esp.
> Camillo's test vectors.
>
> Gunes
>
> On 02/12/2015 06:12 PM, l.m wrote:
>> Hi,
>>
>> For anonymous scraping it could certainly be useful. This poses a
>> problem as far as making Tor Project look as if it supports autonomous
>> anonymous scraping of web data. Ultimately this impression could lead to
>> even more blocking of Tor exits. Another problem with the idea of a
>> randomized fingerprint is that it breaks useability. It might be great
>> for scraping but web sites rely on knowing some of those parameters for
>> proper display. Finally it's worth mentioning that the goal of TBB
>> fingerprinting is to reduce entropy within TBB's user base. A random
>> fingerprint violates this constraint.
>>
>> I'm not commenting on gsoc eligibility
> +1
> --just that it's an edge case
>> which will lead to blocking of Tor's exits. If more exit get blocked
>> then you cannot scrape.
>>
>> --leeroy
>>
>>
>> _______________________________________________
>> tor-dev mailing list
>> tor-dev@xxxxxxxxxxxxxxxxxxxx
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>>
>
> _______________________________________________
> tor-dev mailing list
> tor-dev@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev