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

[Rohit Dua]

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 at 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 at 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 at 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=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 at lists.torproject.org
> >>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> >>>
> >>
> >> _______________________________________________
> >> tor-dev mailing list
> >> tor-dev at lists.torproject.org
> >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> >>
> > _______________________________________________
> > tor-dev mailing list
> > tor-dev at lists.torproject.org
> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tbb-dev/attachments/20150216/a9bd3782/attachment.html>