- tbb-dev - lists.torproject.org

Fwd: Crash Reporter for Tor Browser - GSoC 2017 Intro
by Tom Ritter 02 Jun '17

02 Jun '17

Hey all, Nur-Magomed will be in irc (probably #tor-dev unless we need to move because it conflicts with another meeting) twice a week for status checkins and general dedicated "help with bugs and errors" time. If you're able to pop into irc or keep an eye on it during those times, that would be fantastic, since you might know an aswer I don't. - Wednesday 3PM UTC (That's 11 AM EDT) - Friday same time -tom ---------- Forwarded message ---------- From: Nur-Magomed <nmagoru(a)gmail.com> Date: 12 May 2017 at 13:25 Subject: Crash Reporter for Tor Browser - GSoC 2017 Intro To: tor-project(a)lists.torproject.org Cc: Tom Ritter <tom(a)ritter.vg>, Georg Koppen <gk(a)torproject.org>, Damian Johnson <atagar(a)torproject.org> * Didn't change the title in previous letter, sorry :/ Hi everyone! My name is Nur-Magomed, I’m 4th year student from North-Caucasus Federal University, Russia. This summer, I will be working on Crash Reporter for Tor Browser as a part of GSoC 2017. My mentors are: Tom Ritter - Primary Mentor, Georg (gk) - Backup Mentor. At the beginning I would like to thank all Tor dev community and my mentors that helped me and accepted my proposal, I’m glad to be a part of Tor dev community! About project Crash Reporter will be helping developers to improve Tor Browser, find bugs and crash reasons easier, that would make Tor Browser more stable and user-friendly. Mozilla Firefox has the crash reporter based on Google BreakPad with server side - Mozilla Socorro. My summer work is focused at adapting Firefox Crash Reporter for Tor Browser (Linux version). And also adapting Socorro for changed Crash Reporter and run it as “.onion” service. Full project proposal can be found at blog [1] or in PDF file [2]. Project timeline GSoC coding period starts on May 30 and ends on August 21 comprising a total of 12 weeks: week 1 - 5 : Crash Reporter client side | +--- week 1+2 : Build Tor Browser with Crash reporter. Improving crash data minidumps generator (don’t save privacy data in reports) | +--- week 3 : Redesign report’s client UI form, making functionality to delete data after sent, removing not necessary UI functions | +--- week 4 : Adapting report’s sender for Tor network (sending through Tor network) | +--- week 5 : Testing and review code week 6 - 11 : Crash Reporter server side based on Socorro | +---week 6+7 : working on Collector, adapting it according to changed minidumps | +---week 8+9 : updating DB structure, adapting Processor (for DB and for Collector’s reports) | +---week 9+10 : Working on statistic site - updating design templates, ORM classes for DB, and etc. | +---week 11 : Testing and review code. Setting up service on Tor network. week 12: Final testing, documentation Before coding will start there are some tasks to do (I'm starting work): > be sure which ones of fields or of their combinations could be privacy-sensitive > find the best way that explains to user what happened and what he can do after crash (in UI design) > try build Tor Browser with Crash Reporter from Firefox [for Linux] I will send bi-weekly status reports to this list, and also public it on my blog [1]. Please don’t hesitate to contact me if you have any suggestions. E-Mail: nmagoru [at] gmail.com IRC (OFTC): nmago Time Zone: UTC+03:00 Kind regards, Nur-Magomed Links: [1] https://torcrashreporter.wordpress.com/2017/04/03/google-summer-of-code-pro… [2] https://torcrashreporter.files.wordpress.com/2017/05/final_proposal.pdf

1 0

Re: [tbb-dev] So, about the Linux sandbox in the long term?
by Nathan Freitas 30 May '17

30 May '17

On Tue, May 30, 2017, at 02:51 PM, Hans-Christoph Steiner wrote: > > Tom Ritter: > > On 30 May 2017 at 13:22, Hans-Christoph Steiner > > <hans(a)guardianproject.info> wrote: > >> As for Android apps updating their own code, it is possible, and it is > >> occasionally done. > > > > Can it be prevented? > > Android now sets the /data and /sdcard partitions so that code cannot be > executed from them. Those are the only places that apps have permission > to write. So apps cannot download and store code. The only option is > to download code and keep it in RAM. However, we could download a new tor binary, or PT's on demand, at least in the current configuration, since those are just command line executable we unpack and store in data. You can execute binaries from within /data - you just need to chmod them first. It is only /sdcard where that is not allowed. I think you can also download shared libraries anywhere, and just load them via System.load() with an arbitrary path. I do agree, there is benefit from keeping the tor process in an isolated sandbox from the browser process. This has been the discussion we have been having around a core "Tor Network Services" APK, that would be essentially an invisible dependency much like Google Play Services. +n

2 1

Re: [tbb-dev] Where is Orfox being developed?
by Nathan Freitas 25 May '17

25 May '17

On Tue, May 23, 2017, at 06:29 AM, e3b(a)riseup.net wrote: > all the sites linked to on https://guardianproject.info/apps/orfox/ are > inactive, except for the repository on > https://gitweb.torproject.org/tor-browser.git/ , where Georg Koppen > seems to be the only active contributor. We have a #tor-mobile channel on OFTC that is becoming more active. Otherwise, this is the main repo for builds: https://github.com/guardianproject/Orfox and this is the repo where we track the main tor-browser code with patches for Android: https://github.com/guardianproject/tor-browser/tree/0d08726e5067b9d608f6fa2… Since Orfox is mostly a rebase and tweak on top of Georg and other's work on the main tor-browser project, it can sometimes seem like it isn't very active. Also, we've been spending a lot of energy working on iOS efforts, since the state of a tor-based browser there has not been very good. More on that soon. +n

1 0

Where is Orfox being developed?
by e3b＠riseup.net 23 May '17

23 May '17

Hi, all the sites linked to on https://guardianproject.info/apps/orfox/ are inactive, except for the repository on https://gitweb.torproject.org/tor-browser.git/ , where Georg Koppen seems to be the only active contributor. How can I get up to date on the development? Thanks! -- e3b

1 0

Next Tor Browser meeting: Tue, May 30 1800 UTC in #tor-dev
by Georg Koppen 22 May '17

22 May '17

Hi all, Next Monday is Memorial Day in the U.S. and we'll therefore move the meeting by one day. New meeting time for next week is: Tuesday, May 30, 1800 UTC. As usual we'll gather in #tor-dev for status updates and items that need further discussion. Feel free to drop by! Georg

1 0

Tag: sandboxed-tor-browser-0.0.7
by Yawning Angel 22 May '17

22 May '17

Hello, I went and tagged this, because it's a good idea, and despite the changes being minor there's no reason to sit on them. Changes in version 0.0.7 - 2017-05-22: * Bug 21977: Fetch install/update metadata files from a different location. * Bug 22038: Stub out `pa_start_child_for_read`. This is the first release that will use `update_3`, so until prior releases are dead, `update_2` will need to be kept, well up to date. The PulseAudio related change is more for peace of mind than anything else. I don't think it's particularly harmful or exploitable, but removing it doesn't hurt, so I did. See the bug for more details. Regards, -- Yawning Angel ps: As far as I am aware (though I stopped using the alpha series as my daily driver as of the ESR52 transition), 7.0 works as well in the sandbox as elsewhere, so there shouldn't need to be any more changes. Let me know if this is not the case.

1 0

SELFRANDO_write_layout_file enabled intentionally?
by Rusty Bird 19 May '17

19 May '17

Hi, start-tor-browser sets the SELFRANDO_write_layout_file environment variable to an empty string, which *enables* [1] the creation of the 7 MB /tmp/<PID>.mlf layout file. This adds 2 seconds of startup time on my system. Would it make sense to *disable* it for alpha/stable builds? If so, the export line in start-tor-browser should be removed. (People who really want the layout file for debugging could still enable it by running "SELFRANDO_write_layout_file= ./start-tor-browser".) Rusty 1. https://github.com/immunant/selfrando/blob/73f33ecc8031bdf9c2ba8d95191b23f7…

6 6

Proposal: extensions.update.enabled=false [tbb-fingerprinting]
by Rusty Bird 27 Apr '17

27 Apr '17

Hi, I propose to disable Tor Browser's automatic extension update, effectively freezing extension versions between releases. This would, among other things, get rid of a fingerprintable difference between mainline TB and TB with an immutable extensions directory, such as sandboxed-tor-browser, Split Browser for Qubes[1], or Tails[2]. (Currently, mainline TB uses extensions.update.enabled=true. Of the included extensions, HTTPS Everywhere and NoScript actually update, whereas Torbutton and TorLauncher already opt out by setting a bogus updateURL.) So when e.g. HTTPS Everywhere at some point updates itself to a version with new rules, a website affected by the rule changes (as a first party or as a third party) can distinguish which version is active. For NoScript, fingerprinting different versions is less obvious, but probably still possible when an update breaks or fixes some content. Downsides of disabling: - Minor improvements to HTTPSE/NoScript take a little longer to reach the user. (If there's a _serious_ security or usability issue, the TB version would have to be bumped anyway.) Upsides: - More uniform fingerprint for mainline and immutable TB - More reproducible environment for bug reports - Not affected by vulnerabilities in the extension updater - Slightly reduced exit traffic :) Rusty 1. https://github.com/rustybird/qubes-split-browser 2. Although Tails can of course be distinguished by its ad blocker.

3 4

roadmaping and tracking dependencies
by isabela 21 Apr '17

21 Apr '17

Hello TBB! As a result of organizing ourselves into teams and coordinate our efforts towards similar goals (e.g. better support for mobile users). Tor's Vegas teams are in need of better visibility of what each one is doing and better coordination of deliverables/dependencies. In order to achieve that, I am asking all Vegas teams to organize their work in a roadmap (covering at least till the end of 2017). Once that is done, I would like the team to identify possible dependencies on other teams to get your work done. For instance, I start working on it with the UX team and they are aware of some dependencies you have on them for certain deliverables: https://storm.torproject.org/shared/f9a3OwWFIyOlNrY1W9CxmxkFnlGbWvGzofJazGo… I know you have discussed and updated your roadmap at the AMS meeting. I took the liberty of pasting it from the wiki in this pad: https://storm.torproject.org/shared/gf-PXTTtFJyzrpqDoGepLwXa4Sr4JUb-hWIK6yq… If you don't have any further updates to it. I would like that you identify the dependencies you have on other teams and by when they need to be done so you can work at your deliverables. Please do it even for the ones the UX team has already identified you depend on them. The goal here is to have a full list of dependencies from each team to make sure everyone is on the same page. Once we have this list - I will help facilitate the coordination of that with the other teams. BTW - other teams might have dependencies on you too! Please let me know if you have any questions, or if you want me to hang out at your next meeting to help with it. Cheers, isabela

2 1

New fingerprinting patches
by Ethan Tseng 18 Apr '17

18 Apr '17

Hi Georg and Arthur, We have a meta bug for the fingerprinting resistance feature of Firefox. https://bugzilla.mozilla.org/show_bug.cgi?id=1329996 According to this meta bug, we have 46 bugs (patches) being tracked on our side. 43 of them are open bugs at this moment. https://mzl.la/2oDC3Ap Last month in the Tor meeting in AMS, you mentioned that there are 30+ new patches for fingerprinting. Could you please help to identify these new patches? (by either providing a list or instructing us how to find out them on Trac) We will add the corresponding bugs on Bugzilla for them. -- Ethan Tseng Engineering Manager, Mozilla

2 2