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

[Nur-Magomed]

Hi, Georg,
Thank you!

> We should have a good user interface ready giving the user at least an
> explanation on what is going on and a way to check what is about to be
sent.

I've also thought about that, I suppose we could just put text explanations
on Crash Reporter client UI form [1].

I've wrote the Proposal [2], could you review it and leave comments?
Thanks.

P.S. Have I to send proposal to GSoc as draft?

1) http://kb.mozillazine.org/images/MozillaCrashReporter-Fx7.png
2)
https://docs.google.com/document/d/13q3D1UYYbmUv4DlZBYFLnHuLnbz7-GI2L_lMM9igZ_o/

2017-03-26 18:23 GMT+03:00 Georg Koppen <gk at torproject.org>:

> Tom Ritter:
> > 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:
>
> Those look all good to me. I just have one small addition/clarification
> below.
>
> > 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.
>
> Even though it seems to me the critical UX part is implicit in the
> section above, I thought it might be better to point it out explicitly
> as well:
>
> We should have a good user interface ready giving the user at least an
> explanation on what is going on and a way to check what is about to be
> sent.
>
> Georg
>
> > 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
>
>
>
> _______________________________________________
> 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/20170329/668c5486/attachment-0001.html>