search

RocketChat / Rocket.Chat.Electron

Official OSX, Windows, and Linux Desktop Clients for Rocket.Chat
https://rocket.chat/
MIT License
1.59k stars 704 forks source link

Remove Bugsnag -- or allow to disable it at the very least. #2099

Closed tmartincpp closed 3 years ago

tmartincpp commented 3 years ago

My Setup

Description

Bugsnag should be removed from Rocket.Chat Electron or we should be able to completely disable it using a simple option.

Current Behavior

Datas are being sent to third party WITHOUT user (or admin) approval.

Expected Behavior

Please remove Bugsnag or allow to disable it.

I know that Rocket.Chat Electron is one of RC's part the least maintained but still, it feels really unacceptable to use Bugsnag like it is right now.

Related :

tmartincpp commented 3 years ago

@johncrisp @debdutdeb : could you please contact the team about this ?

It feels really bad for a Open Source solution like RC to have that kind of behavior IMO (especially in a professional environment).

Thanks.

CvH commented 3 years ago

reading https://docs.bugsnag.com/legal/privacy-policy/ is rather scary, no mentions of GPDR (or I didn't found it) Looking at the targeted audience this is unacceptable (public facilities/commercial environments usually don't like to get their data tracked) and even more that you can't opt out. Very likely this is even violating EU rights to some extend (GPDR). I have no idea why this kind of privacy data tracking tool has any place in OSS in general.

Stated at bugsnag website: If you are under the age of 18, you must have your parent’s permission to access the Services. So in other words this could lead to the point where you have to disclose the usage of the app to 18+ (at least in the EU) due that usage. There are other "nice" stuff burrowed there too, so in general this is something nobody wants at their device at all.

would be nice if someone from the team could make some comment about this @johncrisp

debdutdeb commented 3 years ago

Good morning CvH and tmartincpp!

I'll forward this to John right away.

Thanks for bringing this forward.

tmartincpp commented 3 years ago

@debdutdeb @johncrisp : any news about this ? Sorry to bump you about this again but bugsnag/legal issues are quite scary.

johncrisp commented 3 years ago

Hi. You don't need to @ anyone thanks - we do watch.

I need to try and speak to the Product Team about this as I have no idea.

In the short term the simple answer is just don't use the app if it concerns you. Just use a browser. SImple as that. That stops all the worries.

Note also here on GDPR in the terms.

https://docs.bugsnag.com/legal/dpa/

  1. Definitions and Interpretations 1.1 Definitions ..... including but not limited to the General Data Protection Regulation 2016/679 of the European Parliament and of the Council on the protection of natural persons with regard to the processing of personal data and on the free movement of such data (the “GDPR”).....

So you are technically covered under GDPR.

Another thing you could do is do the open source thing, take the code, and build it yourself. You can then configure it how you want.

https://stackoverflow.com/questions/31247083/disable-bugsnag-on-certain-instances

However, this really forks off into a discussion on how open source works and is off topic, so it is something you can chat with us about in depth on open.rocket.chat of the forums.

In the meantime I'll try and find an answer for you which might take a few days.

tmartincpp commented 3 years ago

Hi. You don't need to @ anyone thanks - we do watch.

I need to try and speak to the Product Team about this as I have no idea.

Again sorry to @ you, the lack of answers in github issues is one of RC weakness IMO, it's really hard to know if an issue is really getting investigate or not.

In the short term the simple answer is just don't use the app if it concerns you. Just use a browser. SImple as that. That stops all the worries.

For security reasons, some companies forbid RC access through web browsers , this is where RC Electron comes handy, but they might be quite scared once they discover bugsnag usage.

In my experience, in an enterprise environment, there is nothing like "simple as that" unfortunately.

Note also here on GDPR in the terms.

https://docs.bugsnag.com/legal/dpa/

1. Definitions and Interpretations
   1.1 Definitions
   ..... including but not limited to the General Data Protection Regulation 2016/679 of the European Parliament and of the Council on the protection of natural persons with regard to the processing of personal data and on the free movement of such data (the “GDPR”).....

So you are technically covered under GDPR.

Bugsnag is quite renown to track users activities and is blacklisted from many lists (ex: pihole).

Also, by forcing Electron's users to use bugsnag, without even warning them, you force them to accept bugsnag's "Data Processing Agreement" ? Quote from the beginning of their DPA: Company is a controller of certain personal data, so, in our cases, does it mean that RC control/own users personal datas where the client is launched (on users computers) ?

Another thing you could do is do the open source thing, take the code, and build it yourself. You can then configure it how you want.

https://stackoverflow.com/questions/31247083/disable-bugsnag-on-certain-instances

Of course some companies can modify RC Electron themselves and maintained it, but many cannot afford to do that.

One of main argument for RC compared to Slack (or others) is privacy, if in the mean time you are using services like bugsnag withtout even warning users, it seems quite weird to me.

If you don't want to remove bugsnag from the client fine, but at least ask for users permissions to send their datas to bugsnag on the first launch for example (declining would close the app).

Of course this is only my opinion.

In the meantime I'll try and find an answer for you which might take a few days.

Thanks, I didn't meant to rush you, I have ways to block bugsnag for most of my users anyway, I just wanted to know if this issue was considered as one or not basically.

johncrisp commented 3 years ago

Thanks for your considered response!!

Again sorry to @ you, the lack of answers in github issues is one of RC weakness IMO, it's really hard to know if an issue is really getting investigate or not.

Yes - I am more than well aware..... ;-)

Since we now have a Community Team we are getting on top of this now, or at least I hope so! We are working hard to respond and hopefully you should have noticed improvements recently.

For security reasons, some companies forbid RC access through web browsers , this is where RC Electron comes handy, but they might be quite scared once they discover bugsnag usage.

I'm a little surprised that they would block normal browsers. Is Rocket.Chat any different from any other site? We'd be interested to know the reasons for that.

Also, by forcing Electron's users to use bugsnag, without even warning them, you force them to accept bugsnag's "Data Processing Agreement" ?

That's an interesting legal point and I will try ask about that. Yes, we could put in an 'accept' option which means like many apps you can't use it unless you do accept.......

mean that RC control/own users personal datas

We have our own privacy policies too.... I think you will find that we do not read or store ANY personal data at all. Yes, if statistics are enable we collect some anonymous usage statistics and that is labelled at install and in the admin section. We don't hide any of that - it is all in the code if you want to check.

Of course some companies can modify RC Electron themselves and maintained it, but many cannot afford to do that.

Again, this comes down to understanding what open source is, or is not. It is not 'free'. The code is open and you are welcome to do whatever you want with it, just as Rocket.Chat does itself.

Please talk to us on open.rocket.chat for a longer discussion.

One of main argument for RC compared to Slack (or others) is privacy, if in the mean time you are using services like bugsnag without even warning users, it seems quite weird to me.

As I said above, you don't have to use the app, or you can build your own version. And see my comment regarding browsers. You have to determine how important these issues are for you and the relative costs and time involved.

Nonetheless I will raise the comments with the Product Team in due course and see what their response is.

Note that this should really be closed as a duplicate in favour of 2005 but I will leave it in abeyance for now.

CvH commented 3 years ago

I guess its also a bit about sending a message. You state at your website:

We do not sell your personal data. 
Our business model is to provide you with a free edition and we charge you for extra services or features, according to the plan you choose. 
What you process within Rocket.Chat is yours and stays yours.

In the current light this is pretty wrong. Especially there is no technical need for bugsnag anyway - so you add a privacy tracking tool for no good reason. This is just not fitting with "privacy in mind" that surrounds RC.

Yes, we could put in an 'accept' option which means like many apps you can't use it unless you do accept.......

To be realistic this won't happen, guess what would happen if you add a screen at the start of the program. you need to accept installing a privacy tracking tool or you can't use the RC electron app Also the GDPR forbids this kind of "choice".

Bugsnag might be valuable in development but this should not get rolled, unasked, into public releases.

tmartincpp commented 3 years ago

For security reasons, some companies forbid RC access through web browsers , this is where RC Electron comes handy, but they might be quite scared once they discover bugsnag usage.

I'm a little surprised that they would block normal browsers. Is Rocket.Chat any different from any other site? We'd be interested to know the reasons for that.

It's not about RC itself, it's about lowering the risks by splitting activities/applications.

For example an enterprise might not want to have instant messaging and public websites running on the same browser/application, so, if the application is compromised, internal datas should be safe.

In some cases, companies policy might go even further :

So, if one of this element is compromised, there is a good chance that others are not.

Your others answers are also welcome and appreciated, I'm only responding to this part to stay in the topic.

tmartincpp commented 3 years ago

For those who want to disable Bugsnag in Rocket.Chat client : you can build Rocket.Chat Electron yourself, it will disable Bugsnag without modifying any source code (as long as RC developers don't force it in a future release :).

Example (in this case I want a Debian package) :

 curl -L https://github.com/RocketChat/Rocket.Chat.Electron/archive/refs/tags/3.4.0.tar.gz -o /tmp/RCE.tar.gz
 tar xzf /tmp/RCE.tar.gz
 cd Rocket.Chat.Electron-3.4.0

 yarn
 export NODE_ENV=production 
 yarn build
 yarn release --linux deb
 ls -lrt dist/
debdutdeb commented 3 years ago

Hi @tmartincpp , @CvH

I was just typing this and @tmartincpp replied :p I had to go to a meeting.

Anyway, first of all, if what Martin suggested there works, then great, whoever's reading this, sure try it :)

So first of all, this issue is being worked on, as we speak. The first task was created internally on April! After an internal discussion about this.

I did not know about this until 30 minutes ago. We've had problems with community and internal team communication as I believe all of you know already. I'm just now trying to fix this, and this information is one proof of that.

Another thing is why is it taking so long? I will get you an answer to that SOON. I'm fixing a meeting with the developer, and even he might come in and respond. Currently there's just one person working on the whole project, we're planning to grow the team obviously, just don't know when that'll materialise. Prioritizing among 649 issues for a single person, is really hard, and that's what we'll be working on in the coming days.

Finally, I'd like to personally invite everyone here on this conversation to our open server, if you're already there, drop me a DM please (at)debdut.chakraborty . Where this project goes, how it moves forward, how can we help the users such as yourself - I need your input.

I apologize for us taking so long to update you on this, communicate the progress. John also didn't know this unfortunately. Everyone'd been stuffed for so long, and sometimes life just takes over. Not an excuse, but it is how it is unfortunately.

Let's see how we can fix this and move forward.

THANKS :)

tmartincpp commented 3 years ago

I want to thank you about RC Electron 3.5.0, I have seen that the option has been added :+1:

The only drawback I have seen so far is that if I force "isReportEnabled" to false (and "isFlashFrameEnabled" to true) in configuration file before upgrading to 3.5.0, the values will be reset to respectively true and false once 3.5.0 is started...

It seems related to the 'internal.migrations.version' value of the conf file, if it's not set to "3.5.0" (at least I guess), isReportEnabled and isFlashFrameEnabled will be override on first 3.5.0 launch.

Not ideal, but still, it is a very good improvement IMO. Thanks again.