The snappy team would like to continue getting information from the chromehang data without necessarily fixing all of the currently identified issues. This means we need to submit reports without actually crashing/killing the browser. Taras has proposed that we auto-submit these reports without any UI if the user has the telemetry pref enabled. This will require privacy review, because a minidump can contain arbitrary personal data and I believe that other forms of telemetry do not have this privacy "risk". Note that the reports will not be sent to the standard telemetry server but to the crash-stats server.

(In reply to Benjamin Smedberg [:bsmedberg] from comment #0) > This will require privacy review, because a minidump can contain arbitrary > personal data and I believe that other forms of telemetry do not have this > privacy "risk". Note that the reports will not be sent to the standard > telemetry server but to the crash-stats server. I think it would be against the principles stated in http://blog.mozilla.com/privacy/2011/01/12/mozillas-privacy-data-operating-principles/ to enable this for users who opted in under the current telemetry privacy policy, because the opted in under a policy that said "The only Potentially Personal Information sent to Mozilla when this functionality has been enabled is IP addresses". I think it would make sense to treat this as a separate setting from the kind of telemetry that really won't contain Potentially Personal Information other than the IP address.

I agree with hsivonen. If we want to collect "arbitrary personal data" via telemetry, we'll have to update the privacy policy and be straightforward about this in the opt-in.

BTW, couldn't hang stacks be gathered without risking leaking "arbitrary personal data" by shipping symbols to end users, walking the stack on the end users' computers and not sending minidumps elsewhere for processing?

re comment 3, not effectively, no: the engineering work required would be much more than just putting up a heavyweight UI as in bug 705888. It would at least require downloading significant amounts of data over secure mechanism and would require a security audit of the stack walker code.

I believe that this particular version of the bug is WONTFIX. There are other bugs on a heavier UI model.

Benjamin we were discussing turning on framepointers on a branch so we could gather this with built in backtrace apis. Will that not work for this?

You would need something pretty different from the current chromehang code: the Windows CaptureStackBackTrace function only works on the *current* thread, so you can't use that directly. We could perhaps use the profiling code.

In any event, if you want to do something else, you should file a new bug.