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_lMM9ig...
2017-03-26 18:23 GMT+03:00 Georg Koppen gk@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.
- 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.
- 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.
- 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
- 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.
- 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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev