Un plan de vacaciones de grupo contiene nombres reales, fechas de disponibilidad y, en algunos casos, informacion sobre la ubicacion o el periodo de ausencia del hogar de varias personas. No es un dato financiero ni medico, pero si es informacion personal que el grupo no ha consentido compartir publicamente. Tratarlo con la misma cautela que cualquier otro dato privado no es paranoico: es lo razonable.
Minimos datos para maxima utilidad
Para calcular fechas de disponibilidad no hace falta pedir email obligatorio, telefono, fecha de nacimiento ni contraseña. Un nombre y unas franjas de disponibilidad son suficientes para el calculo. Cada dato extra que se pide tiene un coste doble: reduce la tasa de participacion del grupo y amplia la superficie de informacion personal que la app almacena.
Bajo el RGPD, aplicable en Espana a traves de la LOPDGDD, el principio de minimizacion de datos establece que solo deben tratarse los datos estrictamente necesarios para la finalidad declarada. Para una app de disponibilidad de vacaciones, esa finalidad es coordinar fechas, no construir un perfil de usuario.
Un enlace privado no equivale a una contrasena
Un enlace de acceso por token es comodo: no requiere login ni registro. Pero tiene una diferencia importante respecto a una contrasena: si alguien reenvila el enlace, otra persona puede acceder al plan con los datos de todos los participantes. La seguridad de ese enlace depende de quien lo comparte.
En grupos pequenos esto raramente es un problema real. En grupos grandes o cuando el plan incluye informacion sensible, lo mas prudente es usar invitaciones individuales en vez de un enlace general compartido en el chat.
Por que los planes privados no deben aparecer en Google
Si una URL con los datos de un plan de vacaciones es publica (accesible sin login) y no tiene instrucciones explicitas para los rastreadores, Google puede indexarla. Eso significaria que los nombres de los participantes, las fechas del viaje y la disponibilidad del grupo podrian aparecer en resultados de busqueda.
La forma correcta de evitarlo es servir esas paginas con la etiqueta meta `<meta name="robots" content="noindex">` en el HTML o con la cabecera HTTP `X-Robots-Tag: noindex`. Google explica que para que esta directiva funcione, la pagina debe ser accesible para el rastreador: si se bloquea en robots.txt, el rastreador no puede leer el noindex.