- tbb-dev - lists.torproject.org

Timeline for the rebase on Firefox 38?
by intrigeri 08 Mar '15

08 Mar '15

Hi, is the plan to migrate to Firefox 38 once the FF 31 ESR series stops being supported by Mozilla, that is on August 11, or earlier? Cheers, -- intrigeri

2 1

Firefox 37 (and 31.6.0esr?) release moved up one week
by anonym 06 Mar '15

06 Mar '15

Hi, Firefox 37 was supposed to be released on 2015-04-07 but has been moved up one week, to 2015-03-31 [1], to not coincide with Easter. I suppose the same goes for the 31.6.0esr release (why shouldn't it?). If that's so, will you also move up the release date for the next Tor Browser for a same day release with the corresponding Firefox ESR release? The same apparently goes for Firefox 38 (moved up one week) but Firefox 39 will be on schedule (so there will be *seven* weeks between 38 and 39). I guess that in general I'm interested to know if you'll always aim to follow Mozilla's release schedule. This is quite relevant for us Tails developers to know, so we can adapt our release cycle according to your (and indirectly, Mozilla's) release dates. Cheers! [1] https://wiki.mozilla.org/RapidRelease/Calendar#Future_branch_dates

2 1

Using ASAN as a protection mechanism
by Tom Ritter 03 Mar '15

03 Mar '15

Here is the blog post I mentioned: http://scarybeastsecurity.blogspot.com.es/2014/09/using-asan-as-protection.… It seems like the changes he recommends are not trivial changes unfortunately. -tom

1 0

cross platform building TB's Firefox
by gunes acar 21 Feb '15

21 Feb '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, Tor Browser hacking document has this section on building *just* Firefox - instead of the whole bundle: https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Hacking#Buildi… I want to do that, but in a cross-platform manner; i.e. I want to build Mac & Win versions of TB's Firefox on Linux. And I'd like to avoid running the whole build system to make things faster. Mike pointed the scripts in the build system's Gitian descriptors: https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/gitian/d… https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/gitian/d… Would anyone have other suggestions or pointers? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJU5z5MAAoJEPb7JcMmVt4g9UYH/jkNuxhNOgDGTCfpAN79faqU iMoJ/nuTfOYvw6pZJmCqCpDU31xCRWH0GLz/Fy5efAEYHtNVeWNfSOY57vS4Og9a KpiNHNNNdD7vuqxbzi1Sp0EPD+Pynw86R8X9NrKup4hHj/dXYJHOI/WXhfss7sGz Px2/91xAUhYEflgSTgNBKix3F9gT6Od7Si7x4kaC/KuTF0Lo91kk8NUuOv+fYjya Sy2a00ZMP+7fcQUxjS0QZKir+LxGVA3TeF3agPlUGMV7m//tzc3k2JJbemN07bHB PKir6TH3Q5/JPuAD4qtbbYE9qOL/QDuJmN40yZ4Xk/lLTBoB42JGffuVlZjyp2k= =o76z -----END PGP SIGNATURE-----

3 3

Fwd: [tor-dev] Tor Project Idea | GSOC 2015 | Panopticlick | fake fingerprint
by Rohit Dua 16 Feb '15

16 Feb '15

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(a)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(a)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(a)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=… > >> > >> [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(a)lists.torproject.org > >>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > >>> > >> > >> _______________________________________________ > >> tor-dev mailing list > >> tor-dev(a)lists.torproject.org > >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > >> > > _______________________________________________ > > tor-dev mailing list > > tor-dev(a)lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > _______________________________________________ > tor-dev mailing list > tor-dev(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev >

2 1

TBB meeting temporarily moved to Tuesday 2/17
by Mike Perry 14 Feb '15

14 Feb '15

Apparently this Monday is President's Day[1,2] in the US, so we'll be moving the TBB meeting to the same time on Tuesday instead (18:00 UTC). Sorry for the short notice, this rather obscure holiday took me by surprise too. Hopefully this doesn't cause any new conflicts. 1. https://en.wikipedia.org/wiki/Washington%27s_Birthday 2. For the benefit of our European colleagues, here's a biographical documentary on the epic history of our nation's first president that plays in Tor Browser: https://www.youtube.com/watch?v=l7iVsdRbhnc (might be slightly NSFW, but it's a holiday!) -- Mike Perry

1 0

Fwd: Tor Project Idea | GSOC 2015 | Panopticlick | fake fingerprint
by Rohit Dua 12 Feb '15

12 Feb '15

---------- Forwarded message ---------- From: Rohit Dua <8ohit.dua(a)gmail.com> Date: Thu, Feb 12, 2015 at 1:51 AM Subject: Tor Project Idea | GSOC 2015 | Panopticlick | fake fingerprint To: tor-dev(a)lists.torproject.org Hello I'm Rohit from India, aspiring for gsoc-2015(TOR). This will be my 2nd consecutive year for gsoc participation. Previous mediawiki. Project:BUB tool <http://tools.wmflabs.org/bub/> I stumbled across Panopticlick related project <https://www.torproject.org/getinvolved/volunteer.html.en#Panopticlick> in tor project ideas. I would like to propose a project relating to this. Panopticlick obtains browser fingerprints mainly via javascript objects(navigator, screen, window etc.) These objects are easy to fake in webkit browsers, without touching the underlying source code of browsers, eg. using *__defineGetter__() *after every* javascriptObjectCleared.* If we could compile a large dataset of possible values of js object for several popular browsers, we could use that to randomize the fingerprint for each network request. The dataset could also contain random http header values etc. I am building a python library that does somewhat similar. https://github.com/rohit-dua/selkie (*in development*) It uses pyqt for headless browsing/scraping of webpages. It is a python library that mimics different browser fingerprints by faking(randomizing) the values of navigator, screen object, headers etc. I also intend to add biometric library that mimics humans mouse movements/ keypress statistics for clicking links and surfing pages. I propose to build a similar headless bot that mimics several browsers fingerprints and could be used for anonymous scraping of data and/or adding a feature of random fingerprint in awesome tor tools. Also to improve anonymity location based datasets could be provided(*supported in the above library*) as extra/feature.(maybe downloaded from statcounter.com) Thanks Rohit Dua IRC:rohit-dua github: rohit-dua <https://github.com/rohit-dua/> (8ohit.dua(a)gmail.com)

1 0

Missing the meeting today
by Nicolas Vigier 10 Feb '15

10 Feb '15

Hello, Due to an unexpected thing I have to do tonight, I will be missing the meeting. Nicolas

1 0

Missing meeting today
by Arthur D. Edelstein 02 Feb '15

02 Feb '15

Hi All, I'll be missing the tbb-dev IRC meeting due to travel, but I will send a message later with my week's report/plans. Arthur

1 0

Quo Vadis, Private Browsing Mode?
by Georg Koppen 02 Feb '15

02 Feb '15

Hi all, the discussion about how to handle our fingerprinting patches in the Private Browsing Mode (PBM) space we had on 01/12 made me think a bit more about the topic in general. So, PBM currently is just meant to avoid saving information about the sites you visit. Nothing more and nothing less.[1] This basically maps to the disk avoidance requirement in the Tor Browser design document.[2] The question is now how to treat the other privacy relevant areas like cross-origin linkability or fingerprinting? Should we invent new modes and try to sell them to the user in addition to the Private Browsing Mode? And if so, how exactly do we relate all these things together given that there are now private windows and non-private windows coexisting in vanilla Firefox versions (thanks for bringing this complication up, Arthur)? Here is what I think we should aim at: We should have one mode we sell as private browsing mode, call it Private Browsing Mode+ (PBM+) for now, that contains the different areas I mentioned above as they are all related to "privacy" in one way. How should it work ------------------ If you look at the current privacy pane in your Firefox you see that there are already some foundations laid for that idea in that Mozilla seems to acknowledge that there are different angles to "privacy": there is the Tracking section that would roughly correspond to our cross-origin linkability area, then there is the History section which regulates the disk avoidance part and then there is the odd Location Bar section which is presumably there to optionally prevent people from looking over ones shoulder. No fingerprinting part. No proxy part (in case users are looking for location privacy). At the same time the privacy pane is highly confusing: What do third party cookie settings play for a role in the history section, for instance? And why are these settings deeply buried there and not visible in the Tracking section? I am not talking here about how the privacy pane should look like in non-PBM(+) but if PBM+ got enabled the pane could by quite clean and show by default five checkboxes and one button like [x] Enable Private Browsing Mode+ [x] Don't remember history [x] Prevent website tracking [x] Prevent browser fingerprinting [ ] Prevent location tracking (use a proxy) [Show site data] (We could think about checking the last checkbox, too, if a proxy is already configured) Users would then 1) easily see what kind of privacy related protections they have enabled without the need to dig down some obscure menus and fiddle with several settings. 2) be able to configure their mode according to their needs (yes, there are people that want their history being enabled (I am not of that sort btw) while all the other protections remain in place). 3) get a place where the improved privacy UI mentioned in our design document would have a good place (we might need to think about which relationship it has to the prevent-tracking-option above but that is just a detail): a "Show site data" button. Why should it work that way --------------------------- First if all, it is highly confusing for a user to have a bunch of modes to select from if she wants to get privacy on the web. "Enable Private Browsing Mode" somewhere in the menu or via a toolbar button should be enough. There is no need for her to know things about the different parts of the privacy concept. Second, there is still a big part of users that see more than one angle with respect to privacy and include the linkability and fingerprinting part in their concept of a private browsing mode.[3] We should take care of them and incorporate that into the UI I think. This is especially important, I think, as the usual things that hit the mainstream press and thus have a chance to get seen by and influence normal users are linkability/fingerprinting related.[4][5] What to do ---------- For the linkability related things we have a preference which makes it a) easier for Mozilla to merge our patches and b) makes it easier for the UI I outlined above. It might even make it easier for Mozilla to adapt such a UI as they could just flip a preference if they really think that cross-origin linkability has nothing to do with a Private Browsing Mode. It might make sense to have a preference for the fingerprinting patches, too, then given the model above. Something like "privacy.fingerprinting.disable" maybe. This would allow Mozilla then again to leave the checkbox unchecked in a UI like the one above if they think fingerprinting does not belong into the Private Browsing Mode. It might make upstreaming patches easier, too. And, as a last point, we should not let us distract here from people framing the fingerprinting issue as a security related one being orthogonal to privacy concerns.[6] Georg [1] https://support.mozilla.org/en-US/kb/private-browsing-browse-web-without-sa… [2] https://www.torproject.org/projects/torbrowser/design/#disk-avoidance [3] About 22% according to http://www.winlab.rutgers.edu/~janne/WPES14-privatebrowsing.pdf. But the data they collected is not as robust as I'd like to have it. [4] E.g.: http://www.mediapost.com/publications/article/155032/#axzz2JFJ5s8l1 [5] E.g.: https://www.propublica.org/article/meet-the-online-tracking-device-that-is-… [6] See the FPDetective paper: https://www.cosic.esat.kuleuven.be/publications/article-2334.pdf sections 7.1 and 7.3 for examples

4 4