Summer is coming and with it the next Movim #release ! The 0.12 version will be tagged certainly in the upcoming weeks. Unfortunately #OMEMO is not part of the game for this one but is still planned for the upcoming release.

You can already try the next version on the two official pods nl.movim.eu and fr.movim.eu :) You'll find there all the nice features that will be delivered for this summer release, among others:

• A new way to quickly publish posts from the home page
• A refreshed contact page
• The support of MUC invitations
• The support of chat markers (to know if your contact has read your messages)
• A big improvement for the support of #tags in posts

…and many other small surprises ;)

We are also still looking for a nice name for the 0.12. We invite you to submit name ideas in the comments of this post :) One rule to follow, it must be the name of a comet, you can use the Lists of comets Wikipedia page to help.

That's all folks!

Six months after Movim 0.10 Holmes, here is the new winter release of the Movim project.

Small recap: Movim is a project that aims to build an IM and social networking service exclusively on top of the XMPP protocol.

This 0.11 version refined several features and will introduce a couple of big changes, mainly regarding the navigation and the project UI.

Features

New contacts list

The contacts list (or roster) has always been a very complex element inside Movim. It was ported on Angular 1 a couple of versions ago but suffered since then of performances issues (that could block the page loading for several seconds).

This new version brings a complete rewrite of this feature in pure PHP (with a bit of JavaScript). The contacts are now grouped in a simple list. The search has been improved and now allows you to search instantly among your contacts using their name, ID, nickname or group.

Onboarding

At first startup, Movim is now asking for some browser and account preconfiguration regarding notifications and pop-ups (used for videoconferencing) preferences.

The sharing feature

As promised, articles sharing has been greatly improved in and around the Movim project. It is now possible to share an article (as in "write an article as an answer to") on your own Blog. This feature is based on the IETF — Atom Threading Extensions (RFC 4685) norm. Again, Movim aims at showing that it's possible to build a social solution relying only on existing standards.

Sharing an external link has also been improved. Movim now understands XMPP URIs.

Communities

Communities, previously named "groups", are the result of a deep redesign of the way articles are displayed navigated through. The reorganization of the content makes the exploration much easier and natural. This new name also lets Communities clearly stand out from group discussions (chatrooms) and groups in the contacts list.

Communities also benefited of a better management system, for users, but also for administrators who can now assign roles in a more precise way.

All in all, that's a lot of changes but don't worry, Movim will still be compatible with old versions as nothing has changed on the XMPP side. ;)

Posts

Two littles features have been added on the articles page to facilitate articles discovery and evaluation. An article is now surrounded by links to the previous and following articles of the same Community or from the same contact and a "Like" button let's you express your contempt to the author of the article. :)

As an author, a new Notifications block on the homepage informs you of comments and likes on your published articles.

Discovery

The interface redesign also brings new features of content discovery.

Movim now provides readers with related articles published on Blogs or in Communities. Suggestions are so far pretty basic but should get better in the upcoming versions.

Chat

The Chat part has not been forgotten. A lot of changes have been done on the interface to ease the navigation on small and big screens (removal of useless spaces) and to fix a few bugs (on Android). A new pack of stickers has been added with a Creative Common BY-SA license.

The file upload and file sharing UI have both been redesigned and now make use of one of the latest XMPP norms, XEP-0385 : Stateless Inline Media Sharing (SIMS). It allows Movim to integrate them better in Chats.

Videoconferencing (beta)

In this version, the videoconferencing feature is coming back in Movim. As usual, nothing but standards here (WebRTC and XMPP Jingle this time). However some bugs still remain. They should all be fixed for the upcoming (0.12) version. This feature is only available for the desktops for now.

Refactoring of the session system

The user sessions management code within Movim was one of the oldest ones in use in the project. It has been heavily redesigned and now brings a new way of handeling cookies and session variables both in memory and in the database.

Around Movim

We now see more and more external contributions on Movim and its linked projects.

Android Client

Thanks to schlusslicht the Android native file selector has been integrated to the application. You can now upload files from your phone.

A little security update regarding certificates management has been added at the same time (non valid certificates are no longer accepted).

The Android application is available on Google Play and F-Droid.

Electron Client (desktop)

The Electron client has been updated. Mike Barnes (bremensaki) has added the support of contextual menus in the interface. Thanks Mike !

New Debian and RPM packages have been made. Movim is now also available on Windows and macOS. All those applications are available on the official website.

Atomtopubsub

Atomtopubsub is the little magic tool that, as its name suggests, parses Atom feeds and injects them on Pubsub nodes. It allows Movim to offer a lot of news feeds among Communities. A big thanks to Link Mauve, who took some time during the 33c3 to port atomtopubsub in Python 3 and to optimize the processing of articles inside the application.

Movim Europe

Movim Europe is a structure that provides support for the Movim project. It has been declared in the Netherlands and currently offers two services.

• technical support and advices to deploy the platform (and linked services such as XMPP servers or SQL databases) and/or on the technologies involved in the project;
• the possibility as a company, an association or an individual to fund the development of features that were not initially planned on the roadmap and that are part of a particular need.

The gathered funds will first cover the running costs (domains, hosting, travels...) that were until now payed by the founder, but also to free more time to develop the project and its surroundings (administration, linked projects, conferences...).

Don't hesitate to contact us on the official chatroom.

A few figures

We also have two official servers: one hosted in Amsterdam, with around 4 000 registrations and 50 connected people, and one in Roubaix with 2 800 registered people and around 20 simultaneously connected people.

Everyday, 4 000 messages (simple or from groupchats) are sent or received, and around twenty articles are written by the users of nl.movim.eu.

Statistics that are (voluntarily) sent on api.movim.eu by the deployed instances are showing a total of 8 000 registered users and around 250 simultaneously connected ones along the day. The XMPP server movim.eu reaches 300 connected people during the day.

Some plans are made to open new servers both in Australia and in Russia.

Movim 0.12

A new roadmap is also planned for the 0.12 that should be released this summer. Two main changes are planned:

• Movim has a heavy memory consumption, it can reach 50 Mio for some users connected on a server. This problem is not due to memory leaks but to architectural decisions that are duplicating for each session some parts of the Movim code in memory. A huge change on this subject is planned, that should significantly reduce the memory footprint during runtime.
• An implementation of the OMEMO protocol has been strongly demanded by the community. A preliminary research work has been done in January and it seems that this end-to-end encryption protocol could be implemented in Movim. A publication about this feature will most probably be released in the next few months.

We need you!

Don't forget, the Movim project needs you! As a source code contributor, but also as an administrator, packager, translator or even a drawer (if you want to add your own stickers to Movim!).

All contributions are welcome, so don't hesitate to come and discuss them with us on movim@conference.movim.eu. :)

That’s all folks!

Translated from the original French article by nodpounod - Christine HO & daftaupe - Pierre-Alain TORET

Il y a quelques jours je suis tombé sur un article annonçant la sortie de la nouvelle mouture du client de messagerie sécurisé Cryptocat. Je ne m'étais jamais réellement penché sur ce client car il faisait, selon moi, partie des dizaines d'autres clients surfant sur la vague des messageries instantanées chiffrées sorties suite aux révélations d'E.Snowden. J'ai donc voulu creuser un peu et voir de quoi il était composé.

Comme vous le savez peut-être, je travaille moi-même sur un client de messagerie "sociale" appelée Movim exploitant le protocole XMPP. J'essaye, au travers de ce projet, de montrer aux gens qu'il est parfaitement possible de créer une solution à la fois sécurisée, standard et décentralisée tout en offrant une interface agréable et simple à comprendre. Petite précision toutefois: Movim ne possède pas (encore, mais j'y travaille) de fonctionnalité de chiffrement de bout en bout. Néanmoins il est possible de faire ce genre de chiffrement sur XMPP de façon standard et compatible avec des technologies standardisées comme OTR et le récent OMEMO (c'est d'ailleurs cette norme que j'ai décidé d'implémenter dans Movim).

La chose que je trouve dommage avec tous ces services et clients c'est qu'ils ne sont pas compatibles entre eux. Pourtant il existe aujourd'hui plusieurs clients XMPP proposant la norme OTR et OMEMO mais qui ne sont malheureusement pas si connus et médiatisés que les autres. Je mentionnerais en particulier l'excellent Conversations (sur Android) dont l'équipe est à l'origine de la norme OMEMO (qui est elle-même une implémentation de la norme Axolotl dans XMPP, notamment utilisée sur le client Signal).

Étant un peu curieux par nature je me suis plongé dans le code source de la nouvelle version de ce cher Cryptocat pour regarder un peu ce qu'il a dans le ventre.

Ni une, ni deux, je clone le dépôt sur ma machine et je commence à explorer le code.

Première surprise !

Avant même d'ouvrir le moindre fichier j'avais déjà un petit sourire en coin en voyant le nom de certains d'entre eux dans le répertoire src/js/.

axolotl.js
omemo.js
xmpp.js

Tiens, tiens, tiens. Un petit tour sur la page Security du site me confirme bien ça. Cryptocat utilise XMPP comme transport et OMEMO comme méthode de chiffrement. Le reste du blabla n'est rien d'autre qu'une réexplication de la norme Axolotl sans pour autant la mentionner.

Donc Cryptocat est un client XMPP, en Javascript, avec la norme OMEMO par dessus.

XMPP…

Je ne me suis pas particulièrement penché sur la partie chiffrement du projet, j'avoue ne pas avoir assez de compétences en cryptographie pour offrir une critique constructive et je pense que l'auteur du projet est bien plus expérimenté que moi là dessus. Je salue par ailleurs sa volonté de transparence à ce propos. Néanmoins je commence à bien connaitre le protocole XMPP et je sais que son point fort est la possibilité d'interconnecter les serveurs entre eux et de laisser le choix du serveur à utiliser aux utilisateurs.

L'interconnexion est une fonctionnalité que j'estime nécessaire car d'une part, elle permet aux utilisateurs d'avoir le choix du serveur sur lequel ils iront déposer leurs données et d'autre part, elle décentralise les points d'échange du réseau (et rend ainsi plus difficile la censure et l'écoute du réseau).

Après avoir regardé plus en détails le fichier xmpp.js j'ai enfin la confirmation de ce dont je me doutais jusque là.

jid: username + '@crypto.cat',
server: 'crypto.cat',

Oui, il y a bien un serveur XMPP écrit en dur dans le code source du projet.

Explorons un petit peu le serveur crypto.cat

Le site XMPP IM Observatory nous retourne une note de A pour la sécurité du serveur, ici rien à dire. Par contre je découvre que l'interconnexion avec les autres serveurs du réseau n'est pas autorisée. La connexion entre le client Javascript et le serveur se fait au moyen d'un Websocket et le serveur XMPP est un serveur Prosody tout bête.

Cryptocat n'est donc pas qu'une application de chat offerte par Nadim Kobeissi, mais aussi un service centralisé auquel les utilisateurs sont contraints de se connecter (sauf s'ils changent le code source du client, ce qui est possible, mais combien le feront ?).

Précisions sur le chiffrement de bout en bout dans XMPP

Le chiffrement de bout en bout est une très grande avancée dans l'anonymisation des données échangées. Néanmoins il ne permet pas tout. Sur XMPP par exemple il faut savoir que OTR et OMEMO ne chiffrent que le contenu des messages et pas la signalisation qui les accompagne (certains diront les métadonnées). Mais que pouvons nous trouver dans ces métadonnées ? Et bien l'identifiant de l'émetteur et du destinataire du message mais aussi beaucoup d'autres choses pouvant êtres sensibles. Une page sur le Wiki de Reporters Sans Frontieres résume plutôt bien tout ça. Ces informations peuvent être conservées dans des historiques et journaux sur les serveurs XMPP.

En choisissant de centraliser son service sur un seul et unique serveur (qui semble être hébergé dans le datacenter d'OVH à Roubaix) l'auteur de Cryptocat a aussi fait le choix de concentrer l'intégralité du trafic de sa plateforme sur un seul et unique point du réseau Internet.

Cela me serait égal si toutes ces informations étaient précisées sur le site du projet, au moins de façon temporaire si l'objectif à terme était de permettre la connexion à d'autres serveurs XMPP. Mais je trouve vraiment dommage qu'il ait tu ces informations.

Petit bonus, qu'en est-il de la v1 de Cryptocat ?

Même si je salue le fait d'utiliser des normes comme XMPP et OMEMO dans Cryptocat, j'ai quand même jeté un œil à la première version du projet pour voir sur quelle architecture il s'était basé.

Sans grande surprise la première version se base également sur XMPP et OTR. Néanmoins elle permettait de changer le serveur XMPP sur lequel le client se connectait. J'espère donc qu'il sera également possible de faire la même chose sur la seconde version.

Pas de quoi s'inquiéter donc ?

Oui, pour le moment pas de quoi crier au scandale mais je souhaiterais que Nadim soit aussi transparent sur l'architecture de son projet que sur les méthodes de chiffrement qu'il utilise au sein de son application.

Je pense qu'il est aussi important d'informer les utilisateurs de comment sont protégées leurs messages mais aussi par où et comment ceux-ci sont acheminés.

Dernière petite question, pourquoi vouloir à tout prix fermer la plateforme alors que XMPP permet nativement l'interconnexion avec les autres réseaux ?

En bref, si vous voulez avoir les mêmes fonctionnalités que Cryptocat, plus tous les avantages de XMPP (interconnexion, gestion de l'historique, profiles, notifications, accusés de réception…) tournez vous vers des clients comme Conversations ou Gajim (et bientôt Movim concernant le chiffrement je vous promet !).

That's all folks !