Comment by pilif | Hacker News Reader

Comment by pilif | Hacker News Reader

Parent Full thread

Contrarian opinion/question: Out of the software developers reading the comments here: Who is offering an op-out (much less an opt-in into) from their crash reporting solution they have included in their software?

And of those who do actually offer an op-out: Who is annoyed about not being able to debug an issue because the crash they know is happening only seems to be happening on clients who have opted out?

And my second question to all the non-developers out there: Who here is annoyed about crashes on their machine that "never seem to get fixed" as if the vendor "didn't care about getting crashes fixed" in software that offered and explicit opt-in and they didn't opt into "spying" by the vendor? Who remembers not opting in and remembers to rectify that when the crash happens?

It's very easy to stand on the hill of righteousness and yell at a vendor implementing crash reporting, but before doing so ask yourself: Are you collecting crash reports? Do you wish you had crash reports? Are you unhappy about crashes on your machine not being fixed?

If any of those are true, then you better not complain about a vendor adding crash reporting to their products.

Do I think this should be opt-outable? Of course. Do I think crash reporting needs to be opt-in? No. Absolutely not because next to nobody will opt in and when crashes happen, nobody will remember their decision.

Make it easy for your customer to get a crash report when one occurs. Make it easy for them to contact your support, whether it is a Github issues page or a professional phone support desk.

Make the report readable by a simple text editor. Let the users have a look at the content inside. If you do need the report, ask them to check it then send it through trusted and encrypted ways like Firefox Send.

There is no need to make an crash report automatically sent to you. No need to fix crashes for users that never cared for reporting them to you. Orient your bandwidth to users that care.

> Make the report readable by a simple text editor. Let the users have a look at the content inside.

how do you explain the concept of a backtrace to an end-user so they can make an informed decision whether it's fine to submit the data or not? How do you do the same with a a full memory dump (if you need one?). How do you expect users to analyze the memory dump for potentially compromising data?

> If you do need the report, ask them to check it then send it through trusted and encrypted ways like Firefox Send.

this works for you and me. It doesn't work even for my coworker. Also: What is the advantage of going through the extra hoop of Firefox Send compared to over plain SSL when you intend the recipient to be able to read the dump anyways?

> No need to fix crashes for users that never cared for reporting them to you

Judging from metrics available to an app I'm working on I would say that users are much more likely to stop using my app completely rather than even bothering to press the "report this issue" bug.

It really depends on your target audience.

But in case of UniFi (as opposed to their AmpliFi line), asking for individual reports to be reported could possibly be feasible given the product audience.

Save the crash report, show me a notification where I can review the data and then decide whether to send it or not.

Yes. Getting this right is that simple.

Where do you show the notification when an AP crashes?

How do you handle users not familiar with the concept of a crash? How do you make sure you get their crash reports? How much are you willing to spend on dealing with edge-cases (like crashing loops and reporting fatigue)?

But yes. I agree that your proposed solution is the friendliest for the subset of total users who are also frequenting HN.

Problem is also that they don't even give you an opt-out button yet:

> If you do not wish to participate/provide this data, we will add an opt-out button in upcoming versions that will make it easy to opt-out of providing this data. In the meantime, you can block traffic from UniFi devices to trace.svc.ui.com.

Wonder what the hurry was to launch such a "feature" that couldn't wait for the opt-out button to be ready. In the meantime they will definitely be able to collect some data from users that still wait for the opt-out button.

The notification can be shown in the unifi controller, and optionally send an email. If you are using the controller you would be expected to understand the concept of a crash report.

If a crash occurs, you can ask to send a report. Maybe after a restart of the application. This is the way I do it and many other software vendors as well. It is a non-excuse for default active telemetry.

Reply on news.ycombinator.com