El problema de las claves de API que nunca caducan
Una clave emitida hace años, que nunca se ha rotado y que hoy sigue siendo válida, no es una comodidad. Es un riesgo que nadie ha revisado de verdad en años.
La privacidad se vende como función más a menudo de lo que se construye como opción predeterminada. Un producto añade un interruptor de "modo privado", o un plan de pago que desactiva ciertos tipos de seguimiento, y lo llama argumento de venta. Ese planteamiento delata el diseño subyacente: si la privacidad es algo que puedes activar, era algo con lo que el producto no venía de serie para todos los que no fueron a buscar el interruptor.
No ejecutamos scripts de seguimiento sobre los visitantes de nuestro propio sitio ni de los sitios y aplicaciones que llaman a nuestra API, y no vendemos analíticas de visitantes recopiladas a través de nuestro servicio. La geolocalización de IP se hace en el lado del servidor, como parte de la respuesta a la solicitud que realmente hiciste, no como un canal lateral que recopila datos de comportamiento sobre la persona que está al otro lado de esa dirección IP. No hay ningún interruptor para esto porque no hay nada que desactivar. Nunca se construyó.
Esta distinción importa más en los datos de ubicación que en la mayoría de los demás tipos de API, porque una dirección IP o una consulta de dirección es, por naturaleza, información personal. Puede situar a alguien en una ciudad, a veces en un barrio. Un proveedor que obtiene esa información como efecto secundario de atender una comprobación antifraude o un cálculo de envío, y que además la conserva para crear un producto de analítica que vender a otros, ha convertido discretamente el tráfico de cada cliente en una segunda fuente de ingresos que ese cliente nunca aceptó.
Marcos normativos como el RGPD existen en parte porque este patrón se volvió lo bastante común como para necesitar una respuesta legal. Pero no creemos que la respuesta correcta a una cuestión de privacidad sea "qué exige técnicamente la normativa". Una normativa fija un mínimo. Construir hasta el mínimo porque es lo menos con lo que puedes salir del paso es una postura distinta de construir sin el seguimiento desde el principio porque decidiste que no debería existir en tu sistema, exija lo que exija el mínimo.
Aquí también hay un argumento práctico, no solo uno de principios. Una empresa que resuelve la geolocalización de IP en el lado del servidor, sin un script en el cliente que envíe datos a un tercero, tiene un sistema más fácil de entender y una superficie menor en la que algo puede salir mal. Menos lugares por los que fluyen los datos significa menos lugares desde los que pueden filtrarse, sufrir una brecha o reutilizarse más adelante por quien acabe siendo dueño de ese flujo de datos.
No pretendemos atribuirnos mérito por una contención que consideremos difícil. No vender los datos que recopilas como subproducto de un servicio de pago no es un problema de ingeniería complicado. Es una decisión de negocio, y es una que toma toda API de ubicación, lo diga o no en la página de precios. La nuestra es sencilla: la solicitud por la que pagas es el producto. Los datos que hay detrás no tienen una segunda vida de la que no te hayamos hablado.