Три типа пользовательских данных в веб-приложении

Дата публикации: 2024-03-14

У данных в веб-приложении есть три базовых режима доступа: публичный, личный и групповой. Это удобная модель для проектирования продукта и честного разговора с пользователем о том, кто именно увидит его информацию.

Как сложилась эта модель

Первые веб-приложения строились вокруг сервера и браузера. Сначала на сервере были доступны все данные, включая HTML. Затем появилась необходимость ограничивать доступ — так возникли групповые данные, доступные определённому кругу пользователей. Позднее cookies и CGI позволили персонализировать страницы.

• Публичные — их могут читать и изменять все, кому это разрешено правилами сервиса.
• Личные — доступны только конкретному пользователю.
• Групповые — принадлежат назначенной группе участников.

Архитектура влияет на данные

Классическая клиент-серверная архитектура хранила всё на сервере. При ограниченной пропускной способности появились кэши: на сервере, прокси, CDN и в браузере. Личные данные кэшировать проще, а публичные и групповые требуют согласованного обновления у многих людей. SSE и WebSocket позволяют серверу отправлять обновления в браузеры и уменьшают эту задержку.

Централизованное хранение личных данных создало рынок их обработки: компании анализируют поведение, предпочтения и связи пользователей. В ответ вырос запрос на контроль над личной информацией. Локальные localStorage и IndexedDB, защищённые облачные хранилища и проекты вроде Solid дают больше самостоятельности владельцу данных.

Децентрализация

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

Групповые данные для небольшой группы можно передавать напрямую, например через WebRTC. Для большой группы сервер обычно всё ещё выгоднее: он надёжнее распределяет изменения между всеми участниками. Децентрализация — не отказ от сервера, а разумное распределение ответственности.

Эффект Стрейси Барбранд

Эффект Барбры Стрейзанд описывает ситуацию, когда попытка скрыть сведения делает их заметнее. Обратный процесс тоже знаком: мем, ролик или картинка долго встречаются повсюду, а после смены моды исчезают из публичного интернета. Я называю это «эффектом Стрейси Барбранд» — постепенным затуханием публичной информации.

Поэтому личное хранилище важно даже для открытых данных. То, что сегодня лежит в сети и кажется обычным, завтра может быть невозможно найти, хотя для конкретного человека оно остаётся ценным.

Вывод

Для публичных, групповых и личных данных растёт потребность в клиентском хранении. IndexedDB, Cache Storage и Service Worker позволяют держать часть данных в браузере; серверу остаются доставка кода, обновления и задачи координации. WebRTC, более быстрые мобильные сети и мощные устройства расширяют эту возможность — включая локальное шифрование.

Но место хранения не отменяет ответственности: нужно ясно определить владельца, модель доступа, резервное копирование, синхронизацию и последствия потери устройства. Тогда более персональная и частично децентрализованная архитектура действительно даёт пользователю контроль, а не только переносит риски на него.

Вопрос о данных связан с общей работой браузерной среды: состоянием приложения, происхождением, доступом и профилем пользователя. Эта связь подробнее раскрыта в книге «Браузер как операционная система для разработки современных приложений».