--- title: "Los tres tipos de datos de usuario en aplicaciones web" description: "Datos públicos, personales y de grupo: cómo la arquitectura web condiciona su almacenamiento y acceso." date: 2024-03-14 --- Los datos de una aplicación web tienen tres modos básicos de acceso: público, personal y de grupo. Es un modelo útil para diseñar un producto y explicar con claridad quién puede ver la información de cada persona. ## Cómo surgió el modelo Las primeras aplicaciones web giraban alrededor de servidor y navegador. Al principio todos los datos, incluido HTML, estaban disponibles en el servidor. Después apareció la necesidad de limitar el acceso y nacieron los datos de grupo, accesibles para un conjunto de personas. Más tarde, las cookies y CGI hicieron posible personalizar las páginas. - **Públicos**: pueden leerlos y modificarlos quienes tengan permiso según las reglas del servicio. - **Personales**: solo debe acceder la persona concreta. - **De grupo**: pertenecen a un grupo determinado de participantes. ## La arquitectura cambia los datos La arquitectura cliente-servidor clásica guardaba todo en el servidor. Con ancho de banda limitado aparecieron cachés en servidor, proxy, CDN y navegador. Los datos personales se cachean con menos dificultades; los públicos y de grupo exigen actualizaciones coherentes para muchas personas. SSE y WebSocket permiten al servidor enviar cambios a los navegadores y reducen esa demora. El almacenamiento central de datos personales creó un mercado para su tratamiento: empresas analizan comportamientos, preferencias y relaciones. Como respuesta, creció la demanda de control. [localStorage](https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage), [IndexedDB](https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API), nubes seguras y proyectos como [Solid](https://solidproject.org/about) devuelven más autonomía a quien posee los datos. ## Descentralización Hoy un navegador o un almacenamiento independiente del servidor puede conservar y procesar una cantidad apreciable de datos personales. El servidor pasa a distribuir y actualizar el código de la aplicación, además de atender la información pública. Los datos de un grupo pequeño pueden intercambiarse directamente, por ejemplo con [WebRTC](https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API). Para un grupo grande el servidor suele seguir siendo preferible, pues reparte los cambios de modo fiable entre todos. Descentralizar no es eliminar el servidor, sino repartir las responsabilidades con criterio. ## El efecto Stracey Barbrand El efecto Barbra Streisand describe cómo intentar ocultar información puede volverla más visible. También existe el proceso inverso: un meme, vídeo o imagen aparece por todas partes durante un tiempo y, al pasar la moda, deja de encontrarse. Lo llamo «efecto Stracey Barbrand»: el desvanecimiento gradual de la información pública. Por eso el almacenamiento personal importa incluso para datos abiertos. Algo que hoy está disponible y parece corriente puede ser imposible de recuperar mañana, aunque siga teniendo valor para alguien. ## Conclusión Para datos públicos, de grupo y personales aumenta la necesidad de almacenamiento en el cliente. IndexedDB, Cache Storage y Service Worker permiten mantener parte de los datos en el navegador; el servidor conserva la distribución de código, actualizaciones y coordinación. WebRTC, redes móviles más rápidas y dispositivos potentes amplían estas posibilidades, incluido el cifrado local. Sin embargo, dónde se guarda un dato no elimina la responsabilidad: hay que definir propiedad, control de acceso, copias de seguridad, sincronización y qué ocurre si se pierde un dispositivo. Así una arquitectura más personal y parcialmente descentralizada da control real, y no solo traslada riesgos a la persona usuaria. Datos, origen, acceso y perfil de la persona usuaria se encuentran en el entorno más amplio del navegador descrito en [El navegador como sistema operativo para desarrollar aplicaciones modernas](/es/books/browser-as-operating-system.html).