--- title: "Три типа пользовательских данных в веб-приложении" description: "Публичные, личные и групповые данные: как архитектура веб-приложения влияет на их хранение и доступ." date: 2024-03-14 --- У данных в веб-приложении есть три базовых режима доступа: публичный, личный и групповой. Это удобная модель для проектирования продукта и честного разговора с пользователем о том, кто именно увидит его информацию. ## Как сложилась эта модель Первые веб-приложения строились вокруг сервера и браузера. Сначала на сервере были доступны все данные, включая HTML. Затем появилась необходимость ограничивать доступ — так возникли групповые данные, доступные определённому кругу пользователей. Позднее cookies и CGI позволили персонализировать страницы. - **Публичные** — их могут читать и изменять все, кому это разрешено правилами сервиса. - **Личные** — доступны только конкретному пользователю. - **Групповые** — принадлежат назначенной группе участников. ## Архитектура влияет на данные Классическая клиент-серверная архитектура хранила всё на сервере. При ограниченной пропускной способности появились кэши: на сервере, прокси, CDN и в браузере. Личные данные кэшировать проще, а публичные и групповые требуют согласованного обновления у многих людей. SSE и WebSocket позволяют серверу отправлять обновления в браузеры и уменьшают эту задержку. Централизованное хранение личных данных создало рынок их обработки: компании анализируют поведение, предпочтения и связи пользователей. В ответ вырос запрос на контроль над личной информацией. Локальные [localStorage](https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage) и [IndexedDB](https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API), защищённые облачные хранилища и проекты вроде [Solid](https://solidproject.org/about) дают больше самостоятельности владельцу данных. ## Децентрализация Сегодня браузер или независимое от сервера хранилище способны держать и обрабатывать значительный объём личных данных. Тогда сервер главным образом раздаёт и обновляет код приложения, а также обслуживает публичную информацию. Групповые данные для небольшой группы можно передавать напрямую, например через [WebRTC](https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API). Для большой группы сервер обычно всё ещё выгоднее: он надёжнее распределяет изменения между всеми участниками. Децентрализация — не отказ от сервера, а разумное распределение ответственности. ## Эффект Стрейси Барбранд Эффект Барбры Стрейзанд описывает ситуацию, когда попытка скрыть сведения делает их заметнее. Обратный процесс тоже знаком: мем, ролик или картинка долго встречаются повсюду, а после смены моды исчезают из публичного интернета. Я называю это «эффектом Стрейси Барбранд» — постепенным затуханием публичной информации. Поэтому личное хранилище важно даже для открытых данных. То, что сегодня лежит в сети и кажется обычным, завтра может быть невозможно найти, хотя для конкретного человека оно остаётся ценным. ## Вывод Для публичных, групповых и личных данных растёт потребность в клиентском хранении. IndexedDB, Cache Storage и Service Worker позволяют держать часть данных в браузере; серверу остаются доставка кода, обновления и задачи координации. WebRTC, более быстрые мобильные сети и мощные устройства расширяют эту возможность — включая локальное шифрование. Но место хранения не отменяет ответственности: нужно ясно определить владельца, модель доступа, резервное копирование, синхронизацию и последствия потери устройства. Тогда более персональная и частично децентрализованная архитектура действительно даёт пользователю контроль, а не только переносит риски на него. Вопрос о данных связан с общей работой браузерной среды: состоянием приложения, происхождением, доступом и профилем пользователя. Эта связь подробнее раскрыта в книге [«Браузер как операционная система для разработки современных приложений»](/ru/books/browser-as-operating-system.html).