[tor-dev] GSoC 2017 - Project "Crash Reporter for Tor Browser"

Nur-Magomed nmagoru at gmail.com
Wed Mar 22 06:30:26 UTC 2017

Hi Tom,

Thank you for the response!

I’ve started to dive in process, collecting information about BreakPad
and Socorro.
Also I created the blog for project - https://torcrashreporter.wordpress.com.
In few days I'll try to send draft of proposal.



2017-03-20 18:18 GMT+03:00 Tom Ritter <tom at ritter.vg>:

> Hi Nur-Magomed,
> Great to have you interested in this!
> So we would want to use the Crash Reporter that's built into Mozilla
> Firefox (which is called Breakpad, and is adapted from Chromium).  At
> a high level, I would break down the project into the following
> sections:
> 1) Get the crash reporter built (at all) in our toolchain. We
> currently disable it and I know there will be at least one or two
> hurdles to overcome here as we've never tried to built this on
> Linux-for-Windows.  If you wish you could focus on a single platform
> for this at a time (e.g. Linux) so you can move onto the next step.
> 2) Audit the crash reporter data and see what it is that gets
> reported, when, and how. We'd want to err on the side of caution about
> what we report in a dump. So we'd need to enumerate each field that
> gets reported, get some samples of the data, and review if we'd want
> to include it or not. We'd also want to review what prefs govern crash
> submissions, how crashes get stored (which I think is on-disk next to
> Tor Browser), and when they get reported.
> 3) Change the way they get reported. We absolutely cannot have crashes
> sitting around on disk next to Tor Browser for the next time the user
> starts the browser - no matter how much data we strip out of them. So
> we'll need to brainstorm how we might try submitting them immediately
> upon crash instead of next startup.
> 4) Get a submission server running. Mozilla has a ton of tools to
> analyze crashes (https://crash-stats.mozilla.org/home/product/Firefox
> is one and https://github.com/mozilla/socorro is the general backend).
> We should look at Socorro and probably adapt it for use by Tor rather
> than building our own.
> 5) Circle back and get the crash reporter built reproducibly, and for
> all platforms. I put this one last because it may be the case that
> there are annoying time-sinks here, and I think by doing this last
> you'll be able to make the most headway on things that will take the
> most time - like enumerating, documenting, and evaluating the fields;
> and fiddling with Socorro.
> This is my take on it - Georg may have additional thoughts.
> -tom
> On 20 March 2017 at 09:01, teor <teor2345 at gmail.com> wrote:
> >
> >
> >> On 19 Mar 2017, at 19:02, Nur-Magomed <nmagoru at gmail.com> wrote:
> >>
> >> Hi!
> >> I'm interesred with project "Crash Reporter for Tor Browser".
> >> I'm working on that idea, but I need some specifications about how it
> should work, what kind of crash information we have to get and what
> technologies I can use on server side (for collect information).
> >> ...
> >
> > Hi Nur-Magomed,
> >
> > I've cc'd the mentors for the Crash Reporter project on this email.
> >
> > Please be aware that we have a meeting this week and next week, so some
> > of us are busy travelling and working together in person.
> >
> > T
> >
> > --
> > Tim Wilson-Brown (teor)
> >
> > teor2345 at gmail dot com
> > PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
> > ricochet:ekmygaiu4rzgsk6n
> > xmpp: teor at torproject dot org
> > ------------------------------------------------------------------------
> >
> _______________________________________________
> 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/tor-dev/attachments/20170322/ce6ff56a/attachment-0001.html>

More information about the tor-dev mailing list