Open newmanw opened 3 years ago
We have similar issues and requirements. It's absolutely not ideal but we are testing jamming the data by DNS.
A note, we have tried to change the Bugsnag key to something that will fail, and when it failed it actually ended up taking down the server or causing other technical problems.
I would argue that it should be addressed in all builds: any communication involving data collection, on the back end with no user visibility or interaction especially, should be opt-in, and very obvious on the installer.
I totally agree. Such a feature should be opt-in or easily deactivatable by the app user at least - but I as an admin would prefer to have the opportunity to exclude it from compiling to be sure it is not part of the app.
Description:
This is related to #2971, but for different reasons. I support a number of government customers that would like to bring Rocket.Chat into their enterprise. One reason why applications like Rocket.Chat are invaluable to the government is the ability to host these systems internally. Restrictions when running on a government system are high, one of these being communication with external 3rd party systems. Unfortunately running with bugsnag enabled is a non starter. Would it be possible to look into adding an option to disable bugsnag when building the whitelabel apps?
Environment Information: