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 <g...@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@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > >
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev