XMPP et Java avec Smack : un peu de Privacy

Publié dans XMPP | Marqué avec , ,
Share

Une extension XMPP en cours de standardisation permet de gérer les permissions d’accès  : l’extension Privacy. Le terme Privacy fait beaucoup penser à la protection des données personnelles, or en réalité avec cette extension, on gère simplement les permissions pour me contacter ou connaître ma présence.

L’idée général est simple :

  • On définie des règles dans un PrivacyItem (ex : j’autorise Jacques à m’envoyer des messages, mais pas Pierre)
  • On créé un PrivacyList qui contient autant de PrivacyItem que souhaité
  • On ajoute ce ou ces listes à notre PrivacyListManager et on active la liste à utiliser

Voici ce que cela donne avec la librairie Smack :

// Create PrivacyItems
List<PrivacyItem> privacyItems = new ArrayList<PrivacyItem>();
PrivacyItem item = new PrivacyItem(...);
// On verra ça plus bas
privacyItems.add(item);
// Add it
PrivacyListManager privacyManager = PrivacyListManager.getInstanceFor(xmppManager.connection);
privacyManager.createPrivacyList("blockedPeople", privacyItems);
privacyManager.setDefaultListName("blockedPeople");

Regardons plus en détails ce qu’il est possible de faire avec cette extension.

Bloquer/Autoriser un utilisateur (via son JID)

PrivacyItem item = new PrivacyItem("jid", false, 1);
item.setValue("a jid@a domain");

Empêche un utilisateur de nous envoyer des paquets (messages, mis à jour de ses informations ou de sa présence, …), mais il peut recevoir les notre !

Bloquer/Autoriser les subscriptions

PrivacyItem item = new PrivacyItem("subscription", false, 1);
item.setValue(PrivacyRule.SUBSCRIPTION_BOTH);

Cela permet d’empêcher des utilisateurs s’étend inscris à mes paquets de les recevoir. Par exemple, si je suis dans le Roster de quelqu’un, c’est qu’il s’est inscris aux messages que je lui destine.

Un tel item peut recevoir quatre valeurs différentes :

  • both : touche les personnes qui sont dans mon Roster, et moi dans le leur
  • to : touche les personnes qui sont dans mon Roster, mais moi PAS dans le leur
  • from : touche les personnes qui ne sont  PAS dans mon Roster, mais moi dans le leur
  • none : touche les personnes qui ne sont ni dans mon Roster, ni moi dans le leur

Bloquer/Autoriser un groupe

PrivacyItem item = new PrivacyItem("group", false, 1);
item.setValue("group name in my roster");

Empêche un groupe de contacts (défini dans notre roster) de nous envoyer des paquets (messages, mis à jour de ses informations ou de sa présence, …), mais ils peuvent recevoir les notre et voir notre présence.

Bloquage et autorisation : avec plus de finesse

En ajoutant à un privacy item un ou plusieurs filtres, on peut préciser les paquets bloqués ou autorisés pour tel type d’utilisateur. En effet, lors de la création de l’instance de privacyItem, on définie un boolean à true ou false pour autoriser ou bloquer de manière globale tous les paquets. Et pour affiner cela, on surcharge cette autorisation en précisant un :

  • setFilterMessage : false pour bloquer les messages entrants (ceux venant de l’autre utilisateur)
  • setFilterIQ : false pour bloquer les paquets IQ entrants (ceux venant de l’autre utilisateur)
  • setFilterPresence_in : false pour bloquer les modifications de présence entrantes (celles venant de l’autre utilisateur)
  • setFilterPresence_out : false pour bloquer les modifications de présence sortantes (ma présence !) . Ce dernier champ est particulièrement intéressant puisqu’il permet, en théorie, de cacher sa présence à un utilisateur non désiré. Malheureusement, d’après les tests que j’ai fait, cela ne fonctionne pas très bien, si je modifie mon status à « available », je suis toujours détecté (l’inverse n’est pas vrai)

Voici un exemple d’utilisation :

PrivacyItem item = new PrivacyItem("group", false, 1);
item.setValue("group name in my roster");
item.setFilterMessage(true);

Ici on empêche donc un groupe de contacts  de nous envoyer des paquets , sauf des paquets au format Message.

A noter que lorsque l’API de cette extension XMPP sera terminée, on écrira vraisemblablement PrivacyRule.JID au lieu de « jid » et de même : PrivacyRule.SUBSCRIPTION et PrivacyRule.GROUP.

Pour conclure

Alors pour conclure ce petit aperçu de l’extension Privacy de XMPP… L’API est plutôt bien conçue, c’est facilement utilisable une fois que l’on a compris la chose. Je me demande juste ce que donne en pratique cette histoire de PrivacyList à activer ou à choisir par défaut.

Par contre, certes cette extension permet de gérer les autorisations/permissions avec une bonne granularité dans le choix des personnes (un utilisateur, un groupe, ou en mode follower/followed) mais c’est du tout noir ou tout blanc. On ne peut autoriser / bloquer en fonction du but d’utilisation (purpose) ou du contexte (géolocalisation, durée de rétention de la donnée, …). Or c’est aujourd’hui très utile, voir indispensable, pour gérer les données personnelles de manière intelligente et non limitative pour l’utilisateur. En l’occurrence, j’en demande peut-être trop à XMPP. Je ne pense pas que ce genre de règles doivent se trouver dans le protocole de communication (comme XMPP), mais plutôt liée au protocole d’accès aux données.

D’autres ressources

Une réponse à XMPP et Java avec Smack : un peu de Privacy

  1. Le plus marrant c’est que j’ai écrit cet article il y a quatre mois, et qu’en le relisant je me suis dit : « c’est cool ! Je ne savais pas (plus) que l’on pouvait faire ça ! » 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*