Sid: I think it would make sense to tie this into Telemetry pings. Although this is a different kind of data than the original intent, it seems to make sense. Having all of the "misbehavior attributes of Firefox" reported by the same service is clear and clean and makes it much easier for us to keep tabs on what we collect.
DEinspanjer 19:17, 13 June 2011 (PDT) I'm not sure if the browser code that supports Telemetry is useful for Syncorro. It is designed to collect data in the background and send it in once per day. That said, the backend that Metrics built for Telemetry is very suitable for this purpose. It is basically a lightweight REST service that can be easily configured to persist the payloads to a variety of backends. We have ones written to persist to HBase (used by Telemetry) and ElasticSearch (used by Socorro). We could either use one of those backends or make a new one that writes to some other backend more useful to you.
Questions to answer
always on and not configurable,
Sid: No. Users should always have a way to opt out of data collection
ask after every error (with the option to remember the user's choice for future incidents),
Sid: This sounds painful if there are lots of errors. If the incidence of errors is low, this would make sense.
philikon: Yes, we want to keep the rate low. We've already put the first improvements in place for Firefox 7 to make sure we don't spam the user with errors. This option would be the best analogy to the crash reporter where upon each crash, we ask the user to submit a report.
Sid: Good plan. I recommend running a test pilot study to determine probable report rate and make sure that errors are infrequent. If they prove infrequent, this is probably the best route to obtain opt-in.
off by default and opt in,
on by default and opt out?