close
    • chevron_right

      Movim 0.22 - Kowal

      Timothée Jaussoin · pubsub.movim.eu / Movim · Sunday, 25 June, 2023 - 16:02 edit · 3 minutes

    Only a few months after Movim 0.21 - Whipple we are releasing Movim 0.22, codename Kowal.

    This version was more focused on stabilization, cleanup and refactoring but also introduces a couple of new exciting features. It requires PHP8.1+ to work properly.

    Let's dive in!

    Blog privacy toggle

    Already introduced in a previous blog post this new feature allow you to change your blog privacy level between "public" and "subscribers only".

    Global OMEMO toggle

    After some feedback from the community a global #OMEMO toggle was introduced in the settings. OMEMO is therefore disabled by default from this version.

    This decision is especially linked with the current encryption implementation that relies on libsignal-protocol-javascript that is deprecated by their authors. The performances of this library are not that great, especially on mobile devices, which caused lots of accessibility issues for some Movim newcomers.

    For now, no serious alternative are available, if you know one do not hesitate to tell us about it.

    Fixes and improvement around audio-video calls

    Several small tickets (#1212, #1213, #1214) linked to the the audio-video call integration and compatibility with other clients were fixed.

    Missed and refused call events are also now tracked properly and displayed in your contacts conversations.

    Cleaner URLs

    The ? was (finally) removed in front of all the URLs! While being way cleaner it also fixes some issues when #Movim URLs were shared around, especially on some other social-networks. Don't worry about retro-compatibility, existing URLs are redirected to the new format.

    Rewrite of the XEP-0077: In-Band Registration related code

    Movim is supporting XEP-0077 for close than 10 years now and this code was never really refactored since then. All the #XMPP code, and related user flow, were cleaned and upgraded to the latest Movim standard, fixing a few issues in the meantime!

    New Chat bubble design and interaction

    Kowal introduce a totally new way of interacting with the chat bubbles.

    While keeping the small actions icons on desktop it is now possible to simply click (or tap) on the bubbles to open a sub-menu which presents all the actions available.

    This menu allows you to react, retract, reply and copy the message content in one click/tap. Easy!

    The new chat message menu

    Under the hood... or not

    An important refactoring was done to simplify and factorize redundant items in the UI. This brought some big code cleanup, both on the front part (what is taking care of what you see) of Movim but also in the core and XMPP layers. The code was modernized and ported to PHP8.1+ in many places as well.

    Several Pubsub related issues were fixed improving the compatibility with existing XMPP servers such as Prosody or ejabberd (see the related ticket). Movim now detect Pubsub nodes misconfiguration and reconfigure them properly to respect the privacy and settings specified in all the Pubsub related implemented XEPs that it supports.

    This refactoring also brought some small UI improvements such as a new design for the contact status bubbles and a totally new way to handle Contacts and Communities avatars. We are strongly advising you to configure the Picture Proxy Cache on your Web Server when upgrading to greatly improve the page load time.

    Two important security fixes

    CVE-2023-2848 fixes a security issues that allows under certain circumstances to open a #Websocket to Movim from a different domain. It was fixed in this commit.

    CVE-2023-2849 is not directly linked with Movim itself but the related server configuration.

    When the domain that host upload files is the same as where Movim is hosted it is possible to upload a malicious Javascript file and execute it in the Movim sandbox. The attack surface is really minimal but we advise you to ensure that such case cannot happen on your instance. To do so you can use different domains between the two services or force the browser to handle all the uploaded files as attachments and not inline elements using a simple HTTP header:

        add_header Content-Disposition attachment;
    

    What's next?

    The multi-part audio and video-conference feature that was planned for the 0.22 is pushed back to the 0.23. The amount of work planned for that is quite big, therefore it was more relevant to move all the code cleanup and refactoring plans in Kowal and have this milestone before jumping into this new exciting feature set !

    As always, if you find issues or want to share some feedback you have on the project, you can find how to contact us on our official website and our Github.

    That's all folks!

    • chevron_right

      Jabber/XMPP Client Kaidan Progress

      pubsub.movim.eu / berlin-xmpp-meetup · Tuesday, 11 October, 2022 - 18:40

    Jabber/XMPP Client Kaidan Progress

    Topic: Kaidan with OMEMO 2 Encrypted File Sharing, Message Reactions, Chat Markers, Chat State Notifications and Trust Messages

    When? Wednesday, 2022-10-12 18:00 CEST (always 2ⁿᵈ Wednesday of every month)

    Where? In xHain hack+makespace, Grünberger Str. 16, 10243 Berlin

    No live stream and no recording this time, sorry.

    See you there or in our virtual room xmpp:berlin-meetup@conference.conversations.im?join

    #jabber #xmpp #community #xhain #freesoftware #berlin #meetup #federation #kaidan #omemo #omemo2

    • chevron_right

      End to end encryption in Movim - OMEMO is (finally) there!

      Timothée Jaussoin · pubsub.movim.eu / Movim · Wednesday, 15 December, 2021 - 22:01 edit · 7 minutes

    A few days ago I finally closed the OMEMO encryption ticket on Github. Opened in 2015 it had many twists and turns along the years but I finally found a proper way of integrating it in Movim.

    In this article I'll explain why adding #E2EE (End to End Encryption) was not as easy as with the other #XMPP clients (and more generaly all the chat clients that are using a similar encryption protocol) and how I addressed the issue.

    But before going in the details I'd like to thanks the NLNet Fundation for its financial support in this project. With their help I was able to free-up some time to work on the problem and propose a proper architecture (detailled bellow) for it.

    NLNet Foundation logo

    The result of this work will be released with the upcoming 0.20 version of #Movim. There is still some quirks and whims about it but the base is there and works pretty well.

    End to End encryption in XMPP, a quick overview

    The introduction of Signal in 2015 brought a small revolution into the encryption protocols in the IM ecosystem. The Double Ratchet Algorythm (see the dedicated technical documentation on the Signal website) allowed users to exchange messages between different clients in an “end to end encrypted” way (only user devices themselves know how to encrypt and decrypt messages) with some technical improvements (not detailed here) that made the new protocol a “must have” for all the others IM solutions.

    Today the Double Ratchet Algorithm is used in applications such as WhatsApp or Matrix.

    In the XMPP ecosystem it was primarily pushed by Daniel Gultsch in the Conversations.im client and standardized along the way in the OMEMO XMPP Extension XEP-0384: OMEMO Encryption. Throughout the years many XMPP clients implemented OMEMO, their status can be tracked on the following website Are we OMEMO yet?.

    The OMEMO architecture

    Without going too deep into the technical details the general idea about OMEMO is to generate some keys on each of the user's devices and publish the public ones on their account server.

    Using the keys published on the XMPP user's servers, anyone can then start an encrypted session at any time (the servers are always available) and start to send messages to the desired contact without having to wait.

    Publishing keys and building sessions with OMEMO

    If one of the user's contacts wants to start an encrypted discussion they will first start to get those keys, then build sessions with their secret one and encrypt a message using the freshly built sessions.

    If a user receives a new encrypted message and doesn't have an encryption session to that device, their device will then retrieve the contact keys, build the encryption sessions and start decrypting messages.

    This can be done automatically if the contact trusts blindly the key used or in a more “trusted” way by accepting manually each keys to build the encryption sessions on.

    All the existing XMPP clients are using this simple architecture. XMPP servers are storing their users' #OMEMO public keys and the users are connecting directly using their different devices to build their encrypted sessions.

    The Movim particularity

    But Movim is kind of special. The XMPP connection is actually not maintained on user devices but by the Movim server (built in PHP and running behind a web server such as Apache or nginx, see Movim General architecture on the Wiki). Movim is then processing everything server side, saving the information (articles, contacts and messages) in a SQL Database (PostgreSQL or MySQL) and then showing the result to the Movim users through a lightweight website.

    If a user is connecting on the same Movim instance through several browsers using the same XMPP account all the browsers are then “merged” into one unique XMPP session (called "resource") and all the browsers are synchronized in real time by the Movim server. This is pretty useful to save memory and to prevent Movim to maintain several XMPP connections at the same time for a unique user. This also allows quick disconnection/reconnections, the users can close and reopen their tabs without having to reload the whole XMPP state when they come back after a while (Movim is closing the XMPP session after a day of inactivity).

    End to end encryption actually requires to encrypt and decrypt messages on the user device, this brings several issues:

    • For Movim, the user device is actually a “dumb” browser that only display the messages pre-processed by the Movim server, there is no logic whatsoever browser side
    • A user can use simultaneously several browsers with the same XMPP connection on the same Movim instance
    • All the message processing logic is done server side

    This unique architecture requires a very unique way of adressing the E2EE situation. Hopefully OMEMO offers all the tools needed to handle those cases.

    Split the logic

    The OMEMO extension is actually talking about devices, for a large majority of the XMPP clients a device is connected through a unique XMPP session (one device equal one current XMPP resource in those cases).

    Publishing keys with Movim

    The fact that Movim is sharing a unique session (resource) with several devices (browsers) is actually not an issue in the end. Each browser will then be considered as a unique device on its own, with its own key and its own OMEMO encrypted sessions.

    Building encrypted sessions with Movim

    This brings some interesing results. When a user is connected using the same XMPP account using two different browsers on the same Movim server (also called instance, or pod), an encrypted message sent by the browser Firefox will then directly be decrypted by the browser Chrome without even having to travel through the XMPP network.

    The term “browser” is also defining more than actual browsers (like Firefox, Chrome or Opera). Since we can have private navigation or containers (in Firefox) each time it is seen as a different “browser” on the Movim side (because each context is separated, with a different cookie and different local data).

    So the global idea is to continue to handle the messages server side, push the encrypted message object to the browser, and then implement only the key handling and message encryption-decryption flow browser side. When doing this implementation I actually looked at the Converse.js and JSXC OMEMO implementations, the Movim implementation is really close to the one done on those two clients (I am also re-using the libsignal JavaScript implementation).

    This architecture actually works for the current version of OMEMO (0.3.0) where only the body is encrypted. The upcoming versions are looking to encrypt a larger part of the XML stanza. This will be way more difficult to handle for Movim, as it will require to decrypt messages browser side and then implement a second parser, this time in JavaScript (everything is parsed in PHP using libxml at the moment).

    if (textarea.dataset.encryptedstate == 'yes') {
        // Try to encrypt the message
        let omemo = ChatOmemo.encrypt(jid, text, Boolean(textarea.dataset.muc));
        if (omemo) {
            omemo.then(omemoheader => {
                ...
                xhr = Chat_ajaxHttpDaemonSendMessage(jid, tempId, muc, null, replyMid, mucReceipts, omemoheader);
                ...
            });
        }
    } else {
        xhr = Chat_ajaxHttpDaemonSendMessage(jid, text, muc, null, replyMid, mucReceipts);
        ...
    }
    

    This little JavaScript Movim code extract presents the differences in handling encrypted and unencrypted messages. The text variable is containing the clear text version of the message. When the body is encrypted it is then calling the same method as for a clear text message.

    This method is actually a wrapper generated by the RPC (Remote Procedure Call) Movim server core. Once this function is called an Ajax called is made and the rest of the flow is handled server side. The encrypted body, and generated OMEMO headers passed will be injected in a freshly generated XMPP XML <message>.

    Keep the messages in the local database

    With the separation of the logic it was then required to keep a copy of the decrypted messages browser side.

    To do that an IndexedDB database is used. This database is quite simple and only contains a key-value store, where the key is the message id (the same as the one in the Movim server SQL server databse) and the value the plaintext message.

    • When a message is decrypted the plaintext body is then stored in this database.
    • When the user sends an encrypted message, the original text is also saved in this database.
    • If a message cannot be decrypted, the message key is still saved in the browser database with a false value. This prevents Movim to try to decrypt several times a message, knowing that the decryption will fail each time in the end.

    Using this database, when a chat is loaded, all the messages are then sent chronologically from the server, passed trough a little bit of code that will lookup the state of all messages and then decrypt the ones that are not decrypted yet, the already decrypted messages are then shown, or an error is displayed for those that cannot be decrypted.

    To sum up

    In this article I tried to present you what limitations I faced when trying to implement end to end encryption within Movim and what architectural and technical solutions were used to address them.

    The current solution seems to fit and bring all the desired features to Movim without too much downsides. The feature can now be considered as done and will be released soon. And as always, lots of small fixes and adjustments will be integrated to polish it afterward.

    That's all folks!

    edhelas

    • chevron_right

      Year of the OX: OpenPGP for XMPP

      pubsub.movim.eu / berlin-xmpp-meetup · Monday, 1 February, 2021 - 02:02 edit

    In February 2021, this month, starts the year of the ox. At Berlin XMPP meetup, we will celebrate the new year with an introductionary talk about "XEP-0373: OpenPGP for XMPP" and "XEP-0374: OpenPGP for XMPP Instant Messaging" and the panel of experts:

    • DebXWoody (implementor of OX in Profanity)
    • defanor (implementor of OX in rexmpp)
    • Florian (co-author of the OX standards)
    • lovetox (implementor of OX for Gajim)
    • Paul (implementor of OX in Smack)

    When? Wednesday, 2021-02-10 18:00 CET (always 2ⁿᵈ Wednesday of every month)

    Where? Online, via our MUC (xmpp:berlin-meetup@conference.conversations.im?join). A Jitsi video conference will be announced there.

    See you then!

    #yearoftheox #openpgp #xmpp #ox #jabber #encryption #e2ee #privacy #omemo #🐂️ #berlin #meetup #community #profanity #rexmpp #gajim #smack

    • chevron_right

      Adrien Dorsaz · Thursday, 9 January, 2020 - 06:59

      Contact publication

    • OMEMO is broken in general across the ecosystem :(

      I along with a lot of other people have tried to test OMEMO and we've all spent some time trying to figure out what is going on with OMEMO on multiple clients and compatibility. I think I know at least one reason why clients on different platforms can't talk to each other. If you look at my earli

    • chevron_right

      Movim 0.16.1 – Cesco

      Timothée Jaussoin · pubsub.movim.eu / Movim · Friday, 6 December, 2019 - 09:50 · 1 minute

    Only a few weeks after the 0.16 release here is the 0.16.1 one!

    This release includes several fixes and a few new features.

    Features

    You can now share posts to your connected chatrooms :)

    Chatroom post sharing

    Communities layout were a bit redesigned, publication rules are now displayed clearly in the right column and the header shows more information on mobile.

    Communities redesigned

    All the messages that you sent in the one to one discussions can now be edited.

    Message edition for the whole history

    The videoconferencing feature was heavily refactored and several issues were fixed during this process. A new XEP was also used partially to improve the call negociation flow, XEP-0353: Jingle Message Initiation.

    Fixes

    In the database an index was added on the key that was tracking contacts avatars. This sounds maybe a bit technical to you but this small fix boost quite a lot the performances during the login process, when you join a chatroom (especially that one) or when a contact updates his/her avatar. Because it's a database change you should run the database migrations when updating from 0.16 to 0.16.1.

    All the entities that are on the XMPP network needs to declare what they are capable of to the others. This allows feature discovery and negociation and is specified in the #XMPP extension XEP-0115: Entity Capabilities. After the big code refactor of the handling of those #capabilities within the Movim codebase some other small improvements and fixes were done to wrap up properly this feature.

    Presences sent to MUC are now generated the same way than those sent to contacts, this fixes #711.

    DNS resolution errors an timeout are now handled properly displayed during the authentication flow (#368).

    The SQL_DATE constant was renamed to MOVIM_SQL_DATE to prevent some naming conflicts (#820).

    What's next?

    PHP 7.4 was released a few days ago, so the upcoming version will focus on fixing issues to make Movim fully compatible with that version.

    This new PHP release also includes an exciting feature that allows #PHP developpers to call directly C libraries in their codes. This could allow #Movim to directly use the libsignal C library and therefore (finally) allow OMEMO end-to-end-encryption to be implemented. This will be a lot of work and verifications so we're not promissing anything anytime soon. Stay calm please!

    That's all folks!

    #omemo #videoconference #jingle #release

    • chevron_right

      Protéger ses conversations avec OMEMO

      Adrien Dorsaz · Wednesday, 3 August, 2016 - 06:07 · 1 minute

    Je viens de survoler le texte de la XEP d'OMEMO.

    Cette extensions permet de chiffrer ses conversations avec ses contacts d'une manière originale: au lieu de faire un chiffrement par contact, l'extension prévoit de faire un chiffrement par client XMPP.

    Ce que j'aime bien, c'est que le chiffrement avec OMEMO est compatible avec les principaux avantages de Carbon et de MAM (le premier permet d'envoyer un message à plusieurs client en même temps, le second de créer une archive sur le serveur pour que les clients qui ont perdu la connexion puissent retrouver l'historique complet des messages).

    En réalité MAM perd une fonctionnalité: si j'utilise aujourd'hui un nouveau client XMPP, il ne pourra pas lire l'historique de mes conversations d'hier, car il est incapable de déchiffrer les messages. Comme cette fonctionnalité est un concept opposé au chiffrement, ça fait sens de ne plus l'avoir lorsque l'on décide de chiffrer ses messages.

    Si j'ai bien compris, pour chaque message OMEMO génère une clé de chiffrement et chiffre le message avec cette clé. À côté du message chiffré, pour chaque client XMPP de confiance, OMEMO ajoute une entête avec la clé utilisée chiffrée avec la clé publique du client. Ainsi, le message réel n'est chiffré qu'une fois et tous les clients peuvent le déchiffrer (car chacun peut retrouver la clé qui avait été utilisée). Je trouve ça vraiment élégant :)