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

[Nur-Magomed]

Tom, thanks for review,
I've sent the proposal final version through gsoc site.

__

>It would be cool to build the browser with https://github.com/google/sani
tizers this way you could get bug reports for bugs that don't >panic the
browser

Hi Antonio,
Thanks for your reply!
I've add it to the proposal as optional.


2017-04-03 8:42 GMT+03:00 Antonio Groza :

> It would be cool to build the browser with https://github.com/google/sani
> tizers this way you could get bug reports for bugs that don't panic the
> browser
>
> Il lun 3 apr 2017, 07:10 Tom Ritter  ha scritto:
>
>> On 1 April 2017 at 09:22, Nur-Magomed  wrote:
>> > Hi Tom,
>> > I've updated Proposal[1] according to your recommendations.
>> >
>> > 1) https://storm.torproject.org/grain/ECCJ3Taeq93qCvPJoWJkkY/
>>
>> Looks good to me!
>>
>> > 2017-03-31 19:46 GMT+03:00 Tom Ritter :
>> >>
>> >> On 31 March 2017 at 10:27, Nur-Magomed  wrote:
>> >> >> I think we'd want to enhance this form. IIRC the 'Details' view is
>> >> >> small and obtuse and it's not easy to review. I'm not saying we
>> >> >> _should_ create these features, but here are a few I brainstormed:
>> >> >
>> >> > Yes, actually that form only shows "Key: Value" list, we can break it
>> >> > down
>> >> > in several GroupBoxes which consist of grouped data field and
>> checkboxes
>> >> > to
>> >> > include.
>> >> >
>> >> >> Let's try and avoid GDocs if you don't mind :)
>> >> >
>> >> > Sorry :) I already registered on storm, but I had no access to
>> create.
>> >> > Thanks for review, I'll update proposal accordint to your requiments.
>> >>
>> >> No worries.
>> >>
>> >> > And question: could we throw Windows or MacOS or both versions from
>> >> > timeline, and develop them after summer?
>> >>
>> >> Yes, I think that's fine. I think getting one platform to completion
>> >> would be a great accomplishment and would lay the groundwork and
>> >> improve the momentum to getting the subsequent platforms there.
>> >>
>> >> -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
>> >
>> ___
>> 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
>
>
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[Antonio Groza]

It would be cool to build the browser with
https://github.com/google/sanitizers this way you could get bug reports for
bugs that don't panic the browser

Il lun 3 apr 2017, 07:10 Tom Ritter  ha scritto:

> On 1 April 2017 at 09:22, Nur-Magomed  wrote:
> > Hi Tom,
> > I've updated Proposal[1] according to your recommendations.
> >
> > 1) https://storm.torproject.org/grain/ECCJ3Taeq93qCvPJoWJkkY/
>
> Looks good to me!
>
> > 2017-03-31 19:46 GMT+03:00 Tom Ritter :
> >>
> >> On 31 March 2017 at 10:27, Nur-Magomed  wrote:
> >> >> I think we'd want to enhance this form. IIRC the 'Details' view is
> >> >> small and obtuse and it's not easy to review. I'm not saying we
> >> >> _should_ create these features, but here are a few I brainstormed:
> >> >
> >> > Yes, actually that form only shows "Key: Value" list, we can break it
> >> > down
> >> > in several GroupBoxes which consist of grouped data field and
> checkboxes
> >> > to
> >> > include.
> >> >
> >> >> Let's try and avoid GDocs if you don't mind :)
> >> >
> >> > Sorry :) I already registered on storm, but I had no access to create.
> >> > Thanks for review, I'll update proposal accordint to your requiments.
> >>
> >> No worries.
> >>
> >> > And question: could we throw Windows or MacOS or both versions from
> >> > timeline, and develop them after summer?
> >>
> >> Yes, I think that's fine. I think getting one platform to completion
> >> would be a great accomplishment and would lay the groundwork and
> >> improve the momentum to getting the subsequent platforms there.
> >>
> >> -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
> >
> ___
> 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

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

[Tom Ritter]

On 1 April 2017 at 09:22, Nur-Magomed  wrote:
> Hi Tom,
> I've updated Proposal[1] according to your recommendations.
>
> 1) https://storm.torproject.org/grain/ECCJ3Taeq93qCvPJoWJkkY/

Looks good to me!

> 2017-03-31 19:46 GMT+03:00 Tom Ritter :
>>
>> On 31 March 2017 at 10:27, Nur-Magomed  wrote:
>> >> I think we'd want to enhance this form. IIRC the 'Details' view is
>> >> small and obtuse and it's not easy to review. I'm not saying we
>> >> _should_ create these features, but here are a few I brainstormed:
>> >
>> > Yes, actually that form only shows "Key: Value" list, we can break it
>> > down
>> > in several GroupBoxes which consist of grouped data field and checkboxes
>> > to
>> > include.
>> >
>> >> Let's try and avoid GDocs if you don't mind :)
>> >
>> > Sorry :) I already registered on storm, but I had no access to create.
>> > Thanks for review, I'll update proposal accordint to your requiments.
>>
>> No worries.
>>
>> > And question: could we throw Windows or MacOS or both versions from
>> > timeline, and develop them after summer?
>>
>> Yes, I think that's fine. I think getting one platform to completion
>> would be a great accomplishment and would lay the groundwork and
>> improve the momentum to getting the subsequent platforms there.
>>
>> -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
>
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[Nur-Magomed]

Hi Tom,
I've updated Proposal[1] according to your recommendations.

1) https://storm.torproject.org/grain/ECCJ3Taeq93qCvPJoWJkkY/

2017-03-31 19:46 GMT+03:00 Tom Ritter :

> On 31 March 2017 at 10:27, Nur-Magomed  wrote:
> >> I think we'd want to enhance this form. IIRC the 'Details' view is
> >> small and obtuse and it's not easy to review. I'm not saying we
> >> _should_ create these features, but here are a few I brainstormed:
> >
> > Yes, actually that form only shows "Key: Value" list, we can break it
> down
> > in several GroupBoxes which consist of grouped data field and checkboxes
> to
> > include.
> >
> >> Let's try and avoid GDocs if you don't mind :)
> >
> > Sorry :) I already registered on storm, but I had no access to create.
> > Thanks for review, I'll update proposal accordint to your requiments.
>
> No worries.
>
> > And question: could we throw Windows or MacOS or both versions from
> > timeline, and develop them after summer?
>
> Yes, I think that's fine. I think getting one platform to completion
> would be a great accomplishment and would lay the groundwork and
> improve the momentum to getting the subsequent platforms there.
>
> -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

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

[Tom Ritter]

On 31 March 2017 at 10:27, Nur-Magomed  wrote:
>> I think we'd want to enhance this form. IIRC the 'Details' view is
>> small and obtuse and it's not easy to review. I'm not saying we
>> _should_ create these features, but here are a few I brainstormed:
>
> Yes, actually that form only shows "Key: Value" list, we can break it down
> in several GroupBoxes which consist of grouped data field and checkboxes to
> include.
>
>> Let's try and avoid GDocs if you don't mind :)
>
> Sorry :) I already registered on storm, but I had no access to create.
> Thanks for review, I'll update proposal accordint to your requiments.

No worries.

> And question: could we throw Windows or MacOS or both versions from
> timeline, and develop them after summer?

Yes, I think that's fine. I think getting one platform to completion
would be a great accomplishment and would lay the groundwork and
improve the momentum to getting the subsequent platforms there.

-tom
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[Nur-Magomed]

> I think we'd want to enhance this form. IIRC the 'Details' view is
> small and obtuse and it's not easy to review. I'm not saying we
> _should_ create these features, but here are a few I brainstormed:

Yes, actually that form only shows "Key: Value" list, we can break it down
in several GroupBoxes which consist of grouped data field and checkboxes to
include.

> Let's try and avoid GDocs if you don't mind :)

Sorry :) I already registered on storm, but I had no access to create.
Thanks for review, I'll update proposal accordint to your requiments.

And question: could we throw Windows or MacOS or both versions from
timeline, and develop them after summer?


2017-03-31 0:44 GMT+03:00 Damian Johnson :

> >> P.S. Have I to send proposal to GSoc as draft?
> >
> > I don't know the answer to this, but hopefully Damian does?
>
> It would be useful if you uploaded a draft to the site, but really the
> only hard requirement is that the proposal is uploaded before the
> deadline. ;)
> ___
> 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

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

[Damian Johnson]

>> P.S. Have I to send proposal to GSoc as draft?
>
> I don't know the answer to this, but hopefully Damian does?

It would be useful if you uploaded a draft to the site, but really the
only hard requirement is that the proposal is uploaded before the
deadline. ;)
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[Tom Ritter]

On 28 March 2017 at 16:22, Nur-Magomed  wrote:
> 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 think we'd want to enhance this form. IIRC the 'Details' view is
small and obtuse and it's not easy to review. I'm not saying we
_should_ create these features, but here are a few I brainstormed:

- A much bigger, more clear Details window with:
- The ability to include to exclude individual sections of the report
(for example, Hardware information would not be included by default,
but maybe we give the user the ability to include it)
- The ability to perform text searches for keywords of their choosing
to spot-check if they are present in the report

Just ideas.

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

Let's try and avoid GDocs if you don't mind :)

I put your document here:
https://storm.torproject.org/shared/DHc8GjUYr8aUNeO2ZcOjTc1xG3pwbburIQoLYB9wkAz
(I don't know if you can create storm documents, but you could use
pad.riseup.net ) and put comments on it.

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

I don't know the answer to this, but hopefully Damian does?

-tom
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [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 :

> 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

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

[Georg Koppen]

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




signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[Nur-Magomed]

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.

Regards

Nur-Magomed

2017-03-20 18:18 GMT+03:00 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:
>
> 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  wrote:
> >
> >
> >> On 19 Mar 2017, at 19:02, Nur-Magomed  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@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

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

[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:

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  wrote:
>
>
>> On 19 Mar 2017, at 19:02, Nur-Magomed  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@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[teor]

> On 19 Mar 2017, at 19:02, Nur-Magomed  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




signature.asc
Description: Message signed with OpenPGP
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev