4

I have some questions regarding whether to crash or report errors to the user. We are developing a web site and mobile clients in which we allow our users to report any bugs and crashes through e-mail. We require the user to send the e-mail from their e-mail account, so they can be identified. Here are some questions regarding it:

  1. We used to send the last stacktrace of java when user presses "send error report" button. As it has only technical details that user may not understand or care about, is it necessary to show this stacktrace to the user?

  2. What if the user is concerned about privacy? Is it good practice to collect stacktraces of crashes and unusual behavior keeping user's privacy in mind? If it's not what are the other alternatives?

  3. For mobile devices what if the user wants to send an error report to the server but there is not any network connectivity, is it necessary to have a record of this type of common errors that is not related to application?

gnat
  • 21,442
  • 29
  • 112
  • 288
Prasham
  • 1,059
  • 10
  • 19
  • 1
    What other "crash report" applications have you seen? Please list some examples and what they do. Please find some specific examples of what other software does and talk specifically about those examples. – S.Lott May 24 '11 at 10:27

3 Answers3

5

My two cents.

Keep in mind, this particular community is likely to be a cross section of programmers, so we aren't your average user. :) I can see reading my own thoughts that I'm answering as the "user who knows how to program", and not a regular human being.

  • We used to send the last stacktrace of java when user presses "send error report" button. As it has only technical details that user may not understand or care about, is it necessary to show this stacktrace to the user?

As a geeky user, I like to have the option (but not the obligation) to see the stacktrace. Oddly, about my best example is Microsoft - when something goes hideously wrong in some cases they give a "see details" button that gives me the stack trace. 9 times out of 10 I'll either not click the button, or click it, stare at it, and send it. But once and a while, I get just enough esoteric information out of it that I can change my behavior and get the app to do what I want.

  • What if the user is concerned about privacy? Is it good practice to collect stacktraces of crashes and unusual behavior keeping user's privacy in mind? If it's not what are the other alternatives?

I think you need to give the user both options and information. To me that's the ethical thing. My Android mobile apps give me a warning, first - "this app will send detailed error information about the state of your device to the company when an error occurs". That's very wordy, I suspect there's a better way to say it.

Then, I think the feature is either a persistent setting and/or a case by case option to turn off the error reporting. Personally, I prefer case by case, since I may make the decision based on current conditions - how big of a problem was it? How high is my bandwidth? etc.

  1. For mobile devices what if the user wants to send an error report to the server but there is not any network connectivity, is it necessary to have a record of this type of common errors that is not related to application?

IMO - for mobile apps, no. To me, there's an implied contract that my mobile apps will not fill my phone with error information just so it can be relayed when connectivity returns. I might expect that from an email app, where I'm trying to send some content, but I don't expect it from errors. I think when you are designing remote error reporting you have to assume you're going to loose a fair number of errors, so the error reports you get at the central server are not representative of every error that ever occurred remotely.

I'm sure mileage varies with the practicality of the system. Fortunately, I can't think of an application in your average mobile phone that is directly connected to the preservation of human life...

bethlakshmi
  • 7,625
  • 1
  • 26
  • 35
3
  1. Always show the stack trace. A magic mail is opening doors for law suits.
  2. Always respect privacy. See point 1 above - that is the option for user to deny sending it to you if they find any private info. Ideally NONE of the parameters should come to you.
  3. Always have an EULA that gets them to agree to this. Again, law suits.
  4. I have seen mobile apps that overwrite a single error file until they get connectivity - I have also seen mobile apps that reserve space in their file format for stats/error info. you could try one of that.
  5. When programs go out, I am assuming your stack trace might not contain all the information you need because of obfuscation etc. So ensure you have your release symbols cached and so on. Try checking out a core dump as a test case for every release - nothing worse than getting a malformed file.
  6. If you are indeed getting stacktraces, then your app might be reverse engineerable. Take care there if you are worried about IP.
Subu Sankara Subramanian
  • 2,438
  • 15
  • 23
  • Concerning point 3: Use a privacy statement instead of the EULA for this purpose. In many countries the EULA is completely meaningless, e.g. if any part of it contradicts local legislation, or if the user has not read and explicitly accepted the EULA before installing the app. Furthermore, mentioning the crash reporting in the privacy statement may be required but not sufficient. So you should still inform the user in the app before any data is sent from the device (e.g. as implied in your point 1.). –  Oct 16 '16 at 10:12
0

In a way the first two mentioned issues are related. i) the user must be given the choice to authorize, or not, the transmission of the error report; ii) the user must be allowed to see the content of the error report before deciding on i), especially due to privacy.

If the user was working on something confidential or typed in some sensitive information, the user does have reasons to be concerned with privacy and should NOT authorize the transmission of the error report. The following paragraph can be found in the privacy statement for the Microsoft Error-Reporting Service:

“Reports might unintentionally contain personal information, but this information is not used to identify you or contact you. For example, a report that contains a snapshot of memory might include your name, part of a document you were working on, or data that you recently submitted to a website. If you host virtual machines using a Windows operating system, reports generated by the Windows operating system for the MER service might include information about virtual machines. If you’re concerned that a report might contain personal or confidential information, you should not send the report.”

In line with thins, there are two important things to consider:

1) some error reporting mechanisms include some logging features to collect reproducibility information, so that the developers are provided with a more complete/useful error report, which arguably raises even bigger concerns regarding privacy;

2) even if the report contains only some "final state" information regarding the error, such as the stack-trace, it is unclear what information it may be revealing. For example, if the error can only be triggered by specific execution paths that in turn are only traversed if the user inputs a limited subset of values or clicked on some particular content, one can deduce such inputs (at least partially) just be the stack trace.

João Matos
  • 101
  • 1