Summary

  • Le projet de protocole MIMI, version 07, mis à jour le 2 novembre 2026, reste un Internet-Draft de groupe de travail. Sa section 5.10 traite les pièces jointes chiffrées stockées hors du message, dont l'adresse HTTPS figure dans un objet ExternalPart.
  • L'accès direct montre l'adresse IP et l'heure du lecteur à l'hébergeur du fichier. Le relais du centre masque cette adresse, mais le fournisseur du destinataire peut toujours rapprocher l'URL de son utilisateur et du salon.
  • Avec Oblivious HTTP, relais et passerelle répartissent encore autrement les renseignements. MIMI exige une passerelle au centre et recommande un relais chez les autres fournisseurs pour éviter que le fournisseur du destinataire voie directement tous les domaines de stockage.

Imaginons une conversation de groupe qui traverse trois services. Un membre envoie une image chiffrée, dont le message porte l'adresse de téléchargement. Une destinataire ouvre l'image. Son contenu reste protégé sur le serveur, mais l'acte de la récupérer produit une heure, une destination et une demande. La société capable de relier ces trois éléments à la destinataire ou au salon dépend du chemin emprunté. Le cadenas du fichier ne décide pas du trajet.

Le RFC 9420 décrit la sécurité des messages de groupe par MLS. MIMI ajoute le transport entre fournisseurs et traite les pièces jointes comme des objets chiffrés distincts. Son projet de politique des salons définit les domaines de stockage autorisés dans asset_policy. Cette règle gouverne le destinataire du téléchargement et donc l'opérateur qui voit la requête.

La route directe donne le lecteur au serveur de fichiers

Premier choix : l'application télécharge directement chez l'hébergeur du fichier. Selon le projet, celui-ci voit l'adresse IP du client et l'heure de la demande. Les téléchargements d'un même objet permettent de rapprocher des lecteurs et d'inférer leur présence ou une participation commune. MIMI marque ce choix NOT RECOMMENDED, surtout lorsque l'hébergeur appartient à un autre fournisseur. Le contenu demeure chiffré ; la transaction parle encore du public qui s'y intéresse.

Deuxième choix : le fournisseur du destinataire appelle GET /proxyDownload/{downloadUrl} au centre du salon, qui demande l'objet à l'hébergeur. L'hébergeur voit le centre plutôt que l'adresse du lecteur. Le centre voit un fournisseur demander une URL, sans identifiant de salon ou de personne dans cette demande. Cette réduction est réelle. MIMI impose aussi que le centre vérifie le domaine cible contre les domaines de stockage configurés pour ses fournisseurs partenaires. Sans cette limite, le relais de pièces jointes deviendrait un proxy ouvert.

Le fournisseur du destinataire garde une vue plus complète. Il sert l'utilisateur et connaît l'URL demandée. Le projet indique qu'il peut rapprocher URL et lecteur puis inférer dans quel salon l'objet a circulé. L'heure d'arrivée d'un message associé au salon peut être comparée à l'heure d'une demande envoyée au centre. Mettre les objets en cache chez le fournisseur ou au centre peut brouiller une partie de cette correspondance. Le centre doit implémenter ce proxy ; son existence ne retire donc pas au fournisseur du lecteur le pouvoir de corrélation.

HTTP oblivieux déplace la connaissance

Troisième choix : le client enveloppe la demande dans Oblivious HTTP. Le relais chez son fournisseur la transmet à une passerelle au centre, qui va chercher l'objet auprès de l'hébergeur. Le RFC 9458 sépare les vues : le relais connaît la connexion du client mais pas la cible protégée, tandis que la passerelle connaît la cible sans recevoir cette connexion d'origine si les rôles restent distincts. MIMI exige la passerelle au centre et recommande les relais chez les autres fournisseurs. La passerelle doit limiter ses cibles aux domaines de stockage configurés.

Le bénéfice précis annoncé est que le fournisseur du destinataire n'apprend plus directement le domaine de chaque hébergeur de fichiers. La passerelle connaît encore la cible qu'elle contacte. Le fournisseur voit encore son utilisateur utiliser le relais à une certaine heure. Le regroupement des journaux ou des rôles peut recomposer les vues que le protocole sépare. Il faut donc nommer l'organisme qui exploite chaque fonction, la durée de conservation des traces et la possibilité de les joindre.

Les sources officielles ne mesurent pas la réussite de telles corrélations dans une installation réelle. Un essai contrôlé des trois chemins, avec et sans cache, montrerait les journaux disponibles chez chaque acteur. La décision de conception est déjà visible : chiffrer l'image protège l'image ; l'architecture de téléchargement décide qui tient la liste des personnes venues la voir. Avant de promettre un échange privé entre services, il faut choisir cette architecture.

Projet MIMI · RFC 9458 · RFC 9420 · Politique MIMI