Q1. Pouvez-vous nous expliquer brièvement l'histoire d'origine de Session et ce qui vous a motivé à construire un réseau de messagerie décentralisé ?
Session est la création conjointe de centaines de contributeurs du monde entier—c'est la beauté des logiciels open-source ; tout le monde peut écrire et contribuer au code de Session. Chaque produit, cependant, a une histoire de fondation plus centrale. Pour Session, les fondateurs originaux voulaient créer une application de preuve de concept sur un réseau décentralisé nouvellement établi. Nous pensions que la meilleure application de preuve de concept était de construire une application de messagerie qui stockait et acheminait des messages à travers ce réseau décentralisé, car une fois que vous aviez un messager de base, vous pouviez généraliser ce concept à de nombreuses autres applications qui se résument souvent à passer des messages d'un appareil à un autre. Session a été lancée sous un nom différent et a immédiatement grandi. Il est devenu clair que l'attention devait se concentrer sur Session, et ce qui était à l'origine conçu comme une preuve de concept s'est transformé en l'une des plus grandes applications de messagerie privée disponibles aujourd'hui.
Q2. La récente directive d'urgence du CISA a identifié deux failles critiques dans TM SGNL. De votre point de vue, qu'est-ce qui n'a pas fonctionné dans la conception ou la mise en œuvre qui a permis aux attaquants de récolter des journaux de discussion et des métadonnées ?
Ceci est un cas classique de problèmes de conception et d'implémentation en cascade qui, par eux-mêmes, pourraient ne pas être exploitables mais qui, combinés, peuvent provoquer une défaillance catastrophique dans la sécurité d'un réseau.
La première défaillance était dans la conception, TeleMessage a pris Signal, une application de messagerie sécurisée bien connue, et a ajouté ce qui équivalait à une porte dérobée intentionnelle dans l'application afin de créer un journal d'audit. Le fonctionnement de ce journal d'audit consistait à envoyer une copie de chaque message qu'un utilisateur envoyait, avant qu'il ne soit chiffré de bout en bout, à un serveur central unique, qui stockait ensuite une copie de tous ces messages dans un état non chiffré. Cela a créé un pot de miel pour les attaquants de données extrêmement sensibles, un trésor d'informations sur la sécurité nationale irrésistible pour les hackers.
Le deuxième échec était une mauvaise configuration d'un service (Spring Boot Actuator) qui fonctionnait sur le serveur d'archives TM SGNL. Il s'agit d'un problème de mauvaise configuration très basique où une URL généralement utilisée par les développeurs pour diagnostiquer des bogues était laissée ouverte à quiconque sans authentification. Cela a permis aux attaquants de vider la mémoire du serveur, dans ce vidage, des messages non chiffrés et des informations d'authentification pour les utilisateurs étaient visibles en texte clair, ce qui a permis aux pirates de récupérer des messages et des informations de compte.
Il est important de noter que les deux échecs devaient coexister pour qu'un piratage de cette ampleur se produise. C'est souvent le cas dans les violations de la cybersécurité, où les attaquants trouvent un seul défaut de conception ou d'implémentation, puis utilisent ce défaut pour identifier d'autres vulnérabilités à exploiter.
Q3. Quelle est la fréquence à laquelle les clients E2EE—même ceux compatibles avec Signal—introduisent de telles faiblesses, et pourquoi ne sont-elles pas détectées plus tôt ?
Les applications de messagerie grand public comme WhatsApp, Signal et Telegram ont généralement une bien meilleure sécurité autour de leurs serveurs que les serveurs TeleMessage. Cependant, en ce qui concerne les applications de messagerie développées et modifiées explicitement pour créer un journal d'audit des conversions, il est plus courant de voir ces types de mauvaises configurations. Surtout lorsque ces applications ont un code fermé, les chercheurs en sécurité de la communauté n'ont pas la même capacité à analyser le code pour détecter des faiblesses, donc les mauvaises configurations courantes peuvent rester inaperçues pendant longtemps ou être gardées secrètes par des hackers de niveau étatique pour maintenir des portes dérobées dans les systèmes qui ne sont pas corrigés.
Q4. Vous avez soutenu que tant qu'un seul fournisseur contrôle des parties clés de l'architecture, il y a un risque inhérent. Comment la centralisation des fournisseurs se traduit-elle par des échecs en matière de confidentialité dans le monde réel ?
La centralisation des fournisseurs est généralement associée à un code source fermé et à des serveurs centralisés. Lorsque un service de messagerie stocke tous les messages des utilisateurs en un seul endroit central, il crée un piège à miel pour les attaquants, ils savent qu'en pénétrant un seul serveur, ils obtiennent accès à tous les messages envoyés via le service. Lorsqu'elle est combinée avec un code source fermé qui ne peut pas être examiné par des chercheurs en sécurité et des auditeurs en open source, l'incitation pour les attaquants augmente, et les bugs qui auraient été découverts passent inaperçus pour tous sauf les attaquants les plus sophistiqués qui gardent ces bugs privés afin de pouvoir maintenir leur accès par porte dérobée, laissant tous les utilisateurs du service compromis.
Q5. Pourriez-vous partager un exemple ( en dehors de TM SGNL) où une faille du côté du vendeur a compromis les garanties du chiffrement de bout en bout ?
L'utilisation de Twilio par Signal pour la vérification SMS a conduit à la compromission de certains comptes d'utilisateurs de Signal lorsque Twilio a été piraté. Étant donné que la vérification par SMS est l'un des moyens par lesquels les utilisateurs de Signal peuvent récupérer leurs comptes, lorsque Twilio a été piraté, des attaquants ont pu tromper les serveurs de Signal pour qu'ils pensent qu'ils possédaient le numéro de téléphone d'un utilisateur de Signal et récupérer leur compte, utilisant cet accès pour envoyer des messages non autorisés depuis les comptes de ces utilisateurs de Signal.
Q6. Pourquoi pensez-vous que la décentralisation est le seul moyen de réduire complètement le risque d'un seul fournisseur ?
La décentralisation est le seul moyen de réduire complètement le risque lié à un fournisseur unique, car elle élimine le point de défaillance unique inhérent à tout système centralisé. Lorsqu'une seule entité contrôle des parties clés de l'architecture – des identités des utilisateurs à l'acheminement et au stockage des messages – elle devient une cible irrésistible pour les attaquants, et ses défauts de conception ou d'implémentation peuvent avoir des conséquences catastrophiques, comme on l'a vu avec TM SGNL.
Dans un réseau décentralisé, il n'y a pas de serveur central à violer, pas d'entreprise unique à contraindre à insérer des portes dérobées, et pas de base de données unique à cibler pour la collecte de métadonnées. Les identités des utilisateurs sont souvent des clés cryptographiques, pas des identifiants du monde réel liés à une autorité centrale. Les messages sont acheminés et stockés à travers un réseau distribué de nœuds indépendants, ce qui signifie qu'aucun nœud ne voit à la fois les adresses IP de l'expéditeur et du destinataire, et qu'aucune entité unique ne peut collecter un journal complet des communications.
Cette distribution du pouvoir et des données rend intrinsèquement le système plus résilient aux attaques, à la censure et à l'exploitation des données car il n'y a pas de point de défaillance unique à exploiter. La sécurité ne dépend pas de la fiabilité d'une seule entreprise, mais plutôt de l'intégrité collective et de la conception cryptographique robuste du réseau distribué.
Q7. Session utilise un réseau de nœuds de service. Comment cette architecture garantit-elle qu'aucune partie ne peut compromettre les données des utilisateurs ?
Contrairement aux applications de messagerie traditionnelles, Session ne s'appuie pas sur un serveur central unique qui stocke toutes les données des utilisateurs. Au lieu de cela, les messages sont acheminés à travers un réseau distribué de milliers de nœuds Session indépendants gérés par la communauté. Cela élimine l'effet "honeypot" d'une base de données centralisée unique, rendant extrêmement difficile pour une seule entité de collecter des messages et des métadonnées chiffrés de manière exhaustive. Les nœuds Session stockent temporairement les messages pour les destinataires hors ligne. Cependant, ces messages sont chiffrés de bout en bout, ce qui signifie que les nœuds eux-mêmes ne peuvent pas lire le contenu. De plus, les messages ne sont stockés que pour une durée limitée (Time-To-Live) et peuvent être supprimés une fois lus, empêchant la rétention à long terme sur le réseau de nœuds.
De plus, Session utilise une technique de routage en oignon modifiée, similaire à Tor. Lorsque vous envoyez un message, il est chiffré en couches, et chaque couche est retirée par des nœuds Session successifs. Il est crucial qu'aucun nœud unique ne connaisse à la fois les adresses IP de l'expéditeur et du destinataire. Cela signifie que même si un nœud était compromis, il ne pourrait pas relier un message à son origine ou à sa destination.
Les comptes de session sont générés de manière cryptographique sans nécessiter d'informations personnelles telles que des numéros de téléphone ou des adresses e-mail. Cela signifie qu'il n'y a pas d'identité réelle liée à votre identifiant de compte de session, ce qui renforce encore la confidentialité et rend plus difficile le compromis de l'identité d'un utilisateur par le biais de violations de données externes.
Cette approche multi-niveaux, sans point de contrôle central, avec stockage temporaire, cryptage de bout en bout et routage anonymisé, garantit que même si un petit nombre de nœuds de session étaient compromis, l'intégrité et la confidentialité globales du réseau resteraient intactes.
Q8. Étant donné le déploiement de TM SGNL dans les agences fédérales, pensez-vous que les gouvernements s'orientent vers un véritable messaging décentralisé ? Quels obstacles existent pour ce changement ?
C'est une question difficile. Les agences gouvernementales exigent généralement que des journaux de vérification soient créés et stockés de manière à être consultables par un auditeur, ce qui crée une vulnérabilité de sécurité inhérente. Le chiffrement de bout en bout est conçu de sorte que seuls les participants à la conversation devraient voir le contenu des communications. L'exigence d'audit introduit une porte dérobée intentionnelle dans le chiffrement de bout en bout, ce qui est difficile à mettre en œuvre de manière sécurisée.
Cependant, il existe des moyens de mieux gérer cela, par exemple, le journal d'audit doit toujours être stocké crypté au repos et il doit y avoir des protections robustes autour des utilisateurs qui peuvent accéder à ce journal d'audit. Les gouvernements devraient utiliser des outils open-source qui peuvent être facilement audités et réfléchir extrêmement soigneusement à la manière dont les journaux d'audit sont stockés et sur quels serveurs ils sont stockés.
Si la réglementation était mise à jour, cela pourrait offrir un moyen de mieux tirer parti des solutions décentralisées dans les communications gouvernementales.
Q9. Comment persuaderiez-vous une organisation soucieuse de la sécurité de migrer d'un client propriétaire compatible avec Signal vers Session ?
Je pense que le piratage de TM SGNL fournit la motivation la plus claire jusqu'à présent pour que les utilisateurs s'éloignent des solutions techniques propriétaires vers des outils open-source comme Session, qui offrent des fonctionnalités de sécurité et de confidentialité bien supérieures. Il pourrait être possible à l'avenir pour les organisations de prendre des outils open-source comme Session et de développer leurs propres outils d'audit qui se connectent à ces outils. Cependant, de telles solutions d'audit devraient elles-mêmes être open-source et auditable pour garantir que nous ne voyons pas les mêmes problèmes que TM SGNL réémerger.
Q10. En regardant vers l'avenir, quelles sont les principales caractéristiques ou améliorations prévues sur la feuille de route de Session pour les 12 à 18 prochains mois ? En fin de compte, quelle est votre vision à long terme pour Session et pour la messagerie sécurisée et privée en général ?
L'objectif actuel de Session est d'atteindre un plus grand nombre d'utilisateurs. Session compte déjà plus d'un million d'utilisateurs actifs mensuels, mais nous souhaitons voir encore plus d'utilisateurs choisir des solutions qui intègrent une forte confidentialité et sécurité au cœur de la conception de l'application. Les contributeurs de Session travaillent actuellement sur une suite premium de fonctionnalités pour les utilisateurs avancés de Session, permettant un financement durable pour l'écosystème Session. Cela inclut des fonctionnalités telles que des groupes plus nombreux, une plus grande personnalisation des profils et des tailles de fichiers augmentées, toutes des fonctionnalités qui augmentent l'utilité de Session.
Plus largement, je considère Session comme la seule application qui offre à la fois la confidentialité du contenu et des métadonnées dans une expérience très consommable et facile à utiliser, et je pense qu'à mesure que les violations de données continuent d'impacter les utilisateurs, Session connaîtra une croissance continue au cours des 12 à 18 prochains mois.
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
Réinventer la messagerie sécurisée : une plongée approfondie avec le co-fondateur de Session Kee Jefferys
Q1. Pouvez-vous nous expliquer brièvement l'histoire d'origine de Session et ce qui vous a motivé à construire un réseau de messagerie décentralisé ?
Session est la création conjointe de centaines de contributeurs du monde entier—c'est la beauté des logiciels open-source ; tout le monde peut écrire et contribuer au code de Session. Chaque produit, cependant, a une histoire de fondation plus centrale. Pour Session, les fondateurs originaux voulaient créer une application de preuve de concept sur un réseau décentralisé nouvellement établi. Nous pensions que la meilleure application de preuve de concept était de construire une application de messagerie qui stockait et acheminait des messages à travers ce réseau décentralisé, car une fois que vous aviez un messager de base, vous pouviez généraliser ce concept à de nombreuses autres applications qui se résument souvent à passer des messages d'un appareil à un autre. Session a été lancée sous un nom différent et a immédiatement grandi. Il est devenu clair que l'attention devait se concentrer sur Session, et ce qui était à l'origine conçu comme une preuve de concept s'est transformé en l'une des plus grandes applications de messagerie privée disponibles aujourd'hui.
Q2. La récente directive d'urgence du CISA a identifié deux failles critiques dans TM SGNL. De votre point de vue, qu'est-ce qui n'a pas fonctionné dans la conception ou la mise en œuvre qui a permis aux attaquants de récolter des journaux de discussion et des métadonnées ?
Ceci est un cas classique de problèmes de conception et d'implémentation en cascade qui, par eux-mêmes, pourraient ne pas être exploitables mais qui, combinés, peuvent provoquer une défaillance catastrophique dans la sécurité d'un réseau.
La première défaillance était dans la conception, TeleMessage a pris Signal, une application de messagerie sécurisée bien connue, et a ajouté ce qui équivalait à une porte dérobée intentionnelle dans l'application afin de créer un journal d'audit. Le fonctionnement de ce journal d'audit consistait à envoyer une copie de chaque message qu'un utilisateur envoyait, avant qu'il ne soit chiffré de bout en bout, à un serveur central unique, qui stockait ensuite une copie de tous ces messages dans un état non chiffré. Cela a créé un pot de miel pour les attaquants de données extrêmement sensibles, un trésor d'informations sur la sécurité nationale irrésistible pour les hackers.
Le deuxième échec était une mauvaise configuration d'un service (Spring Boot Actuator) qui fonctionnait sur le serveur d'archives TM SGNL. Il s'agit d'un problème de mauvaise configuration très basique où une URL généralement utilisée par les développeurs pour diagnostiquer des bogues était laissée ouverte à quiconque sans authentification. Cela a permis aux attaquants de vider la mémoire du serveur, dans ce vidage, des messages non chiffrés et des informations d'authentification pour les utilisateurs étaient visibles en texte clair, ce qui a permis aux pirates de récupérer des messages et des informations de compte.
Il est important de noter que les deux échecs devaient coexister pour qu'un piratage de cette ampleur se produise. C'est souvent le cas dans les violations de la cybersécurité, où les attaquants trouvent un seul défaut de conception ou d'implémentation, puis utilisent ce défaut pour identifier d'autres vulnérabilités à exploiter.
Q3. Quelle est la fréquence à laquelle les clients E2EE—même ceux compatibles avec Signal—introduisent de telles faiblesses, et pourquoi ne sont-elles pas détectées plus tôt ?
Les applications de messagerie grand public comme WhatsApp, Signal et Telegram ont généralement une bien meilleure sécurité autour de leurs serveurs que les serveurs TeleMessage. Cependant, en ce qui concerne les applications de messagerie développées et modifiées explicitement pour créer un journal d'audit des conversions, il est plus courant de voir ces types de mauvaises configurations. Surtout lorsque ces applications ont un code fermé, les chercheurs en sécurité de la communauté n'ont pas la même capacité à analyser le code pour détecter des faiblesses, donc les mauvaises configurations courantes peuvent rester inaperçues pendant longtemps ou être gardées secrètes par des hackers de niveau étatique pour maintenir des portes dérobées dans les systèmes qui ne sont pas corrigés.
Q4. Vous avez soutenu que tant qu'un seul fournisseur contrôle des parties clés de l'architecture, il y a un risque inhérent. Comment la centralisation des fournisseurs se traduit-elle par des échecs en matière de confidentialité dans le monde réel ?
La centralisation des fournisseurs est généralement associée à un code source fermé et à des serveurs centralisés. Lorsque un service de messagerie stocke tous les messages des utilisateurs en un seul endroit central, il crée un piège à miel pour les attaquants, ils savent qu'en pénétrant un seul serveur, ils obtiennent accès à tous les messages envoyés via le service. Lorsqu'elle est combinée avec un code source fermé qui ne peut pas être examiné par des chercheurs en sécurité et des auditeurs en open source, l'incitation pour les attaquants augmente, et les bugs qui auraient été découverts passent inaperçus pour tous sauf les attaquants les plus sophistiqués qui gardent ces bugs privés afin de pouvoir maintenir leur accès par porte dérobée, laissant tous les utilisateurs du service compromis.
Q5. Pourriez-vous partager un exemple ( en dehors de TM SGNL) où une faille du côté du vendeur a compromis les garanties du chiffrement de bout en bout ?
L'utilisation de Twilio par Signal pour la vérification SMS a conduit à la compromission de certains comptes d'utilisateurs de Signal lorsque Twilio a été piraté. Étant donné que la vérification par SMS est l'un des moyens par lesquels les utilisateurs de Signal peuvent récupérer leurs comptes, lorsque Twilio a été piraté, des attaquants ont pu tromper les serveurs de Signal pour qu'ils pensent qu'ils possédaient le numéro de téléphone d'un utilisateur de Signal et récupérer leur compte, utilisant cet accès pour envoyer des messages non autorisés depuis les comptes de ces utilisateurs de Signal.
Q6. Pourquoi pensez-vous que la décentralisation est le seul moyen de réduire complètement le risque d'un seul fournisseur ?
La décentralisation est le seul moyen de réduire complètement le risque lié à un fournisseur unique, car elle élimine le point de défaillance unique inhérent à tout système centralisé. Lorsqu'une seule entité contrôle des parties clés de l'architecture – des identités des utilisateurs à l'acheminement et au stockage des messages – elle devient une cible irrésistible pour les attaquants, et ses défauts de conception ou d'implémentation peuvent avoir des conséquences catastrophiques, comme on l'a vu avec TM SGNL.
Dans un réseau décentralisé, il n'y a pas de serveur central à violer, pas d'entreprise unique à contraindre à insérer des portes dérobées, et pas de base de données unique à cibler pour la collecte de métadonnées. Les identités des utilisateurs sont souvent des clés cryptographiques, pas des identifiants du monde réel liés à une autorité centrale. Les messages sont acheminés et stockés à travers un réseau distribué de nœuds indépendants, ce qui signifie qu'aucun nœud ne voit à la fois les adresses IP de l'expéditeur et du destinataire, et qu'aucune entité unique ne peut collecter un journal complet des communications.
Cette distribution du pouvoir et des données rend intrinsèquement le système plus résilient aux attaques, à la censure et à l'exploitation des données car il n'y a pas de point de défaillance unique à exploiter. La sécurité ne dépend pas de la fiabilité d'une seule entreprise, mais plutôt de l'intégrité collective et de la conception cryptographique robuste du réseau distribué.
Q7. Session utilise un réseau de nœuds de service. Comment cette architecture garantit-elle qu'aucune partie ne peut compromettre les données des utilisateurs ?
Contrairement aux applications de messagerie traditionnelles, Session ne s'appuie pas sur un serveur central unique qui stocke toutes les données des utilisateurs. Au lieu de cela, les messages sont acheminés à travers un réseau distribué de milliers de nœuds Session indépendants gérés par la communauté. Cela élimine l'effet "honeypot" d'une base de données centralisée unique, rendant extrêmement difficile pour une seule entité de collecter des messages et des métadonnées chiffrés de manière exhaustive. Les nœuds Session stockent temporairement les messages pour les destinataires hors ligne. Cependant, ces messages sont chiffrés de bout en bout, ce qui signifie que les nœuds eux-mêmes ne peuvent pas lire le contenu. De plus, les messages ne sont stockés que pour une durée limitée (Time-To-Live) et peuvent être supprimés une fois lus, empêchant la rétention à long terme sur le réseau de nœuds.
De plus, Session utilise une technique de routage en oignon modifiée, similaire à Tor. Lorsque vous envoyez un message, il est chiffré en couches, et chaque couche est retirée par des nœuds Session successifs. Il est crucial qu'aucun nœud unique ne connaisse à la fois les adresses IP de l'expéditeur et du destinataire. Cela signifie que même si un nœud était compromis, il ne pourrait pas relier un message à son origine ou à sa destination.
Les comptes de session sont générés de manière cryptographique sans nécessiter d'informations personnelles telles que des numéros de téléphone ou des adresses e-mail. Cela signifie qu'il n'y a pas d'identité réelle liée à votre identifiant de compte de session, ce qui renforce encore la confidentialité et rend plus difficile le compromis de l'identité d'un utilisateur par le biais de violations de données externes.
Cette approche multi-niveaux, sans point de contrôle central, avec stockage temporaire, cryptage de bout en bout et routage anonymisé, garantit que même si un petit nombre de nœuds de session étaient compromis, l'intégrité et la confidentialité globales du réseau resteraient intactes.
Q8. Étant donné le déploiement de TM SGNL dans les agences fédérales, pensez-vous que les gouvernements s'orientent vers un véritable messaging décentralisé ? Quels obstacles existent pour ce changement ?
C'est une question difficile. Les agences gouvernementales exigent généralement que des journaux de vérification soient créés et stockés de manière à être consultables par un auditeur, ce qui crée une vulnérabilité de sécurité inhérente. Le chiffrement de bout en bout est conçu de sorte que seuls les participants à la conversation devraient voir le contenu des communications. L'exigence d'audit introduit une porte dérobée intentionnelle dans le chiffrement de bout en bout, ce qui est difficile à mettre en œuvre de manière sécurisée.
Cependant, il existe des moyens de mieux gérer cela, par exemple, le journal d'audit doit toujours être stocké crypté au repos et il doit y avoir des protections robustes autour des utilisateurs qui peuvent accéder à ce journal d'audit. Les gouvernements devraient utiliser des outils open-source qui peuvent être facilement audités et réfléchir extrêmement soigneusement à la manière dont les journaux d'audit sont stockés et sur quels serveurs ils sont stockés.
Si la réglementation était mise à jour, cela pourrait offrir un moyen de mieux tirer parti des solutions décentralisées dans les communications gouvernementales.
Q9. Comment persuaderiez-vous une organisation soucieuse de la sécurité de migrer d'un client propriétaire compatible avec Signal vers Session ?
Je pense que le piratage de TM SGNL fournit la motivation la plus claire jusqu'à présent pour que les utilisateurs s'éloignent des solutions techniques propriétaires vers des outils open-source comme Session, qui offrent des fonctionnalités de sécurité et de confidentialité bien supérieures. Il pourrait être possible à l'avenir pour les organisations de prendre des outils open-source comme Session et de développer leurs propres outils d'audit qui se connectent à ces outils. Cependant, de telles solutions d'audit devraient elles-mêmes être open-source et auditable pour garantir que nous ne voyons pas les mêmes problèmes que TM SGNL réémerger.
Q10. En regardant vers l'avenir, quelles sont les principales caractéristiques ou améliorations prévues sur la feuille de route de Session pour les 12 à 18 prochains mois ? En fin de compte, quelle est votre vision à long terme pour Session et pour la messagerie sécurisée et privée en général ?
L'objectif actuel de Session est d'atteindre un plus grand nombre d'utilisateurs. Session compte déjà plus d'un million d'utilisateurs actifs mensuels, mais nous souhaitons voir encore plus d'utilisateurs choisir des solutions qui intègrent une forte confidentialité et sécurité au cœur de la conception de l'application. Les contributeurs de Session travaillent actuellement sur une suite premium de fonctionnalités pour les utilisateurs avancés de Session, permettant un financement durable pour l'écosystème Session. Cela inclut des fonctionnalités telles que des groupes plus nombreux, une plus grande personnalisation des profils et des tailles de fichiers augmentées, toutes des fonctionnalités qui augmentent l'utilité de Session.
Plus largement, je considère Session comme la seule application qui offre à la fois la confidentialité du contenu et des métadonnées dans une expérience très consommable et facile à utiliser, et je pense qu'à mesure que les violations de données continuent d'impacter les utilisateurs, Session connaîtra une croissance continue au cours des 12 à 18 prochains mois.