Répertoires

Le partage de répertoires est un des cas d‘usage les plus fréquents pour les services de gestion de fichiers. C‘est une fonctionnalité incontournable aussi bien dans les solutions centralisées (Dropbox, Google Drive, etc) que décentralisées (nextCloud, Seafile, etc). Contrairement à l‘album photos qui est une structure « à plat », les répertoires ont une structure hiérarchique et peuvent contenir des sous-répertoires, eux-mêmes pouvant avoir des fichiers et sous-répertoires, etc.

Un système de fichiers virtuel, ou Virtual File System (VFS) est utilisé dans Cozy pour représenter cette hiérarchie et fournir les API nécessaires pour la manipuler⁷⁹. Cela fournit l‘abstraction nécessaire pour utiliser des couches de stockage qui peuvent varier selon

79

146 l‘hébergement. Par exemple, Swift80

pour un hébergement mutualisé, ou le système de fichiers du système d‘exploitation du serveur en cas d‘auto-hébergement. Au niveau de la base de données, chaque répertoire et fichier est représenté par un document JSON qui contient entre autres un champ dir_id qui indique l‘identifiant du répertoire parent. Il est laissé vide pour le répertoire racine. Ce champ est à la base de l‘indexation pour calculer la hiérarchie et pour en assurer les divers contrôles d‘intégrité, par exemple s‘assurer qu‘un enfant n‘a qu‘un seul parent.

La Figure 27 montre un exemple d‘expression de partage de répertoire, qui peut se résumer à indiquer l‘identifiant du dossier à partager dans le champ values. Toute la hiérarchie est automatiquement gérée par un trigger dédié. Ce dernier parcourt récursivement la hiérarchie et écoute toute modification pouvant avoir lieu sur le dossier racine ou un de ses descendants de n‘importe quel niveau afin de mettre à jour le partage.

Figure 27. Déclaration d'un partage de répertoire

L‘interface pour partager un répertoire est la même que pour un album photo ; en effet le code front-end a été mutualisé afin d‘obtenir une interface cohérente pour l‘utilisateur entre les applications et pour faciliter le développement de nouveaux cas d‘usages en disposant d‘une librairie clé en main pour le partage.

80

147 A noter qu‘il est aussi possible de partager un simple fichier : l‘expression du partage reste la même, et le fait que ce soit un fichier sera automatiquement détecté par l‘API du VFS. Ce cas peut être vu comme un sous-ensemble du partage de répertoire, sans aucune gestion de hiérarchie.

Ainsi, ce dernier cas d‘usage concrétise la volonté de Cozy d‘obtenir un Minimum Valuable Product (MVP), recentré autour des applications permettant de gérer des fichiers, en les important depuis des sources externes (application Collect) ou de les visualiser en albums photos (application Photos). Les fonctionnalités de partage sont essentielles pour un produit comme Cozy, qui vise à devenir le domicile numérique des individus et donc devenir le point d‘entrée pour des fonctionnalités sociales et décentralisées.

De nombreux autres cas d‘usages intéressants peuvent être envisagés dans le futur. Aux classiques partages de calendrier ou notes, des scénarios plus précis pourraient être explorés. Par exemple, le partage en lecture seule d‘un compte bancaire par un mineur ou une personne âgée avec des membres de sa famille. Ces derniers pourraient alors superviser les comptes depuis leur propre Cloud personnel, sans pouvoir intervenir sans l‘aval du propriétaire du partage. Pour rester dans le domaine financier, on peut également imaginer pouvoir créer un compte commun sur une crypto-monnaie comme Bitcoin [Nakamoto 2008], via un partage en écriture sur le portefeuille électronique. Enfin, pour exploiter toute la puissance d‘expression du partage, des règles sur des données transverses peuvent être envisagées, par exemple l‘ensemble des documents relatifs à un projet, qu‘ils soient des rapports, des entrées de calendrier, des factures, etc. Ou encore partager les PDF de papiers de recherche d‘un sujet précis, avec les notes correspondantes prises dans une application séparée. Ce seraient autant de cas d‘usages intéressants, et qui s‘inscrivent parfaitement dans la logique de SWYSWYK.

5.5 Conclusion

Nous avons présenté ici l‘implémentation industrielle du modèle SWYSWYK dans la plateforme de Cloud personnel Cozy. Bien que partielle, cette implémentation permet l‘expression de règles de partage basiques et réflexives dont l‘évaluation via un système de

148

triggers permet de générer de nouvelles permissions et de gérer dynamiquement les évolutions des documents impactant les partages. Trois cas d‘usages ont été présentés, chacun ayant été l‘objet d‘un déploiement en production et utilisable par les utilisateurs Cozy Cloud.

Le protocole respecte la propriété d’empowerment éclairé en permettant d‘une part à l‘émetteur de pouvoir à tout moment visualiser les documents partagés et leurs destinataires, et d‘autre part en générant une page de permissions afin que chaque destinataire soit conscient de ce qui lui est partagé et des droits associés, pour qu‘il l‘accepte ou refuse en toute conscience.

La propriété d‘auto-administration des sujets est partiellement réalisée par l‘utilisation des fiches contacts du Cozy pour représenter les destinataires du partage et en laissant la possibilité à ces derniers de compléter eux-mêmes l‘adresse de leur Cloud personnel afin que leur fiche contact chez l‘émetteur soit automatiquement complétée.

En revanche, la propriété de sécurité par construction n‘est pas respectée ici. Garantie par l‘utilisation de l‘architecture, présentée au Chapitre 3, le respect de cette propriété impose de nombreuses contraintes afin de garantir qu‘aucune donnée ne puisse être divulguée à l‘insu du propriétaire. Elle nécessite notamment l‘utilisation d‘un environnement sécurisé, par exemple le matériel sécurisé PlugDB, et l‘utilisation d‘interfaces d‘administration physiquement isolées. Or, l‘objectif initial pour Cozy Cloud était de pouvoir disposer d‘un système de partage simple, performant, avec une sécurité acceptable et pouvant être déployée à la fois en auto-hébergement, c'est-à-dire un serveur physiquement directement géré par un utilisateur, et dans une infrastructure mutualisée gérée par un hébergeur professionnel. La faisabilité technique de l‘intégration de PlugDB dans Cozy a été prouvée par des démonstrateurs [Tran-Van, SWYSWYK: A New Sharing Paradigm for the Personal Cloud. 2017] [Tran-Van, Partage de documents sécurisé entre Cloud personnels 2015] et son intérêt motivé dans [Andre 2016]. Cependant, cette intégration implique un accès physique aux serveurs du propriétaire, ce qui est le cas pour un hébergement à la maison, mais n‘est pas possible avec des infrastructures mutualisées, sur lesquelles repose l‘offre commerciale Cozy Cloud.

La sécurité de l‘implémentation actuelle, certes réduite, n‘est néanmoins pas nulle, grâce à l‘utilisation du chiffrement de la base de données et des échanges entre les pairs, au

149 protocole d‘authentification fondé sur le standard OAuth2 et du système de permission. L‘utilisation de systèmes d‘isolations tels que nsjail ou des enclaves sécurisées de type Intel SGX [Costan 2016] ou ARM TrustZone [Alves 2004] sont des pistes envisageables pour disposer d‘une sécurité accrue, même sur des solutions d‘hébergement mutualisé. Mais leur incorporation dans l‘offre commerciale Cozy Cloud reste à faire et doit répondre à des problématiques qui vont au-delà de la seule dimension technique.

150