Hello
I recently proposed a gsoc project realating to panopticlick and browser fingerprinting. But due non availability of mentor, Damian Johnson had to drop the idea from volunteer page.
I am writing this email to ask if someone could be available as a mentor for the gsoc project relating panopticlick. I wrote some scripts to randomize browser fingerprint github.com/rohit-dua/selkie . You may want to check these out.
Thanking you Rohit Dua Delhi, India
On Mon, Feb 16, 2015 at 2:45 AM, Damian Johnson atagar@torproject.org wrote:
Hi Rohit, sorry about the delay. I've been trying to get ahold of the project mentor for panopticlick but no luck, so I'm dropping it from the volunteer page. You're certainly still welcome to take it on, but for the purposes of GSoC we seem to be missing a potential mentor for it.
Sorry about the confusion! -Damian
On Thu, Feb 12, 2015 at 1:53 PM, Rohit Dua 8ohit.dua@gmail.com wrote:
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@esat.kuleuven.be 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=1...
[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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev