Project

General

Profile

Bug #64392

Make crash reporting opt-in and prompt for choice

Added by David Beitey 12 months ago. Updated 8 months ago.

Status:
Done
Priority:
No priority
Assignee:
Vladimir Vinogradenko
Category:
Middleware
Target version:
Seen in:
Severity:
Medium
Reason for Closing:
Reason for Blocked:
Needs QA:
No
Needs Doc:
No
Needs Merging:
No
Needs Automation:
No
Support Suite Ticket:
n/a
Hardware Configuration:
ChangeLog Required:
No

Description

On my install of the recently-released FreeNAS 11.2, I recently failed to to enter the correct password on login. When looking at my browser console for another reason, I noticed a 3rd party HTTP request attempting to take place on the page:

https://sentry.ixsystems.com/api/3/store/?sentry_version=7&sentry_client=raven-js%2F3.22.1&sentry_key=e3a2219083e241589cb154b90feeb26c

This appears to have been triggered by the authentication failure, which throws an error in the console of "Not Authenticated", with a bunch of associated UI data. A quick grep of the webui codebase seems that it stems from here: https://github.com/freenas/webui/blob/freenas/11.2-stable/src/environments/environment.prod.ts#L33

I understand that Sentry.io is error-reporting software but this is a privacy concern as personal & identifying data is being disclosed without consent. In this specific instance, I don't have details of exactly what data is/would have been captured about my login attempt by Sentry/Raven as the sending was blocked. However, it is a fair expectation that all details of my personal server, particularly login attempts, usernames and passwords (whether correct or not), are sensitive & should be private by default. I can understand some users may wish to share error reporting data, but reports should only be sent if a user has opted in & is explicitly saying that this is okay.

A second instance of the sentry.ixsystems.com domain shows up here: https://github.com/freenas/freenas/blob/a440d4d9d5177204d17032c23cba9fd8de57a64e/src/middlewared/middlewared/logger.py#L54
I'm not sure of what specifics of crashes this code is reporting or if it gets used at all now, but the same philosophy should apply. I see in this code that crash reporting can be disabled if the right sentinel file exists, but one should not be expected to have read this far into (or indeed any of) the source code to use FreeNAS privately.

In short, all error reporting should be opt-in with a clear explanation as to what data would be captured, where it would be sent and when reporting occurs if said setting was enabled.

What are your thoughts?


Related issues

Related to FreeNAS - Feature #83588: Add crash reporting opt-out to new UIClosed

History

#1 Updated by Dru Lavigne 12 months ago

  • Category changed from OS to Middleware
  • Assignee changed from Release Council to William Grzybowski

#2 Updated by William Grzybowski 12 months ago

  • Status changed from Unscreened to Screened
  • Target version changed from Backlog to 11.3

The only thing being sent are software tracebacks/exceptions with small metadata. Critical information like password should not be sent (obivously).

I agree user should have the ability to disabled that. That being said the information we are given is very valuable and has allowed us to provide a much more robust product to the community. I fear having this be opt-in we would have these dropped by 90%+.

I would rather have this being an opt-out and an opt-in kind of thing.

#3 Updated by William Grzybowski 12 months ago

  • Assignee changed from William Grzybowski to Vladimir Vinogradenko
  • Severity changed from New to Medium

#4 Updated by David Beitey 12 months ago

Just to clarify, the most important thing is obviousness and transparency. Zoneminder has done a solid job with their recent telemetry changes (https://github.com/ZoneMinder/zoneminder/issues/1229). Unfortunately, there's no screenshot of ZM's implementation but they prompt you to make a choice on first run and you can't continue until you do. It's akin to this: https://github.com/ZoneMinder/zoneminder/issues/1229#issuecomment-169520581 -- presenting the user with a full explanation of what data is being sent, when, to whom and why, and giving users the choice of sending the data or not.

I was suggesting opt-out be the default in case of opt-out being hard to find or enact (eg FreeNAS's /tmp/.crashreporting_disabled sentinel files or previous option in the settings). However, if clearly explained and easily changed later, it would be acceptable for a checkbox or drop-down menu to have Enabled as the default choice.

#5 Updated by Bug Clerk 9 months ago

  • Status changed from Screened to Ready for Testing

#6 Updated by Bug Clerk 9 months ago

  • Target version changed from 11.3 to 11.3-BETA1

#7 Updated by Vladimir Vinogradenko 9 months ago

  • Related to Feature #83588: Add crash reporting opt-out to new UI added

#8 Updated by Dru Lavigne 9 months ago

  • Subject changed from Make error/crash reporting opt-in & make behaviour obvious to Make crash reporting opt-in and prompt for choice
  • Status changed from Ready for Testing to Done
  • Needs QA changed from Yes to No
  • Needs Doc changed from Yes to No
  • Needs Merging changed from Yes to No

#10 Updated by David Beitey 9 months ago

Thanks for adding the option to the settings. Just to clarify, are there still changes coming to the web UI to control if error reports are sent to Sentry (eg https://github.com/freenas/webui/blob/freenas/11.2-stable/src/environments/environment.prod.ts#L33)? As for the user be prompted to make the choice regarding error/crash reporting, how does that look?

The only thing being sent are software tracebacks/exceptions with small metadata. Critical information like password should not be sent (obivously).

The current help text in that PR mentions that crash reports are anonymous. I'm not sure how middlewared's crash reporter works, but the Sentry/Raven error reporter isn't necessarily so. Since Raven is just capturing a JS exception, there can be install-specific details like hostname or other identifiers in an exception message or thrown object.

For example, if I force an exception due to a network error, this is what my FreeNAS UI throws:

Can’t establish a connection to the server at wss://my.domain.example.com/websocket.   main.000000000000000.bundle.js:1:4437469

Server/hostname mightn't be overly sensitive to some, but it's identifying info all the same.

As mentioned before, an explanation about what info could/would be captured, where it gets sent and when reporting occurs would be good to clarify when the user is making the choice of enabling/disabling error reporting.

#11 Updated by Vladimir Vinogradenko 9 months ago

David, thank you for your concern and help! We'll make UI, tooltips and documentation changes in separate related ticket: https://redmine.ixsystems.com/issues/83588

#12 Updated by Dru Lavigne 8 months ago

  • Target version changed from 11.3-BETA1 to 11.3-ALPHA1

Also available in: Atom PDF