Privacy concerns regarding Sentry Error Tracking

[dozro]

I saw that @Just-Insane added sentry Error Tracking in #280. And decided it to be opt-out.

I think it should be an explicit opt-in.

And also which backend are we using? The sentry backend or a oss alternatieve?

We should also consider that opt-out is always on thin ice regarding GDPR...

[nushea]

i was really bothered by it too because i hate having any sort of telemetry in my software and the fact that it uses corporate "implied consent" language really is just not good in my opinion, like i see that a docs page was added to document this behavior too

(text from the new docs)
| Got it / × (close) | Sets sable_sentry_enabled = true in localStorage and dismisses the banner with a fade-out animation. Reporting continues. |
| Opt out | Sets sable_sentry_enabled = false and reloads the page. Sentry is disabled for this user going forward. |

tracking of any form should be opt-in only and very explicit, there is no reason to be like microsoft and track by default, especially not the consent being given on just closing the notification

Also in the same thought, it should assume youre going to opt-out and refresh the page on opting in

[MrRubberDucky]

Yeah, imo if any feature sends user data somewhere to any instance that's not controlled by X instance administrator then it should be users own decision if they wanna enable it, or not. I would also add to it that clearly communicating that enabling such feature may/will report anonymized diagnostic data back to an remote server, as right now the message just reads Send anonymous crash reports to help improve Sable. No messages, room names, or personal data are included. but not where those reports are explicitly sent.

Some end-users may not be knowledgable what a "Sentry" is so informing them in the feature description is the best way to ensure that no one misunderstands this option afterwards.

[dozro]

Yeah, imo if any feature sends user data somewhere to any instance that's not controlled by X instance administrator then it should be users own decision if they wanna enable it, or not. I would also add to it that clearly communicating that enabling such feature may/will report anonymized diagnostic data back to an remote server, as right now the message just reads Send anonymous crash reports to help improve Sable. No messages, room names, or personal data are included. but not where those reports are explicitly sent.

Some end-users may not be knowledgable what a "Sentry" is so informing them in the feature description is the best way to ensure that no one misunderstands this option afterwards.

@MrRubberDucky yeah, i also think that sending data to any server, not being your homeserver or where sable is, should be an explicit and informed opt-in.

[hazre]

Yeah, imo if any feature sends user data somewhere to any instance that's not controlled by X instance administrator then it should be users own decision if they wanna enable it, or not. I would also add to it that clearly communicating that enabling such feature may/will report anonymized diagnostic data back to an remote server, as right now the message just reads Send anonymous crash reports to help improve Sable. No messages, room names, or personal data are included. but not where those reports are explicitly sent.

Some end-users may not be knowledgable what a "Sentry" is so informing them in the feature description is the best way to ensure that no one misunderstands this option afterwards.

We have dedicated a privacy policy, that shows up as learn more button, which exactly states where and who the error tracking is sent to.

[hazre]

Which is also available in the settings page, in case you miss it.

(edit by @dozro : the image size was a bit to big lol)

[hazre]

Technically we don't need any explicit consent since we don't track any PIIs, it's more of a courtesy (sorry that was out of pocket). But if there is a UI/UX thing that we can improve here, that communicates it better, we are very open to that.

[hazre]

I urge everyone to read it privacy policy, it's made to be easy to understand and short. https://github.com/SableClient/Sable/blob/dev/docs/PRIVACY.md

It answers all the concerns, especially on self hosted instances

[hazre]

i was really bothered by it too because i hate having any sort of telemetry in my software and the fact that it uses corporate "implied consent" language really is just not good in my opinion, like i see that a docs page was added to document this behavior too

(text from the new docs) | Got it / × (close) | Sets sable_sentry_enabled = true in localStorage and dismisses the banner with a fade-out animation. Reporting continues. | | Opt out | Sets sable_sentry_enabled = false and reloads the page. Sentry is disabled for this user going forward. |

tracking of any form should be opt-in only and very explicit, there is no reason to be like microsoft and track by default, especially not the consent being given on just closing the notification

Also in the same thought, it should assume youre going to opt-out and refresh the page on opting in

I agree that the wording can be made better there. It will addressed in the next update

[dozro]

I would suggest reverting #280 until the concerns, especially regarding the effectiveness of the opt-out, have been addressed in a suitable manner

[hazre]

#333 is now up that should address these issues.