OPFS : handles, workers et limites de confidentialité
Comprendre l’isolation OPFS par origine, les handles, l’accès des workers, les résultats de quota et une validation respectueuse de la vie privée.
BotBrowser Team
Vous voulez la documentation structurée pour Plateforme ?
Cet article fait partie de la bibliothèque éditoriale. Pour les étapes de configuration, la référence et les mises à jour continues, passez directement à la section docs.
Origin Private File System (OPFS) fournit à une origine Web un espace de fichiers privé, géré par le navigateur, pour les données de l’application. Il ne s’agit pas du dossier de téléchargements visible par l’utilisateur et cet espace reste soumis aux règles de stockage du navigateur. Un handle désigne une entrée dans cet espace ; ce n’est ni un chemin universel ni une autorisation d’accès pour une autre origine. BotBrowser peut répéter un parcours de page autorisé et consigner les résultats visibles, mais ne peut pas contourner les contrôles d’origine, accorder du quota ni garantir la durabilité sur tous les appareils.
Ce qu’OPFS isole
navigator.storage.getDirectory() renvoie le répertoire racine privé de l’origine. Les fichiers et répertoires qui y sont créés sont associés à l’origine et au profil du navigateur. Une page sur https://a.example ne peut pas résoudre un handle créé par https://b.example, même si les deux applications utilisent le même nom de fichier. Les fichiers privés sont également distincts de ceux que l’utilisateur choisit via un sélecteur. Le guide OPFS de MDN décrit ce modèle et le cycle de vie géré par le navigateur.
Les handles sont des capacités à l’intérieur de cette limite. FileSystemFileHandle désigne une entrée de fichier et FileSystemDirectoryHandle, un répertoire. Un handle peut être conservé dans IndexedDB pour une réouverture ultérieure, mais l’application doit gérer une entrée absente, un enregistrement renommé ou un profil effacé. Traitez-le comme un état opaque de l’application, pas comme un chemin à afficher ou à transmettre au serveur.
La limite concerne l’origine, pas le compte. Plusieurs personnes peuvent partager un profil sur la même origine, et une personne peut avoir plusieurs profils. Ne faites pas de la réussite d’une recherche de handle un signal d’identité. Un handle absent peut correspondre à une première utilisation, une suppression, un nettoyage du navigateur, un autre profil ou une migration.
Handles et accès des workers
Les workers peuvent accéder à la racine OPFS, ce qui permet d’effectuer l’analyse ou l’indexation hors du thread d’interface. Le worker reste associé à la même origine et au même profil ; il ne devient pas un service de fichiers inter-origines. Les workers dédiés peuvent utiliser des handles d’accès synchrones dans les contextes compatibles ; les méthodes asynchrones constituent la base la plus portable. Vérifiez la capacité dans le contexte réel et prévoyez une solution de repli.
Définissez un protocole explicite pour les handles. La page peut envoyer une commande limitée au worker, qui renvoie un état ou un résultat dérivé. Ne transmettez ni identifiants, ni fichiers complets, ni canal de messages sans restriction lorsqu’une petite opération suffit. Validez l’origine du message et le nom de l’opération, puis fermez le worker une fois la tâche terminée.
Les écritures concurrentes nécessitent une règle applicative. Un worker et un onglet peuvent détenir le même handle ; le navigateur ne choisit pas quelle mise à jour métier prévaut. Utilisez une révision, un verrou contrôlé par l’application ou un format transactionnel. Écrivez un enregistrement complet, actualisez-le ou fermez-le selon l’API, puis publiez la nouvelle révision. L’arrêt d’un worker pendant une écriture peut laisser un enregistrement incomplet : la récupération doit distinguer « non démarré », « validé » et « résultat inconnu après interruption ».
Résultats de quota et de persistance
OPFS consomme le quota de stockage du navigateur. navigator.storage.estimate() fournit une estimation, pas une promesse de capacité ; un autre onglet ou une autre origine peut modifier l’espace disponible. Une écriture peut échouer pour cause de quota, de permissions, de politique ou d’erreur propre à l’implémentation. L’interface doit préserver la saisie de l’utilisateur et indiquer la suite, sans prétendre que le fichier est enregistré.
La persistance est une demande, pas une garantie. navigator.storage.persist() peut renvoyer true ou false selon la politique du navigateur, l’engagement, l’état de l’appareil et les règles de navigation privée. true décrit l’origine et le profil actuels ; cela ne promet ni sauvegarde, ni export, ni survie à l’effacement des données par l’utilisateur. Documentez la durée de conservation et proposez un export explicite pour les données importantes.
Utilisez les observations de quota pour planifier la capacité, jamais pour créer une empreinte. Consignez des résultats fonctionnels généraux comme saved, quota-full ou storage-unavailable ; évitez de conserver la capacité exacte de l’appareil ou une signature de stockage durable. Supprimez les données de diagnostic après le test et ne conservez des dossiers de compte côté serveur que si le produit le nécessite.
Validation respectueuse de la vie privée
Utilisez une origine de test synthétique et un profil vierge. Créez un petit fichier, lisez-le depuis la même origine, puis tentez la même opération depuis une seconde origine. Le résultat attendu est fonctionnel : la seconde origine ne peut pas résoudre le handle de la première. Cela ne révèle l’identité de personne, le fabricant du navigateur ni le comportement de toutes les API de stockage.
Testez séparément les parcours de page et de worker : créez un fichier dans une page, lisez-le dans un worker, arrêtez celui-ci pendant une écriture puis rouvrez l’enregistrement. Notez la famille et la version du navigateur, la catégorie d’origine, l’état du profil, le résultat et la solution visible. Ne téléversez pas de vrais documents et ne collectez pas la liste complète d’un répertoire. Après une mise à jour du navigateur, comparez la même fixture sans changer simultanément le profil, la version de l’application et la politique de stockage.
La spécification File System Access API et le standard de stockage WHATWG définissent les interfaces et les notions de stockage, pas un résultat métier. Un appel réussi prouve seulement que cette opération a réussi dans ce contexte. L’autorisation serveur, le chiffrement, la conservation et la récupération restent de la responsabilité de l’application.
Limite produit et récupération
Indiquez si un brouillon reste dans ce navigateur, est exporté vers un fichier choisi ou est envoyé à un compte. Gardez le brouillon local jusqu’à confirmation de l’export ou de l’envoi. Proposez une action claire pour effacer les fichiers privés et gardez la page utilisable quand OPFS est indisponible. Une page de récupération de première partie peut restaurer un enregistrement de compte autorisé, mais ne doit pas copier silencieusement les fichiers privés d’une autre origine.
Lorsqu’un handle est périmé, distinguez un espace vide d’une panne réseau. Affichez la configuration lors d’une première utilisation, une nouvelle tentative en cas d’échec transitoire et une action de récupération ou d’export si le profil a été effacé. Le statut accessible doit décrire le résultat sans révéler le nom privé du fichier ni l’identifiant du compte.
BotBrowser peut répéter un parcours OPFS autorisé dans un profil déclaré et comparer les résultats visibles entre les versions de navigateur prises en charge. Il ne contrôle ni la politique de quota, ni la décision de persistance, ni l’isolation d’origine, ni la planification des workers, ni la conservation serveur. Considérez l’exécution comme une preuve du parcours testé et consignez navigateur, profil, version de l’application et solution de repli.
Sources et lectures complémentaires
- MDN : Origin private file system
- WICG : File System Access
- WHATWG : Storage Standard
- MDN : StorageManager.persist()
La prochaine étape sûre consiste à exécuter une fixture à deux origines, page et worker, avec des données synthétiques et une solution explicite en cas de quota insuffisant ou d’indisponibilité du stockage.
TL;DR
- Les fichiers OPFS appartiennent à une origine et à un profil ; un handle n’est ni chemin partagé ni identité.
- Les workers restent dans la même origine et les écritures concurrentes exigent révisions et récupération.
- Quota et persistance sont conditionnels : préservez la saisie et proposez export ou solution de repli.
Contents
- Ce qu’OPFS isole
- Handles et accès des workers
- Résultats de quota et de persistance
- Validation respectueuse de la vie privée
Conclusion
OPFS est un espace lié à l’origine, pas une identité inter-sites ni une sauvegarde. Gardez les handles opaques et rendez les écritures récupérables. Consultez le partitionnement du stockage et Web Locks.
Sources
Articles Connexes
Faites passer BotBrowser de la recherche à la production
Utilisez ces guides pour comprendre le modèle, puis passez à la validation multi-plateforme, aux contextes isolés et au déploiement navigateur prêt pour l'échelle.