New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add OMEMO encryption [$100] #63

Closed
cart opened this Issue Oct 20, 2015 · 35 comments

Comments

Projects
None yet
@cart

cart commented Oct 20, 2015

I haven't seen end to end encryption mentioned anywhere. For an organization claiming "Our first aim is to protect your privacy" this seems like an important feature. Have you considered implementing XEP-0027? Conversations (the android app) supports it.

@edhelas

This comment has been minimized.

Show comment
Hide comment
@edhelas

edhelas Oct 20, 2015

Member

There's a bounty on BoutySource here https://www.bountysource.com/teams/movim/issues?utm_source=Movim&utm_medium=shield&utm_campaign=bounties_received

Implementing OTR in Movim is really-really tricky because I have to keep the sessions open, even if you reload the pages, something that people do all the time. Other clients don't have this issue because they are running everything in the same "process". So it's definitely not plan yet in Movim. Also OTR has some serious compatibility issues with XMPP (like handling properly the different resources, the history…).

XEP-0027 is Obsolete actually.

Member

edhelas commented Oct 20, 2015

There's a bounty on BoutySource here https://www.bountysource.com/teams/movim/issues?utm_source=Movim&utm_medium=shield&utm_campaign=bounties_received

Implementing OTR in Movim is really-really tricky because I have to keep the sessions open, even if you reload the pages, something that people do all the time. Other clients don't have this issue because they are running everything in the same "process". So it's definitely not plan yet in Movim. Also OTR has some serious compatibility issues with XMPP (like handling properly the different resources, the history…).

XEP-0027 is Obsolete actually.

@edhelas edhelas added the enhancement label Nov 7, 2015

@ghostofkendo

This comment has been minimized.

Show comment
Hide comment
@ghostofkendo

ghostofkendo Nov 12, 2015

It would be great to have end-to-end encryption in Movim.

Although it's somewhat different from Movim, Salut à Toi has OTR support: http://repos.goffi.org/sat/file/8cc7d83141a4/src/plugins/plugin_sec_otr.py
Maybe you could use SàT's implementation as inspiration for Movim?

Also, regarding the difficulty to correctly implement OTR with XMPP, you could perhaps start with a first minimal version without resources support (e.g. an OTR-encrypted conversation is only valid for the resource used to start it), etc.

It would be great to have end-to-end encryption in Movim.

Although it's somewhat different from Movim, Salut à Toi has OTR support: http://repos.goffi.org/sat/file/8cc7d83141a4/src/plugins/plugin_sec_otr.py
Maybe you could use SàT's implementation as inspiration for Movim?

Also, regarding the difficulty to correctly implement OTR with XMPP, you could perhaps start with a first minimal version without resources support (e.g. an OTR-encrypted conversation is only valid for the resource used to start it), etc.

@marxistvegan

This comment has been minimized.

Show comment
Hide comment
@marxistvegan

marxistvegan Nov 20, 2015

edhelas not to belabor the point but there is also this jappix/jappix#305

edhelas not to belabor the point but there is also this jappix/jappix#305

@edhelas

This comment has been minimized.

Show comment
Hide comment
@edhelas

edhelas Nov 21, 2015

Member

Like I said in my previous comment Jappix run in an unique tab so there is no issue to use OTR.js, which is not the case for Movim.

Member

edhelas commented Nov 21, 2015

Like I said in my previous comment Jappix run in an unique tab so there is no issue to use OTR.js, which is not the case for Movim.

@edhelas edhelas closed this Jan 9, 2016

@edhelas edhelas reopened this Jan 10, 2016

@mulles

This comment has been minimized.

Show comment
Hide comment
@mulles

mulles Jan 11, 2016

There is a quite new encryption "method" designed for instant messaging, currently implemented in conversations android app:
https://en.m.wikipedia.org/wiki/OMEMO_(encryption)

It's worth a lock.

mulles commented Jan 11, 2016

There is a quite new encryption "method" designed for instant messaging, currently implemented in conversations android app:
https://en.m.wikipedia.org/wiki/OMEMO_(encryption)

It's worth a lock.

@dkellner

This comment has been minimized.

Show comment
Hide comment
@dkellner

dkellner Jan 23, 2016

+1 for implementing OMEMO instead of OTR.

+1 for implementing OMEMO instead of OTR.

@heyimgay

This comment has been minimized.

Show comment
Hide comment
@heyimgay

heyimgay Jan 27, 2016

I'd look to cyph for inspiration, specifically their websign solution to guaranteeing trust after the initial visit.

I'd look to cyph for inspiration, specifically their websign solution to guaranteeing trust after the initial visit.

@edhelas edhelas added this to the 0.9.1 milestone Mar 30, 2016

@edhelas edhelas self-assigned this Mar 30, 2016

@edhelas

This comment has been minimized.

Show comment
Hide comment
@edhelas

edhelas Mar 30, 2016

Member

I'm currently having a look at a possible OMEMO implementation in Movim.

Member

edhelas commented Mar 30, 2016

I'm currently having a look at a possible OMEMO implementation in Movim.

@edhelas edhelas removed this from the 0.9.1 milestone Apr 7, 2016

@bb010g

This comment has been minimized.

Show comment
Hide comment
@bb010g

bb010g Jun 28, 2016

Any updates on this or areas assistance would be wanted in?

bb010g commented Jun 28, 2016

Any updates on this or areas assistance would be wanted in?

@edhelas

This comment has been minimized.

Show comment
Hide comment
@edhelas

edhelas Jul 24, 2016

Member

Just to keep you updated about this ticket. Movim current architecture is making the implementation of OMEMO (or OTR) quite impossible if I want to do it "right" (without storing risky stuff on the server). So I have no plans to do it for now to do it but I leave the ticket open.

Member

edhelas commented Jul 24, 2016

Just to keep you updated about this ticket. Movim current architecture is making the implementation of OMEMO (or OTR) quite impossible if I want to do it "right" (without storing risky stuff on the server). So I have no plans to do it for now to do it but I leave the ticket open.

@MRZA-MRZA

This comment has been minimized.

Show comment
Hide comment
@MRZA-MRZA

MRZA-MRZA Jul 24, 2016

Do you mean that there is no possibility to store user's keys/fingerptints?

Do you mean that there is no possibility to store user's keys/fingerptints?

@mulles

This comment has been minimized.

Show comment
Hide comment
@mulles

mulles Jul 25, 2016

Thanks for sharing. May you elaborate what the technical challenges/s is/are.

Maybe endtoend encryption is meaningless, when you don't have at least one save place which is permanent to store the password/key needed for encryption.
This seems very hard when you are using ANY webbrowser on ANY computer, but the android app may be capable of.
One could use a new key for every session and safely delete those. If futhermore you want to have message history, the only possibility I see is to save the messages unencrypted and only send them encrypted.

At the end one must say that endtoend is sercurity on top, which is always good, but needs more effort. I say "On top", because if you trust your proper server and the one to whom you send your message the message transfer is already encrypted the whole time when it passes entites you can't trust, as you may not even be able to know them. Thus, this nice decentralized technology can be deployed now, when everybody thinks well when choosing a server.

mulles commented Jul 25, 2016

Thanks for sharing. May you elaborate what the technical challenges/s is/are.

Maybe endtoend encryption is meaningless, when you don't have at least one save place which is permanent to store the password/key needed for encryption.
This seems very hard when you are using ANY webbrowser on ANY computer, but the android app may be capable of.
One could use a new key for every session and safely delete those. If futhermore you want to have message history, the only possibility I see is to save the messages unencrypted and only send them encrypted.

At the end one must say that endtoend is sercurity on top, which is always good, but needs more effort. I say "On top", because if you trust your proper server and the one to whom you send your message the message transfer is already encrypted the whole time when it passes entites you can't trust, as you may not even be able to know them. Thus, this nice decentralized technology can be deployed now, when everybody thinks well when choosing a server.

@rhz

This comment has been minimized.

Show comment
Hide comment
@rhz

rhz Jul 26, 2016

Perhaps end-to-end encryption could be done using PGP like they do in ProtonMail? The idea would be that everything gets stored on the server encrypted and then it's decrypted by the client (the web ui) using javascript and a second password.

rhz commented Jul 26, 2016

Perhaps end-to-end encryption could be done using PGP like they do in ProtonMail? The idea would be that everything gets stored on the server encrypted and then it's decrypted by the client (the web ui) using javascript and a second password.

@edhelas

This comment has been minimized.

Show comment
Hide comment
@edhelas

edhelas Oct 13, 2016

Member

To give a small update here. I've made some try and research regarding E2E encryption in Movim and the current architecture definitely doesn't allow it to be done in a "secure" way. Movim is handling the XMPP connection in PHP and deliver a unique session to several tabs/devices at the same time (on most of the others clients everything is done on one device/computer).
So basically I can't handle a OMEMO/OTR session (that should be done on a device) this way.

Member

edhelas commented Oct 13, 2016

To give a small update here. I've made some try and research regarding E2E encryption in Movim and the current architecture definitely doesn't allow it to be done in a "secure" way. Movim is handling the XMPP connection in PHP and deliver a unique session to several tabs/devices at the same time (on most of the others clients everything is done on one device/computer).
So basically I can't handle a OMEMO/OTR session (that should be done on a device) this way.

@herbsmn

This comment has been minimized.

Show comment
Hide comment
@herbsmn

herbsmn Oct 14, 2016

Hey @iNPUTmice, just wanted to ping you on this thread so you know about the OMEMO implimentation discussion going on.

herbsmn commented Oct 14, 2016

Hey @iNPUTmice, just wanted to ping you on this thread so you know about the OMEMO implimentation discussion going on.

@MRZA-MRZA

This comment has been minimized.

Show comment
Hide comment
@MRZA-MRZA

MRZA-MRZA Oct 14, 2016

What are the advantages of single session for all devices?

What are the advantages of single session for all devices?

@louy2

This comment has been minimized.

Show comment
Hide comment
@louy2

louy2 Oct 15, 2016

@edhelas So what we need is a client side javascript OMEMO implementation?

louy2 commented Oct 15, 2016

@edhelas So what we need is a client side javascript OMEMO implementation?

@edhelas

This comment has been minimized.

Show comment
Hide comment
@edhelas

edhelas Oct 15, 2016

Member

@MRZA-MRZA the architecture of Movim allow him to be used as a "simple website" this means that using a unique cookie, you can open several tabs that will be connected to the same session in the backend. This behavior has been extended in 0.8 to share the same session not only between tabs, but also between browsers (basically your Android phone, your desktop Firefox and your Electron desktop app are sharing the same session cookie and then are perfectly synchronized). That's why Movim can be considered as a "light-client" (and Jappix a "heavy-client"), all the processing and session handling is done server side, the browsers are just displaying the result.

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.

Now let's say that the encryption layer is done in JS, in the browser. Because here we could have several tabs/browsers opened on the same "Movim session" they will not share the same OMEMO/OTR keys/status. Also if you reload the page I'll have to sync the current status somewhere to be sure that I'm not loosing something on the line.

Now imagine that I can successfully do that (which I doubt seriously) and I can decrypt a message in my browser, where can I save it to handle correctly the history ? The current Movim architecture is designed to save all the messages in the server SQL database ? So I'll create a second place to save only the "OMEMO/OTR" messages ? What if I also have unencrypted messages in between (that are coming from the SQL database)… If I send them back to the server SQL database, there's no point of doing this (because the Movim pod will have an unencrypted version), if I don't save them and if you reload your page, you will basically loose your history.

I know that OMEMO is solving most of the issues that OTR had (especially to handle E2E sessions using several XMPP clients at the same time), but it was always designed in a way that the encryption/decryption layer is done at the same place where the XMPP session is handled and where the messages are stored. Movim doesn't have this architecture (and it's not going to have it).

When I'm saying that it's not possible I don't want to tell you that I just don't want to do it because I'm lazy or because it's too difficult. I'd really like to have a nice and standard E2E encryption implementation in Movim like all of you. Just that I prefer to be clear about this point better than having an implementation that is not-secured because I had to do some comprises to do it.

Also, if you really want to do E2E encryption on your XMPP account, Movim doesn't forbid you to use another client to do it, that's the power of XMPP :p

P.S.: @iNPUTmice correct me if I said something wrong or if I totally missed something about this topic

Member

edhelas commented Oct 15, 2016

@MRZA-MRZA the architecture of Movim allow him to be used as a "simple website" this means that using a unique cookie, you can open several tabs that will be connected to the same session in the backend. This behavior has been extended in 0.8 to share the same session not only between tabs, but also between browsers (basically your Android phone, your desktop Firefox and your Electron desktop app are sharing the same session cookie and then are perfectly synchronized). That's why Movim can be considered as a "light-client" (and Jappix a "heavy-client"), all the processing and session handling is done server side, the browsers are just displaying the result.

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.

Now let's say that the encryption layer is done in JS, in the browser. Because here we could have several tabs/browsers opened on the same "Movim session" they will not share the same OMEMO/OTR keys/status. Also if you reload the page I'll have to sync the current status somewhere to be sure that I'm not loosing something on the line.

Now imagine that I can successfully do that (which I doubt seriously) and I can decrypt a message in my browser, where can I save it to handle correctly the history ? The current Movim architecture is designed to save all the messages in the server SQL database ? So I'll create a second place to save only the "OMEMO/OTR" messages ? What if I also have unencrypted messages in between (that are coming from the SQL database)… If I send them back to the server SQL database, there's no point of doing this (because the Movim pod will have an unencrypted version), if I don't save them and if you reload your page, you will basically loose your history.

I know that OMEMO is solving most of the issues that OTR had (especially to handle E2E sessions using several XMPP clients at the same time), but it was always designed in a way that the encryption/decryption layer is done at the same place where the XMPP session is handled and where the messages are stored. Movim doesn't have this architecture (and it's not going to have it).

When I'm saying that it's not possible I don't want to tell you that I just don't want to do it because I'm lazy or because it's too difficult. I'd really like to have a nice and standard E2E encryption implementation in Movim like all of you. Just that I prefer to be clear about this point better than having an implementation that is not-secured because I had to do some comprises to do it.

Also, if you really want to do E2E encryption on your XMPP account, Movim doesn't forbid you to use another client to do it, that's the power of XMPP :p

P.S.: @iNPUTmice correct me if I said something wrong or if I totally missed something about this topic

@louy2

This comment has been minimized.

Show comment
Hide comment
@louy2

louy2 Oct 15, 2016

@edhelas
I see Movim is not a conventional XMPP IM app, which is what excited me to check it out. But part of the reason I am excited about an XMPP SNS is because the E2E crypto XMPP provides may enable a better privacy structure. So as I totally understand the situation, I can't help but feel a bit sad.

That said Movim is still a great step towards that. Will definitely come for inspiration. Take care.

louy2 commented Oct 15, 2016

@edhelas
I see Movim is not a conventional XMPP IM app, which is what excited me to check it out. But part of the reason I am excited about an XMPP SNS is because the E2E crypto XMPP provides may enable a better privacy structure. So as I totally understand the situation, I can't help but feel a bit sad.

That said Movim is still a great step towards that. Will definitely come for inspiration. Take care.

@rhz

This comment has been minimized.

Show comment
Hide comment
@rhz

rhz Oct 15, 2016

What about storing the messages encrypted in the server and using a second password as a master key to decode the encrypted messages in the client?

rhz commented Oct 15, 2016

What about storing the messages encrypted in the server and using a second password as a master key to decode the encrypted messages in the client?

@edhelas

This comment has been minimized.

Show comment
Hide comment
@edhelas

edhelas Nov 5, 2016

Member

I'm definitely closing this ticket. If you still want to talk about it, please join us on our chatroom : movim@conference.movim.eu.

Member

edhelas commented Nov 5, 2016

I'm definitely closing this ticket. If you still want to talk about it, please join us on our chatroom : movim@conference.movim.eu.

@edhelas edhelas closed this Nov 5, 2016

@edhelas

This comment has been minimized.

Show comment
Hide comment
@edhelas

edhelas Jan 20, 2017

Member

Reopening the ticket. I'll give more information about it soon.

Member

edhelas commented Jan 20, 2017

Reopening the ticket. I'll give more information about it soon.

@edhelas edhelas reopened this Jan 20, 2017

@edhelas edhelas changed the title from End to end encryption to Add OMEMO encryption Jan 22, 2017

@edhelas edhelas changed the title from Add OMEMO encryption to Add OMEMO encryption [$30] Jan 24, 2017

@edhelas edhelas added the bounty label Jan 24, 2017

@edhelas edhelas changed the title from Add OMEMO encryption [$30] to Add OMEMO encryption [$50] Jan 30, 2017

@edhelas edhelas changed the title from Add OMEMO encryption [$50] to Add OMEMO encryption [$70] Feb 2, 2017

@tcitworld

This comment has been minimized.

Show comment
Hide comment

So ?

@mrksr

This comment has been minimized.

Show comment
Hide comment
@mrksr

mrksr Feb 12, 2017

@edhelas said on the movim chatroom a few days ago, that he would post an update to this issue after finishing the next release, which according to him is almost done.

mrksr commented Feb 12, 2017

@edhelas said on the movim chatroom a few days ago, that he would post an update to this issue after finishing the next release, which according to him is almost done.

@Dragnucs

This comment has been minimized.

Show comment
Hide comment
@Dragnucs

Dragnucs Feb 12, 2017

@edhelas: i just want to point you to some direction even if i might be totally wrong. We all agree that decryption should be done client side using JavaScript or some browser plugin (JS is better) and not having to store decrypted messages server-side.

Let us assume that Movim is able deliver non-OMEMO message as-is to the browser which just displays them. Then come OMEMO message, encrypted and the server doesn't know what to do with them. Currently, Movim is able to get them to the right chat room and displays them as E2E messages and does not decrypt them. This behavior is key to my understanding, because this can be used to add an HTML class to those messages and then having a JS function/event that looks these particular classes and tries to decrypt them. This decryption would use a key stored in LocalStorage. Now each time Movim is unable to find this information, it needs to create a new one as a new client. In my personal opinion this is better security. Why? Because this means the user is connecting from a new location which Movim has no prior knowledge of, that might be an unwanted connection, and thus, the user's contacts would have to allow a new key and be consious about the situation.

Using local storage would allow all tabs and windows to have the same key, while each tab would have to do the decryption on its own. This is not an issue because this would be on a computer (who opens many tabs of Movim on mobile?)

To summarize, each 'localStorage' is a 'client', and each tab looks for encrypted messages and decrypts them, in-place, regardless of what other tabs have done.

Users would see something like, i load a tab, see some non-OMEMO messages and a bunch of 'decryption in progress' stuff and after about 0.456 seconds, all the loading stuff would be transformed to real messages.

Once I was sitting with a friend using facebook with crappy connection, and basically, when you load your timeline, all you see is what is unchanged all over facebook, a textarea to type your status in and then, a bunch of place holders looking like user posts. After messages are loaded, placeholders are replaced with actual statuses.

@edhelas: i just want to point you to some direction even if i might be totally wrong. We all agree that decryption should be done client side using JavaScript or some browser plugin (JS is better) and not having to store decrypted messages server-side.

Let us assume that Movim is able deliver non-OMEMO message as-is to the browser which just displays them. Then come OMEMO message, encrypted and the server doesn't know what to do with them. Currently, Movim is able to get them to the right chat room and displays them as E2E messages and does not decrypt them. This behavior is key to my understanding, because this can be used to add an HTML class to those messages and then having a JS function/event that looks these particular classes and tries to decrypt them. This decryption would use a key stored in LocalStorage. Now each time Movim is unable to find this information, it needs to create a new one as a new client. In my personal opinion this is better security. Why? Because this means the user is connecting from a new location which Movim has no prior knowledge of, that might be an unwanted connection, and thus, the user's contacts would have to allow a new key and be consious about the situation.

Using local storage would allow all tabs and windows to have the same key, while each tab would have to do the decryption on its own. This is not an issue because this would be on a computer (who opens many tabs of Movim on mobile?)

To summarize, each 'localStorage' is a 'client', and each tab looks for encrypted messages and decrypts them, in-place, regardless of what other tabs have done.

Users would see something like, i load a tab, see some non-OMEMO messages and a bunch of 'decryption in progress' stuff and after about 0.456 seconds, all the loading stuff would be transformed to real messages.

Once I was sitting with a friend using facebook with crappy connection, and basically, when you load your timeline, all you see is what is unchanged all over facebook, a textarea to type your status in and then, a bunch of place holders looking like user posts. After messages are loaded, placeholders are replaced with actual statuses.

@edhelas

This comment has been minimized.

Show comment
Hide comment
@edhelas

edhelas Feb 13, 2017

Member

@Dragnucs, thanks you practically summed-up what I was going to say :) Yes the session, keys and messages will actually stay in localStorage and each Movim "browser" will be an OMEMO client by itself.

Member

edhelas commented Feb 13, 2017

@Dragnucs, thanks you practically summed-up what I was going to say :) Yes the session, keys and messages will actually stay in localStorage and each Movim "browser" will be an OMEMO client by itself.

@edhelas edhelas changed the title from Add OMEMO encryption [$70] to Add OMEMO encryption [$100] Mar 2, 2017

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Mar 3, 2017

Would this still work for those who use privacy modes or otherwise empty out LocalStorage? How would everything know that the new login is a good login?

Because this means the user is connecting from a new location which Movim has no prior knowledge of, that might be an unwanted connection, and thus, the user's contacts would have to allow a new key and be consious about the situation.

If I understand this right, does this mean that people who don't keep LocalStorage intact, would constantly have to have their contacts verify who they are? This seems like it'd be super cumbersome for the average user, and the repetition could easily bring in "thoughtless acceptance" -- much like how people mindlessly press "I Agree" on places with EULAs.

To me, this seems like there's very little safety in the event of an account breach.

ghost commented Mar 3, 2017

Would this still work for those who use privacy modes or otherwise empty out LocalStorage? How would everything know that the new login is a good login?

Because this means the user is connecting from a new location which Movim has no prior knowledge of, that might be an unwanted connection, and thus, the user's contacts would have to allow a new key and be consious about the situation.

If I understand this right, does this mean that people who don't keep LocalStorage intact, would constantly have to have their contacts verify who they are? This seems like it'd be super cumbersome for the average user, and the repetition could easily bring in "thoughtless acceptance" -- much like how people mindlessly press "I Agree" on places with EULAs.

To me, this seems like there's very little safety in the event of an account breach.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Mar 3, 2017

It might be useful to look at how the people at Riot.im handle that: It's no problem for the electron app which remains always logged in. This should be the preferred way to run a privacy-sensitive web app anyway. People who insist on using their browser are warned before logging out and thus invalidating their LocalStorage and are given the chance to export their key material and to re-import it when they re-login, thus making re-verification unnecessary. Of course, if someone insists on removing all data that proves their cryptographic identity in some way, there is no way around revalidation.

ghost commented Mar 3, 2017

It might be useful to look at how the people at Riot.im handle that: It's no problem for the electron app which remains always logged in. This should be the preferred way to run a privacy-sensitive web app anyway. People who insist on using their browser are warned before logging out and thus invalidating their LocalStorage and are given the chance to export their key material and to re-import it when they re-login, thus making re-verification unnecessary. Of course, if someone insists on removing all data that proves their cryptographic identity in some way, there is no way around revalidation.

@edhelas

This comment has been minimized.

Show comment
Hide comment
@edhelas

edhelas Jun 11, 2017

Member

This feature will not be integrated in the upcoming release (0.12), also there is some serious discussions in the XSF regarding the standardization process of OMEMO, I'm waiting to see where it goes before taking a decision how it should be done as it could have quite a big impact on the result (and the current Conversations/Gajim implementation doesn't respect the current draft).

Member

edhelas commented Jun 11, 2017

This feature will not be integrated in the upcoming release (0.12), also there is some serious discussions in the XSF regarding the standardization process of OMEMO, I'm waiting to see where it goes before taking a decision how it should be done as it could have quite a big impact on the result (and the current Conversations/Gajim implementation doesn't respect the current draft).

@edhelas

This comment has been minimized.

Show comment
Hide comment
@edhelas

edhelas Sep 10, 2017

Member

I'm closing this feature request. I'm not planning to implement OMEMO or related E2E encryption in Movim, I already explained in this ticket details about why it was not a good idea.

In short, Movim is a "light" client and relies heavily on the web server to handle, store, parse, analyze the messages. E2E encryption requires all those work to be done in the browser, this features goes against the architecture and Movim's model. Furthermore, even if that encryption was performed on the browser side, the code that handle that will be sent from the web server (which can be hacked…).

I really tried to find a way to handle that, but Movim is not made for OMEMO. Hopefully we still fully rely on XMPP, so you have the liberty to use another "local" client to send and receive encrypted messages next to Movim :)

Member

edhelas commented Sep 10, 2017

I'm closing this feature request. I'm not planning to implement OMEMO or related E2E encryption in Movim, I already explained in this ticket details about why it was not a good idea.

In short, Movim is a "light" client and relies heavily on the web server to handle, store, parse, analyze the messages. E2E encryption requires all those work to be done in the browser, this features goes against the architecture and Movim's model. Furthermore, even if that encryption was performed on the browser side, the code that handle that will be sent from the web server (which can be hacked…).

I really tried to find a way to handle that, but Movim is not made for OMEMO. Hopefully we still fully rely on XMPP, so you have the liberty to use another "local" client to send and receive encrypted messages next to Movim :)

@edhelas edhelas closed this Sep 10, 2017

@edhelas edhelas added wontfix and removed enhancement labels Sep 10, 2017

@matlag

This comment has been minimized.

Show comment
Hide comment
@matlag

matlag Sep 15, 2017

I still think you should, and store the key right on the pod, with a big warning to the user that the key is stored on the pod and the admin can access it.
Use case:
-I have my own pod, that I fully trust, simply because that's my very own pod!
-I exchange with a user who's using a different client on a server he does not trust
We want to have a secure conversation.
I can still use Movim, with the benefit of not dealing with keys transfer from device to device.

matlag commented Sep 15, 2017

I still think you should, and store the key right on the pod, with a big warning to the user that the key is stored on the pod and the admin can access it.
Use case:
-I have my own pod, that I fully trust, simply because that's my very own pod!
-I exchange with a user who's using a different client on a server he does not trust
We want to have a secure conversation.
I can still use Movim, with the benefit of not dealing with keys transfer from device to device.

@Dragnucs

This comment has been minimized.

Show comment
Hide comment
@Dragnucs

Dragnucs Sep 15, 2017

@edhelas What if we hire someone from Upwork to do this and give him the damn $100?

@edhelas What if we hire someone from Upwork to do this and give him the damn $100?

@alexandre1985

This comment has been minimized.

Show comment
Hide comment
@alexandre1985

alexandre1985 Jan 15, 2018

Have someone considered writing a browser extension that would enable OTR and OMEMO on web clients? Can't this solve your problems?
Privacy is important for users.
And in fact if someone is swapping from facebook to movim this may exactly be the reason... Think about it

alexandre1985 commented Jan 15, 2018

Have someone considered writing a browser extension that would enable OTR and OMEMO on web clients? Can't this solve your problems?
Privacy is important for users.
And in fact if someone is swapping from facebook to movim this may exactly be the reason... Think about it

@Neustradamus

This comment has been minimized.

Show comment
Hide comment
@Neustradamus

Neustradamus Jan 25, 2018

important missing feature...

important missing feature...

@Letterus

This comment has been minimized.

Show comment
Hide comment
@Letterus

Letterus Jan 25, 2018

You might have a look at https://crypto.cat - they are trying to get encryption over XMPP right - for a long time. It's a very hard job. You would at least need a bundled software for each platform, which integrity can be veryfied during update processes. Maintaining such a software bundle would be a project of its own, which requires high knowledge regarding cryptography…

You might have a look at https://crypto.cat - they are trying to get encryption over XMPP right - for a long time. It's a very hard job. You would at least need a bundled software for each platform, which integrity can be veryfied during update processes. Maintaining such a software bundle would be a project of its own, which requires high knowledge regarding cryptography…

@movim movim locked and limited conversation to collaborators Mar 13, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.