Software Removal | Movim serious privacy violations #1583

Closed
opened 2019-12-09 23:30:57 +00:00 by apimon · 5 comments
apimon commented 2019-12-09 23:30:57 +00:00 (Migrated from github.com)

Description

Please remove Movim from this list, serious privacy violations, does save user ip address and geo coordinates without even asking, see https://github.com/movim/movim/issues/892 - this is even more problematic as it will lead users who want to self-host into serious trouble potentially.

Also I would like to strongly suggest to at least conduct some auditing of basic (mis-)features before putting tools with such blatant privacy violations on this list. Yes, I know this is a lot of work.

## Description Please remove Movim from this list, serious privacy violations, does save user ip address and geo coordinates without even asking, see https://github.com/movim/movim/issues/892 - this is even more problematic as it will lead users who want to self-host into serious trouble potentially. Also I would like to strongly suggest to at least conduct some auditing of basic (mis-)features before putting tools with such blatant privacy violations on this list. Yes, I know this is a lot of work.
apimon commented 2019-12-09 23:37:22 +00:00 (Migrated from github.com)

I need to add that in https://github.com/movim/movim/issues/63 you can see developers of that software talking about doing "end-to-end" encryption "on the server" by PHP - what makes absolutely no sense and shows that these people have no understanding of privacy or encryption and should not do what they are doing or at least learn some very basic things before going ahead with what they are doing. This is dangerous.

I need to add that in https://github.com/movim/movim/issues/63 you can see developers of that software talking about doing "end-to-end" encryption "on the server" by PHP - what makes absolutely no sense and shows that these people have no understanding of privacy or encryption and should not do what they are doing or at least learn some very basic things before going ahead with what they are doing. This is dangerous.
edhelas commented 2019-12-09 23:57:33 +00:00 (Migrated from github.com)

@apimon did you even read #63 ? Do you think that in those pages and pages of discussions, since 2015 I'm not even aware today about this security thing ? Seriously ?

https://github.com/movim/movim/issues/63#issuecomment-253971839 => 2016

This also means that the XMPP session and processing is done server-side. The end-to-end encryption protocols are always designed with the idea that "where the message is send/arrive" = "where the message is encrypted/decrypted". This is not the case with Movim. A copy of the messages are stored, unencrypted, in a database (that way you can reload the page, do pagination… ). If I respect the OMEMO/OTR rules, I could encrypt/decrypt them on the server but this means that they still will be saved and sent in plain text to the browser (with HTTPS on top), so basically it's not end to end anymore.

It's been years that I have pressure about this E2EE thing, years of discussions, and ideas of how to handle it. I didn't even started to implement it at the moment, didn't even expressed my plan about it and you're directly drawing conclusions. Seriously ?

Yes I'm planning to do E2EE server side, by saying it clearly to the user, and many were fine with that, because in some cases their servers is hosted at their place, or in their company and they can trust it. What is the difference security wise with a E2EE done in JS, where the JS is actually delivered by a web server that can be compromised ?

For the movim/movim#892 issue, yes it was not clearly explained, but here you didn't even noticed that this thing is actually happening on the movim.eu XMPP server, that is a totally different project than the Movim sourcecode. So yes I'll explain it clearly, but it's not related at all with Movim platform that I'm developing for 10 years.

Before doing any criticism and running everywhere maybe you should simply come talk with us and handle things more quietly.

@apimon did you even read #63 ? Do you think that in those pages and pages of discussions, since 2015 I'm not even aware today about this security thing ? Seriously ? https://github.com/movim/movim/issues/63#issuecomment-253971839 => 2016 > This also means that the XMPP session and processing is done server-side. The end-to-end encryption protocols are always designed with the idea that "where the message is send/arrive" = "where the message is encrypted/decrypted". This is not the case with Movim. A copy of the messages are stored, unencrypted, in a database (that way you can reload the page, do pagination… ). If I respect the OMEMO/OTR rules, I could encrypt/decrypt them on the server but this means that they still will be saved and sent in plain text to the browser (with HTTPS on top), so basically it's not end to end anymore. It's been years that I have pressure about this E2EE thing, years of discussions, and ideas of how to handle it. I didn't even started to implement it at the moment, didn't even expressed my plan about it and you're directly drawing conclusions. Seriously ? Yes I'm planning to do E2EE server side, by saying it clearly to the user, and many were fine with that, because in some cases their servers is hosted at their place, or in their company and they can trust it. What is the difference security wise with a E2EE done in JS, where the JS is actually delivered by a web server that can be compromised ? For the movim/movim#892 issue, yes it was not clearly explained, but here you didn't even noticed that this thing is actually happening on the movim.eu XMPP server, that is a totally different project than the Movim sourcecode. So yes I'll explain it clearly, but it's not related at all with Movim platform that I'm developing for 10 years. Before doing any criticism and running everywhere maybe you should simply come talk with us and handle things more quietly.
Natureshadow commented 2019-12-10 06:47:20 +00:00 (Migrated from github.com)

s/quiet/calm/. It'd be ok to do it transparently, if it were presented based on facts and in a constructive manner.

s/quiet/calm/. It'd be ok to do it transparently, if it were presented based on facts and in a constructive manner.
Mikaela commented 2019-12-10 16:20:50 +00:00 (Migrated from github.com)

Reading the linked issues and comments, if I understood correctly there are two issues:

  • Movim checks geolocation of your IP address and doesn't mention it on the privacy policy (yet). https://github.com/movim/movim/issues/892#issuecomment-563484329
    • I don't see this as a reason for delisting assuming they are going to fix their privacy policy.
  • Movim's OMEMO may be storing keys server-accessible in the future. https://github.com/movim/movim/issues/63#issuecomment-419571967
    • I would consider this as a reason for delisting if we were listing Movin on the instant messaging page, but it appears to be on social media instead, as we require E2EE from not-team chats. If Movim will do this, then in my opinion we should add a warning label.

@privacytoolsIO/editorial I vote for closing this issue.

Reading the linked issues and comments, if I understood correctly there are two issues: * Movim checks geolocation of your IP address and doesn't mention it on the privacy policy (yet). https://github.com/movim/movim/issues/892#issuecomment-563484329 * I don't see this as a reason for delisting assuming they are going to fix their privacy policy. * Movim's OMEMO may be storing keys server-accessible in the future. https://github.com/movim/movim/issues/63#issuecomment-419571967 * I would consider this as a reason for delisting *if* we were listing Movin on the instant messaging page, but it appears to be on social media instead, as we require E2EE from not-team chats. If Movim will do this, then in my opinion we should add a warning label. @privacytoolsIO/editorial I vote for closing this issue.
Mikaela commented 2019-12-18 08:46:22 +00:00 (Migrated from github.com)

Closing for inactivity in all associated issues and I imagine that the team has had time to see this in 8 days.

Closing for inactivity in all associated issues and I imagine that the team has had time to see this in 8 days.
This repo is archived. You cannot comment on issues.
No Milestone
No Assignees
1 Participants
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: privacyguides/privacytools.io#1583
No description provided.