Origin Private File System: handles, workers и границы приватности

Origin Private File System (OPFS) предоставляет веб-источнику приватную файловую область, которой управляет браузер и где хранятся данные приложения. Это не видимая пользователю папка загрузок; на неё распространяются правила хранения браузера. Handle обозначает запись внутри этой области, но не является универсальным путём и не даёт доступа другому источнику. BotBrowser может повторить разрешённый сценарий страницы и зафиксировать наблюдаемый результат, но не может обходить проверки origin, выдавать квоту или гарантировать сохранность на всех устройствах.

Что изолирует OPFS

navigator.storage.getDirectory() возвращает приватный корневой каталог источника. Созданные в нём файлы и каталоги связаны с origin и профилем браузера. Страница с https://a.example не может разрешить handle, созданный https://b.example, даже если приложения используют одно имя файла. Приватные файлы также отличаются от выбранных пользователем через диалог файлов. Руководство MDN по OPFS описывает эту модель и управляемый браузером жизненный цикл.

Объекты handle - это возможности внутри данной границы. FileSystemFileHandle обозначает файл, а FileSystemDirectoryHandle - каталог. Объект можно сохранить в IndexedDB и открыть позже, однако приложение должно обрабатывать отсутствующую запись, переименованный объект или очищенный профиль. Считайте его непрозрачным состоянием приложения, а не путём для показа или отправки серверу.

Граница определяется источником, а не аккаунтом. Несколько пользователей одного origin могут совместно использовать профиль, а один пользователь может иметь несколько профилей. Не превращайте успешный поиск handle в сигнал идентичности. Отсутствие handle может означать первый запуск, удаление, очистку браузера, другой профиль или миграцию приложения.

Handles и доступ workers

Workers могут обращаться к корню OPFS, что позволяет выполнять разбор данных и индексацию вне потока интерфейса. Worker по-прежнему работает в том же origin и профиле, а не становится файловым сервисом между источниками. Dedicated workers могут применять синхронные access handles в поддерживаемых контекстах; асинхронные методы остаются более переносимой основой. Проверяйте поддержку в фактическом контексте и предусмотрите альтернативу.

Определите явный протокол для handles. Страница может отправить worker ограниченную команду, а worker вернуть статус или производный результат. Не передавайте учётные данные, содержимое целых файлов или неограниченный канал сообщений, если достаточно небольшой операции. Проверяйте источник сообщения и имя операции; закрывайте worker по завершении задачи.

Для параллельной записи требуется правило приложения. Worker и вкладка могут одновременно владеть handle; браузер не выбирает, какое бизнес-обновление победит. Используйте ревизию, управляемую приложением блокировку или транзакционный формат. Запишите целую новую запись, обновите или закройте её согласно API, затем опубликуйте новую ревизию. При остановке worker посреди записи может остаться неполная запись, поэтому восстановление должно различать состояния «не начато», «зафиксировано» и «результат неизвестен после прерывания».

Результаты квоты и постоянного хранения

OPFS расходует квоту браузерного хранилища. navigator.storage.estimate() возвращает оценку, а не обещание ёмкости; другая вкладка или источник может изменить доступное место. Запись может завершиться ошибкой квоты, ограничений разрешений или политики либо особенностью реализации. Интерфейс должен сохранить ввод пользователя и объяснить следующий шаг, а не утверждать, что файл сохранён.

Постоянное хранение запрашивается, но не гарантируется. navigator.storage.persist() может вернуть true или false в зависимости от политики браузера, активности, состояния устройства и правил приватного просмотра. true описывает текущий origin и профиль; это не обещание резервной копии, экспорта или сохранения после очистки данных пользователем. Опишите срок хранения и предложите явный экспорт важных данных.

Используйте сведения о квоте для планирования ёмкости, но не для создания отпечатка. Записывайте общие результаты приложения, например saved, quota-full или storage-unavailable; не храните точную ёмкость устройства или долговременную сигнатуру хранилища. Удаляйте тестовые диагностические данные после проверки, а серверные записи аккаунта оставляйте только при необходимости для продукта.

Проверка с защитой приватности

Используйте тестовый origin и чистый профиль с синтетическими данными. Создайте небольшой файл, прочитайте его в том же источнике и повторите операцию из другого источника. Ожидаемый функциональный результат: второй origin не может разрешить handle первого. Это не свидетельство личности, производителя браузера или поведения всех API хранения.

Отдельно проверьте пути страницы и worker: создайте файл в странице, прочитайте в worker, остановите worker во время записи и откройте запись снова. Зафиксируйте семейство и версию браузера, категорию origin, состояние профиля, результат операции и видимую альтернативу. Не загружайте реальные документы и не собирайте полный список каталогов. После обновления браузера сравнивайте ту же fixture, не меняя одновременно профиль, версию приложения и политику хранения.

Спецификация File System Access API и стандарт хранения WHATWG определяют интерфейсы и понятия хранилища, но не обещают бизнес-результат. Успешный вызов API подтверждает только успех этой операции в данном контексте. Авторизация сервера, шифрование, срок хранения и восстановление остаются ответственностью приложения.

Граница продукта и восстановление

Сообщите пользователю, остаётся ли черновик в этом браузере, экспортируется в выбранный файл или загружается в аккаунт. Сохраняйте локальный черновик до подтверждения экспорта или загрузки. Добавьте понятное действие для очистки приватных файлов и оставьте страницу работоспособной без OPFS. Страница восстановления первой стороны может вернуть разрешённую запись аккаунта, но не должна молча копировать приватные файлы другого origin.

Если объект устарел, отличайте пустое рабочее пространство от сетевой ошибки. Для первого использования покажите настройку, при временной ошибке предложите повтор, а при очистке профиля - восстановление или экспорт. Доступный статус должен объяснять результат, не раскрывая приватное имя файла или идентификатор аккаунта.

BotBrowser может повторить разрешённый сценарий OPFS в объявленном профиле и сравнить видимые результаты поддерживаемых версий браузера. Он не управляет политикой квот, решением о постоянном хранении, изоляцией origin, планированием workers или серверным сроком хранения. Считайте запуск свидетельством для проверенного сценария и записывайте браузер, профиль, версию приложения и альтернативный путь.

Источники и дополнительное чтение

• MDN: Origin private file system
• WICG: File System Access
• WHATWG: стандарт хранилища
• MDN: StorageManager.persist()

Следующий безопасный шаг - запустить fixture для двух origin, страницы и worker с синтетическими данными и явной альтернативой при нехватке квоты или недоступности хранилища.

TL;DR

• Файлы OPFS принадлежат одному origin и профилю; handle не является общим путём или идентификатором.
• Worker работает в том же origin, но параллельной записи нужны ревизии и восстановление.
• Квота и постоянное хранение условны; сохраняйте ввод и предлагайте экспорт или альтернативу.

Contents

• Что изолирует OPFS
• Handles и доступ workers
• Результаты квоты и постоянного хранения
• Проверка с защитой приватности

Conclusion

OPFS - рабочая область, ограниченная origin, а не система резервного копирования. Храните handles непрозрачно и делайте записи worker восстанавливаемыми. См. разделение хранилища браузера и Web Locks.

Sources

• https://developer.mozilla.org/en-US/docs/Web/API/File_System_API/Origin_private_file_system
• https://wicg.github.io/file-system-access/