Open paralin opened 8 years ago
Hi @paralin, thank you for your feedback.
Sending errors to Azuki is crucial for us in order to make azk
better. But we understand that maybe this first version of the Crash Reporting system (included in azk v0.17.0
) is not ideal.
We'll work to filter which errors should be sent to Azuki and which can be considered under control.
About the confirmation for sending an crash report, we'd like a feedback from you: during the testing phase of the Crash Reporting system, we noticed that it was too demanding to confirm everytime which crash report either should or shouldn't sent to Azuki (the absence of the filter mentioned above made this even worse).
We're considering to change to the following approach: by default, the Crash Reporting system doesn't ask for confirmation. However, there'll be an option on azk config
command so that the user can define if he/she wants to be asked about sending or not an error to Azuki. What do you think?
Finally, until we add this improvement to azk
, you can disable the Crash Reporting system by running the following command:
azk config set crash_reports.always_send false
You can find more details about the azk config
command here.
As I said, this crash reports is really important for us at Azuki. So, it would be great if you could turn the Crash Reporting system back on once we published those improvements.
Thanks. But submitting non-anonymous data to a third party is something that should always be opt-in and not opt-out. Even if it's annoying, just have at least an initial prompt that asks if it's okay to submit error reports. Every other CLI tool on the planet does this (bower, npm) because people really don't like their data to be automatically shared, especially to a open-source tool.
@paralin, I don't disagree with you, mainly about sensitive data collection. But I'd like to highlight some points:
azk
is open source tool, so this helps on keeping under control which data are collected. And anyone is invited to make questions and purpose improvements for it;One of the main reasons for us to implement this Crash Reporting system was that users were rarely reporting us the problems that was happening with azk
. This was making hard for us to find some issues and prioritize our work.
We took care to collect anonymous data and let the user know about it via the Terms of Use, that the user accepts in the first azk
run.
Finally, none of the points above prevents us to improve azk
and the Crash Reporting system. We can consider to add the crash report sending confirmation and give to the user the possibility of reviewing the collected data before sending them to Azuki.
Right. Still, you should have at least an initial Y/n confirmation the first time the tool is run. That's all I'm saying.
90% of errors with azk are related to what azk is trying to run, not azk itself.
So please stop automatically (with zero confirmation!) submitting bug reports to Azuki including potentially sensitive information with no confirmation.
At least put a [y/N] confirm.