Terceros

¿Qué es un tercero?

Es bastante raro que un sitio web sea completamente independiente. El Web Almanac de HTTP muestra que la mayoría de los sitios web (alrededor del 95%) tienen contenido de terceros.

En Almanac, se define el contenido de terceros como algo alojado en un origen compartido y público, que se usa ampliamente en una variedad de sitios y no lo influye el propietario individual. Pueden ser imágenes o algún otro tipo de contenido multimedia, como videos, fuentes o secuencias de comandos. Las imágenes y las secuencias de comandos representan más que todo lo demás en conjunto. El contenido de terceros no es esencial para desarrollar un sitio, pero podría serlo. Lo más probable es que uses algo cargado desde un servidor compartido público, ya sean fuentes web, iframes de videos incorporados, anuncios o bibliotecas JavaScript. Por ejemplo, podrías usar fuentes web que se entregan desde Google Fonts o medir estadísticas con Google Analytics. También es posible que hayas agregado botones Me gusta o botones Acceder con de las redes sociales, que incorpores mapas o videos, o administres compras a través de servicios de terceros. También podrías estar haciendo un seguimiento de errores y registros para tus propios equipos de desarrollo a través de herramientas de supervisión de terceros.

Por motivos de privacidad, es útil considerar una definición un poco diferente y menos amplia: un recurso de terceros y, en particular, una secuencia de comandos de terceros, se entrega desde un origen compartido y público y se usa ampliamente como se ilustra, pero también es de alguien que no es el propietario del sitio. El aspecto de la autoría de terceros es lo más importante cuando se considera cómo proteger la privacidad de los usuarios. Esto te llevará a considerar qué riesgos están presentes y, luego, decidir cómo usar o si usar un recurso de terceros en función de esos riesgos. Como ya se mencionó, estos elementos te ayudarán a comprender el contexto y, por lo tanto, a comprender qué concesiones debes hacer y qué significan.

Esto no es exactamente lo que se quiere decir cuando se habla de "recursos de terceros" en general: la distinción entre los datos propios y de terceros se relaciona en realidad con el contexto en el que se utiliza un elemento. Una secuencia de comandos que se carga desde otro sitio web es un recurso de terceros, y la solicitud HTTP que carga la secuencia de comandos puede incluir cookies, pero esas cookies no son realmente "cookies de terceros"; en realidad, son "cookies" o "propias" depende de si la secuencia de comandos se carga en una página de tu sitio o en una página del sitio del propietario de la secuencia de comandos.

¿Por qué usamos recursos de terceros?

Los terceros son una excelente manera de agregar funcionalidad a tu sitio. Pueden ser funciones que están expuestas a los usuarios o funciones invisibles del desarrollador, como el seguimiento de errores, pero reducen la carga de desarrollo, y otra persona mantiene las secuencias de comandos: el equipo de desarrollo del servicio que incluyes. Todo esto funciona gracias a la composición de la Web: poder juntar partes para formar un todo que sea mayor que su suma.

El algoritmo web del archivo HTTP ofrece una buena descripción:

Los terceros proporcionan una colección interminable de imágenes, videos, fuentes, herramientas, bibliotecas, widgets, herramientas de seguimiento, anuncios y cualquier otro elemento que puedas imaginar incorporado en nuestras páginas web. Esto permite que incluso los menos técnicos puedan crear y publicar contenido en la Web. Sin terceros, es probable que la Web sea un medio académico muy aburrido y basado en texto, en lugar de una plataforma valiosa, inmersiva y compleja que es tan fundamental para la vida de muchos de nosotros en la actualidad.

¿Qué pueden hacer los recursos de terceros?

Acceso a cierta información

Cuando usas un recurso de un tercero en tu sitio web, independientemente de cuál sea, cierta información se transmite a ese tercero. Por ejemplo, si incluyes una imagen de otro sitio, la solicitud HTTP que realiza el navegador del usuario transmitirá un encabezado de referencia con la URL de tu página y la dirección IP del usuario.

Seguimiento entre sitios

Siguiendo con el mismo ejemplo, cuando la imagen se carga desde el sitio de terceros, se puede incluir una cookie que se enviará de vuelta al tercero cuando el usuario solicite esa imagen de nuevo. Esto significa que el tercero puede saber que se está usando su servicio en tu sitio y puede devolver una cookie, posiblemente con un ID único para ese usuario. Esto significa que la próxima vez que el usuario visite tu sitio o cualquier otro que incluya un recurso de ese tercero, esa cookie de ID única se volverá a enviar. Esto permite que el tercero cree un registro de los lugares que visita el usuario: tu sitio, otros sitios que usan el mismo recurso de terceros, por toda la Web.

Este es el seguimiento entre sitios, que permite que un tercero recopile un registro de la actividad de un usuario en muchos sitios web, siempre que esos sitios web utilicen un recurso que provenga del mismo tercero. Podría ser una fuente, una imagen o una hoja de estilo, todos recursos estáticos. También puede ser un recurso dinámico: un guion, un botón de redes sociales, un anuncio. La secuencia de comandos incluida puede recopilar aún más información, porque es dinámica: puede inspeccionar el navegador y el entorno del usuario, y pasar esos datos a su creador. Cualquier secuencia de comandos puede cumplir este objetivo, al igual que los recursos dinámicos que no se presentan como secuencias de comandos, como una incorporación en redes sociales, un anuncio o un botón para compartir. Si observas los detalles de un banner de cookie en sitios web populares, podrás ver una lista de las organizaciones que pueden agregar una cookie de seguimiento a tus usuarios para crear una imagen de sus actividades y crear un perfil de ese usuario. Puede haber cientos. Si un tercero ofrece un servicio de forma gratuita, una forma en que puede ser económicamente viable es porque recopila y monetiza estos datos.

El Modelo de amenazas a la privacidad de los objetivos es una guía útil sobre los tipos de problemas de privacidad de los que un navegador debe proteger a los usuarios. Este documento aún se está debatiendo al momento de su redacción, pero incluye algunas clasificaciones de alto nivel de los tipos de amenazas a la privacidad que existen. Los riesgos de los recursos de terceros son, principalmente, el “reconocimiento entre sitios no deseado”, en el que un sitio web puede identificar al mismo usuario en varios sitios, y la “divulgación de información sensible”, en la que un sitio puede recopilar información que un usuario considera sensible.

Esta es una distinción clave: el reconocimiento no deseado entre sitios es perjudicial, incluso si el tercero no recopila información sensible adicional de él, ya que le quita el control de su identidad al usuario. Obtener acceso a la URL de referencia, a la dirección IP y a las cookies de un usuario es una divulgación no deseada en sí misma. El uso de recursos de terceros viene junto con un componente de planificación sobre cómo los utilizarás de una manera que preserve la privacidad. Parte de ese trabajo está a tu cargo como desarrollador del sitio, mientras que el resto lo realiza el navegador en su función de usuario-agente; es decir, el agente que trabaja en nombre del usuario para evitar la divulgación de información sensible y el reconocimiento no deseado entre sitios siempre que sea posible. A continuación, analizaremos en detalle las mitigaciones y los enfoques a nivel del navegador y del desarrollo del sitio.

Código de terceros del servidor

Nuestra definición anterior de tercero alteró deliberadamente el enfoque del cliente de HTTP (según corresponda para su informe) a fin de incluir la autoría de terceros, porque, desde una perspectiva de privacidad, un tercero es cualquier persona que sepa algo sobre tus usuarios que no seas tú.

Esto incluye a terceros que proporcionen servicios que usted utiliza en el servidor, así como también al cliente. Desde el punto de vista de la privacidad, también es importante entender una biblioteca de terceros (como algo incluido de NPM, Composer o NuGet). ¿Tus dependencias pasan datos fuera de tus fronteras? Si pasas datos a un servicio de registro o a una base de datos alojada de forma remota, si las bibliotecas también incluyes un “teléfono de inicio” para sus autores, pueden infringir la privacidad de tus usuarios y, por lo tanto, deban auditarse. Por lo general, tú debes entregar los datos del usuario a un tercero basado en el servidor, lo que significa que los datos a los que están expuestos están más bajo tu control. En cambio, un tercero basado en el cliente (una secuencia de comandos o un recurso HTTP que se incluye en tu sitio web y que se obtiene mediante el navegador del usuario) puede recopilar algunos datos directamente del usuario sin que intervenga ese proceso de recopilación. La mayor parte de este módulo se centrará en cómo identificar a los terceros del cliente que elegiste incluir y a los que puedes exponer a tus usuarios, precisamente porque tú puedes realizar menos mediación. Sin embargo, vale la pena considerar la posibilidad de proteger el código del servidor para que comprendas las comunicaciones salientes que proviene de él y puedas registrar o bloquear cualquiera que sea inesperada. Los detalles sobre cómo hacer esto exactamente están fuera de nuestro alcance aquí (y dependen de la configuración de tu servidor), pero esta es otra parte de tu postura de seguridad y privacidad.

¿Por qué es necesario ser cuidadoso con los terceros?

Las secuencias de comandos y funciones de terceros son muy importantes, y nuestro objetivo como desarrolladores web debe ser integrar todo, no alejarse de ellos. Pero hay problemas potenciales. El contenido de terceros puede crear problemas de rendimiento y de seguridad porque aportas un servicio externo que está dentro de tu límite de confianza. Pero el contenido de terceros también puede crear problemas de privacidad.

Cuando hablamos de recursos de terceros en la Web, es útil pensar en los problemas de seguridad (entre otras cosas) que un tercero puede robar datos de tu empresa y contrastar esto con los problemas de privacidad, que son (entre otras cosas) cuando un tercero que incluiste roba u obtiene acceso a los datos de tus usuarios sin tu consentimiento.

Un ejemplo de un problema de seguridad es cuando los “skimmers web” roban información de tarjetas de crédito, un recurso de terceros que se incluye en una página en la que un usuario ingresa los detalles de la tarjeta de crédito, posiblemente, robar esos detalles y enviarlos al tercero malicioso. Los creadores de estos guiones de skimmer son muy creativos al decidir dónde esconderlos. En un resumen, se describe cómo se ocultaron las secuencias de comandos de skimmer en el contenido de terceros, como las imágenes que se usan para logotipos del sitio, íconos de página y redes sociales, bibliotecas populares como jQuery, Modernizr y Google Tag Manager, widgets del sitio como ventanas de chat en vivo y archivos CSS.

Los problemas de privacidad son un poco diferentes. Estos terceros forman parte de tu oferta. Para que los usuarios sigan confiando en ti, debes estar seguro de que pueden confiar en ellos. Si un tercero que usas recopila datos sobre tus usuarios y los hace un uso inadecuado, dificulta la tarea de borrar o descubrir, sufre una violación de la seguridad de los datos o infringe las expectativas de tus usuarios, es probable que los usuarios perciban esta situación como un desglose de la confianza en tu servicio, no solo en el tercero. Es tu reputación y relación en línea. Por este motivo, es importante que te preguntes si confías en los terceros que usas en tu sitio.

¿Cuáles son algunos ejemplos de terceros?

En general, hablaremos de "terceros"; sin embargo, existen diferentes tipos, y estos tienen acceso a distintas cantidades de datos del usuario. Por ejemplo, si agregas un elemento <img> a tu HTML, cargado desde un servidor diferente, le brindarás a ese servidor información sobre tus usuarios diferente de la que podrías agregar si agregas un <iframe> o un elemento <script>. Estos son ejemplos más que una lista completa, pero es útil comprender las distinciones entre los diferentes tipos de elementos de terceros que puede emplear tu sitio.

Cómo solicitar un recurso entre sitios

Un recurso entre sitios es cualquier elemento de tu sitio que se cargue desde otro sitio y no sea <iframe> ni <script>. Entre los ejemplos, se incluyen <img>, <audio>, <video>, fuentes web cargadas por texturas CSS y WebGL. Todo se carga a través de una solicitud HTTP y, como se describió anteriormente, esas solicitudes incluyen todas las cookies establecidas por el otro sitio, la dirección IP del usuario solicitante y la URL de la página actual como referencia. Históricamente, todas las solicitudes de terceros incluían estos datos de forma predeterminada, aunque se realizaron esfuerzos por reducir o aislar los datos que varios navegadores pasan a terceros, como se describe más adelante en "Información sobre las protecciones de navegadores de terceros".

Cómo incorporar un iframe entre sitios

Un documento completo incorporado en tus páginas a través de un <iframe> puede solicitar acceso adicional a las APIs del navegador, además de la duplicación de cookies, la dirección IP y la URL de referencia. Qué APIs están disponibles para las páginas <iframe>d y cómo solicitan acceso son específicas del navegador y, actualmente, se están realizando cambios: Consulta la sección "Política de Permisos" a continuación si quieres conocer las iniciativas actuales para limitar o supervisar el acceso a las APIs en los documentos incorporados.

Cómo ejecutar JavaScript entre sitios

Si incluyes un elemento <script>, se carga y ejecuta JavaScript entre sitios en el contexto de nivel superior de tu página. Esto significa que la secuencia de comandos que se ejecuta tiene acceso completo a todo lo que hacen tus secuencias de comandos propias. Los permisos del navegador aún administran estos datos, por lo que solicitar la ubicación del usuario (por ejemplo) seguirá requiriendo su aceptación. Sin embargo, esa secuencia de comandos puede leer cualquier información presente en la página o disponible como variables de JavaScript, lo que incluye no solo las cookies que se pasan al tercero como parte de la solicitud, sino también las cookies destinadas únicamente a tu sitio. De la misma manera, una secuencia de comandos de terceros cargada en tu página puede realizar las mismas solicitudes HTTP que tu propio código, lo que significa que podría realizar solicitudes fetch() a tus APIs de backend para obtener datos.

Incluye bibliotecas de terceros en tus dependencias

Como se describió antes, es probable que el código del servidor también incluya dependencias de terceros, que no pueden distinguirse de tu propio código en su poder; el código que incluyas desde un repositorio de GitHub o la biblioteca de tu lenguaje de programación (npm, PyPI, Composer, etc.) puede leer los mismos datos que tu otro código.

Conocer a tus terceros

Por lo tanto, esto requiere comprender la lista de proveedores externos y cuáles son las posturas y políticas de privacidad, recopilación de datos y experiencia del usuario. Esa comprensión se vuelve parte de tu serie de compensaciones: qué tan útil e importante es el servicio, equilibrado con respecto a lo invasivo, inconveniente o inquietante que son sus demandas para los usuarios. El contenido de terceros proporciona valor porque se encarga del trabajo pesado de ti como propietario del sitio y te permite centrarte en tus competencias principales. Por lo tanto, tiene valor en este intercambio y sacrificar la comodidad y la privacidad del usuario para ofrecer una mejor experiencia del usuario. Sin embargo, es importante no confundir la experiencia del usuario con la del desarrollador. Sin embargo, decir que "es más fácil para nuestro equipo de desarrollo compilar el servicio" no es una historia atractiva para los usuarios.

Cómo obtener esa comprensión es el proceso de auditoría.

Audita a tus terceros

Comprender lo que hace un tercero es el proceso de auditoría. Puedes hacer esto de manera técnica y no técnica, y para un tercero individual y para toda tu colección.

Ejecutar una auditoría no técnica

El primer paso no es técnico: lee las políticas de privacidad de tus proveedores. Si incluyes recursos de terceros, consulta las políticas de privacidad. Deben ser extensos y estar llenos de texto legal, y es posible que algunos documentos usen algunos de los enfoques específicos de las advertencias en módulos anteriores, como declaraciones demasiado generales y sin ninguna indicación de cómo o cuándo se quitarán los datos recopilados. Es importante tener en cuenta que, desde la perspectiva del usuario, todos los datos que se recopilen en el sitio, incluidos los terceros, se regirán por estas políticas de privacidad. Incluso si haces todo correctamente, cuando eres transparente sobre tus objetivos y superas las expectativas de los usuarios en cuanto a la privacidad y la sensibilidad de los datos, es posible que los usuarios también te responsabilicen de cualquier cosa que hagan los terceros elegidos. Si hay algo en sus políticas de privacidad que no quieres decir en tus propias políticas porque disminuiría la confianza de los usuarios, considera si hay un proveedor alternativo.

Esto es algo que puede ir de la mano con la auditoría técnica que se analiza más adelante, ya que se informan entre sí. Debes conocer los recursos de terceros que estás incorporando por motivos comerciales (como redes de publicidad o contenido incorporado), ya que existirá una relación comercial. Este es un buen punto de partida para comenzar una auditoría no técnica. Es probable que la auditoría técnica también identifique a terceros, en especial aquellos incluidos por motivos técnicos y no comerciales (componentes externos, estadísticas, bibliotecas de utilidades) y que esa lista se puede unir con la lista de terceros centrados en el negocio. En este caso, el objetivo es que tú, como propietario del sitio, sientas que comprendes lo que hacen los terceros que agregas a tu sitio y que, como empresa, puedas presentar a tu asesor legal este inventario de terceros para asegurarte de cumplir con todas las obligaciones requeridas.

Ejecutar una auditoría técnica

Para una auditoría técnica, es importante usar los recursos in situ como parte del sitio web; es decir, no cargues una dependencia en un agente de prueba ni la inspecciones de esa manera. Asegúrate de ver cómo tus dependencias actúan como parte de tu sitio web real, implementadas en la Internet pública, en lugar de en modo de prueba o desarrollo. Es muy instructivo ver tu propio sitio web como un usuario nuevo. Abre el navegador en un perfil nuevo y limpio, de modo que no hayas accedido y no tengas un acuerdo almacenado, e intenta visitar tu sitio.

Regístrate en tu propio sitio para obtener una cuenta nueva, si proporcionas cuentas de usuario. Tu equipo de diseño habrá organizado este nuevo proceso de adquisición de usuarios desde una perspectiva de UX, pero puede ser ilustrativo para abordarlo desde una perspectiva de privacidad. No hagas clic en "Aceptar" en los Términos y Condiciones, en la advertencia de cookies o en la política de privacidad. Establece la tarea de usar tu propio servicio sin divulgar información personal ni tener cookies de seguimiento, y comprueba si puedes hacerlo y lo difícil que es hacerlo. También puede ser útil buscar en las herramientas para desarrolladores del navegador a fin de ver a qué sitios se accede y qué datos se pasan a ellos. Las Herramientas para desarrolladores proporcionan una lista de solicitudes HTTP separadas (por lo general, en una sección llamada "Red") y puedes ver desde aquí las solicitudes agrupadas por tipo (HTML, CSS, imágenes, fuentes, JavaScript, solicitudes iniciadas por JavaScript). También es posible agregar una columna nueva para mostrar el dominio de cada solicitud, lo que demostrará cuántos lugares diferentes se contactan, y es posible que haya una casilla de verificación llamada "solicitudes de terceros" para mostrar solo los terceros. (También puede ser útil usar los informes de Content-Security-Policy para realizar una auditoría continua, de la que se lee más adelante).

La herramienta "Request Map Generator" de Simon Hearne también puede ser una descripción general útil de todas las solicitudes secundarias que realiza una página disponible públicamente.

Este también es el punto en el que puedes incluir a terceros centrados en el negocio identificados como parte de la auditoría no técnica (es decir, la lista de empresas con las que tienes una relación financiera para utilizar sus recursos). En este caso, el objetivo es hacer coincidir la lista de terceros que crees que usas (de registros financieros y legales) y la que en realidad estás usando (y analizar qué solicitudes HTTP de terceros realiza tu sitio web). Debes poder identificar para cada tercero empresarial las solicitudes técnicas salientes que se realizan. Si no puedes identificar solicitudes en la auditoría técnica de un tercero identificado por la relación comercial, es importante averiguar por qué y que eso guíe tus pruebas: tal vez ese recurso de terceros solo se cargue en un país en particular, en un tipo de dispositivo en particular o para los usuarios que accedieron a sus cuentas. Esto ampliará la lista de áreas del sitio que se auditarán y garantizará que veas todos los accesos salientes. (O, tal vez, identifique un recurso de terceros por el que pagas y no usas, lo que siempre anima al departamento de finanzas).

Una vez que limites la lista de solicitudes a terceros que te gustaría que formen parte de la auditoría, si haces clic en una solicitud individual, se mostrarán todos sus detalles y, en particular, qué datos se pasaron a esa solicitud. También es muy común que una solicitud de terceros que inicie tu código luego inicie muchas otras solicitudes de terceros. Estos terceros adicionales también se "importan" a su propia política de privacidad. Esta tarea es compleja, pero valiosa y, a menudo, se puede insertar en los análisis existentes. Tu equipo de desarrollo de frontend ya debería estar auditando las solicitudes por motivos de rendimiento (quizás con la ayuda de las herramientas existentes, como WebPageTest o Lighthouse), y la incorporación de una auditoría de datos y privacidad en ese proceso puede facilitar el proceso.

El mapa de solicitud de web.dev.
Un mapa de solicitud (drásticamente simplificado) para web.dev que muestra sitios de terceros que solicitan sitios de terceros, etcétera.

Sí

Abre un navegador con un perfil de usuario nuevo y limpio, de modo que no hayas accedido y no tengas un acuerdo almacenado. Luego, abre el panel Red de herramientas para desarrolladores del navegador para ver todas las solicitudes salientes. Agrega una columna nueva para mostrar el dominio de cada solicitud y marca la casilla de verificación “Solicitudes de terceros” para mostrar solo los terceros, si están presentes. Luego, haz lo siguiente:

  • Visita tu sitio.
  • Regístrate para obtener una cuenta nueva, si proporcionas cuentas de usuario.
  • Intenta borrar la cuenta que creaste.
  • Realizar una o dos acciones normales en el sitio (lo que se realice exactamente dependerá de lo que haga tu sitio, pero debes elegir las acciones comunes que realice la mayoría de los usuarios).
  • Realiza una o dos acciones que, según sepas, involucran dependencias de terceros en particular. Estos pueden incluir compartir contenido en redes sociales, iniciar un flujo de confirmación de la compra o incorporar contenido de otro sitio.

Cuando realices cada una de estas tareas, registra los recursos solicitados desde dominios que no sean tuyos. Para ello, observa el panel Network como se describe. Estos son algunos de tus terceros. Una buena manera de hacerlo es usar las herramientas de red del navegador para capturar los registros de solicitud de red en un archivo HAR.

Archivos HAR y captura

Un archivo HAR es un formato JSON estandarizado de todas las solicitudes de red que realiza una página. Para obtener un archivo HAR de una página en particular, haz lo siguiente:

Chrome

Abre las Herramientas para desarrolladores del navegador (Menú > Más herramientas > Herramientas para desarrolladores), ve al panel Network, carga (o actualiza) la página y elige el símbolo de la flecha hacia abajo para guardar en la esquina superior derecha, cerca del menú desplegable Sin limitación.

El panel de red de las Herramientas para desarrolladores de Chrome con el símbolo de descarga HAR destacado.
Firefox

Abre las herramientas para desarrolladores del navegador (Menú > Más herramientas > Herramientas para desarrolladores web), ve al panel Red, carga (o actualiza) la página y elige el símbolo de engranaje en la esquina superior derecha, junto al menú desplegable de limitación. En el menú, selecciona Save All As HAR**.

El panel de red de herramientas para desarrolladores de Firefox. Se destaca la opción Guardar todo como Har (Save All As Har).
Safari

Abre las herramientas para desarrolladores del navegador (Menu > Develop > Show Web Inspector; si no tienes un menú Desarrollo, habilítalo desde Menu > Safari > Preferences > Advanced > Show Develop menu en la barra de menú), ve al panel Network, carga (o actualiza) la página y selecciona Export en la parte superior derecha (a la derecha de Preserve Log).

Panel de red del Inspector web de Safari con la opción de exportación HAR destacada.

Para obtener más detalles, también puedes registrar lo que se transmite a terceros (en la sección Solicitud), aunque estos datos suelen estar ofuscados y no se pueden interpretar de manera útil.

Prácticas recomendadas para integrar terceros

Puedes establecer tus propias políticas sobre qué terceros usa tu sitio: cambiar qué proveedor de anuncios usas según sus prácticas, qué tan molesta o invasiva es su ventana emergente de consentimiento de cookies, o si deseas usar botones de redes sociales en tu sitio o vínculos de seguimiento en tus correos electrónicos o vínculos de utm_campaign para hacer un seguimiento en Google Analytics en tus tweets. Un aspecto que debes tener en cuenta cuando desarrollas un sitio es la postura de privacidad y seguridad de tu servicio de estadísticas. Algunos servicios de estadísticas comercian explícitamente por proteger la privacidad. Con frecuencia, también hay formas de usar una secuencia de comandos de terceros que agrega protección de la privacidad en sí misma: no eres el primer equipo que busca mejorar la privacidad de sus usuarios y protegerlos de la recopilación de datos de terceros, y es posible que ya existan soluciones. Por último, muchos proveedores externos son más sensibles que en el pasado a los problemas de recopilación de datos y, a menudo, hay funciones o parámetros que puedes agregar que habilitan un modo más protector para el usuario. Aquí tiene algunos ejemplos.

Cuando agregas un botón para compartir en redes sociales

Te recomendamos incorporar botones HTML directamente. El sitio https://sharingbuttons.io/ tiene algunos ejemplos bien diseñados. O bien, puedes agregar vínculos HTML sin formato. La desventaja aquí es que perderás la estadística de "recuento de uso compartido" y tu capacidad de clasificar a tus clientes en las estadísticas de Facebook. Este es un ejemplo de la compensación entre usar un proveedor externo y recibir menos datos de estadísticas.

En términos más generales, cuando incorporas un widget interactivo de algún tipo de un tercero, a menudo se puede proporcionar un vínculo a ese tercero. Esto significa que tu sitio no tiene la experiencia intercalada, sino que cambia la decisión de compartir datos con el tercero a tu usuario, quien puede elegir interactuar o no como prefiera.

Por ejemplo, puedes agregar vínculos para Twitter y Facebook para compartir tu servicio en misitio.example.com de la siguiente manera:

<a href="https://facebook.com/sharer/sharer.php?u=https%3A%2F%2Fmysite.example.com"
   rel="noopener" aria-label="Share on Facebook" target="_blank" >Share on Facebook</a>
<a href="https://twitter.com/intent/tweet/?text=My%20cool%20service!&amp;url=https%3A%2F%2Fmysite.example.com"
   rel="noopener" aria-label="Share on Twitter" target="_blank">Share on Twitter</a>

Ten en cuenta que Facebook permite especificar una URL para compartir, y Twitter permite especificar una URL y algo de texto.

Cuando insertas un video

Cuando incorpores videos de sitios que alojan videos, busca opciones que preserven la privacidad en el código de incorporación. Por ejemplo, para YouTube, reemplaza youtube.com en la URL incorporada por www.youtube-nocookie.com a fin de evitar que se realice un seguimiento de cookies en los usuarios que ven la página de incorporación. También puedes marcar la opción "Enable privacy-Enhanced mode" cuando generes el vínculo para compartir o incorporar desde YouTube. Este es un buen ejemplo de cómo usar un modo de protección más para el usuario proporcionado por el tercero. (en https://support.google.com/youtube/answer/171780 se describe esto con más detalle y otras opciones de incorporación específicas para YouTube).

Otros sitios de videos tienen menos opciones en este sentido: TikTok, por ejemplo, no tiene una forma de incorporar videos sin seguimiento en el momento de la redacción de este documento. Puedes alojar los videos por tu cuenta (con una alternativa), pero puede llevar mucho más trabajo, en especial, admitir muchos dispositivos.

Al igual que con los widgets interactivos que mencionamos anteriormente, a menudo es posible reemplazar un video incrustado con un enlace al sitio web que los provee. Esto es menos interactivo porque el video no se reproducirá intercalado, pero permite que el usuario decida si lo mirará o no. Se puede usar como un ejemplo del "patrón de fachada", el nombre para reemplazar dinámicamente contenido interactivo por algo que requiera una acción del usuario para activarlo. Un video incorporado de TikTok se puede reemplazar por un vínculo simple a la página del video, pero con un poco más de trabajo es posible recuperar y mostrar una miniatura para el video y convertirla en un vínculo. Incluso si el proveedor de video elegido no admite una manera fácil de incorporar videos sin seguimiento, muchos hosts de video admiten oEmbed, una API que, cuando se le proporciona un vínculo a un video o contenido incorporado, muestra los detalles programáticos, incluidos una miniatura y un título. TikTok admite oEmbed (consulta https://developers.tiktok.com/doc/embed-videos para obtener más información), lo que significa que puedes (de forma manual o programática) convertir un vínculo a un video de TikTok https://www.tiktok.com/@scout2015/video/6718335390845095173 en metadatos JSON sobre ese video con https://www.tiktok.com/oembed?url=https://www.tiktok.com/@scout2015/video/6718335390845095173 y, por lo tanto, recuperar una miniatura para mostrar. A menudo, WordPress usa este método para solicitar información de oEmbed para el contenido incorporado. Puedes usar esta opción de manera programática para mostrar una “fachada” que se ve interactiva y que cambie a incorporar un video interactivo o vincularlo a él cuando el usuario haga clic en él.

Cuando incorporas secuencias de comandos de estadísticas

Analytics está diseñado para recopilar información sobre tus usuarios de modo que pueda analizarse y para qué sirve. En esencia, los sistemas de estadísticas son servicios destinados a recopilar y mostrar datos sobre los accesos y los usuarios, lo que se realiza en un servidor de terceros, como Google Analytics, para facilitar la implementación. También hay sistemas de estadísticas autoalojados, como https://matomo.org/, aunque esto implica más trabajo que usar una solución de terceros para esto. Sin embargo, ejecutar este sistema en tu propia infraestructura te ayuda a reducir la recopilación de datos, ya que no abandona tu propio ecosistema. Por otro lado, administrar esos datos, quitarlos y establecer políticas en función de ellos se convierte en tu responsabilidad. Gran parte de la preocupación por el seguimiento entre sitios surge cuando se hace de forma clandestina y secreta, o como un efecto secundario del uso de un servicio que no necesita recopilar datos en absoluto. El software de estadísticas está diseñado abiertamente para recopilar datos y, así, informar a los propietarios del sitio sobre sus usuarios.

Históricamente, ha habido un enfoque para recopilar todos los datos posibles sobre todo, como una red de pesca gigante, y luego analizarlos más tarde en busca de patrones interesantes. Esta mentalidad, en gran parte, generó una sensación de incomodidad y inquietud por la recopilación de datos, que se analizó en la parte 1 de este curso. Ahora, muchos sitios primero deciden qué preguntas hacer y, luego, recopilan datos específicos y limitados para responder esas preguntas.

Si tu sitio y otros sitios usan algún servicio de terceros, y este incluye el código JavaScript en tu sitio y establece cookies para cada usuario, es importante considerar que es posible que esté realizando un reconocimiento entre sitios no deseado, es decir, mediante un seguimiento de los usuarios en los sitios. Algunos pueden y otros no, pero la postura que protege la privacidad aquí es suponer que ese servicio de terceros de hecho está realizando un seguimiento entre sitios, a menos que tengas un buen motivo para pensar o saber lo contrario. Esto no es en sí un motivo para evitar esos servicios, pero es algo que debes tener en cuenta en tu evaluación de las compensaciones de usarlos.

El equilibrio en el análisis solía ser solo para elegir si usarlo o no: recopilar todos los datos y comprometer la privacidad a cambio de estadísticas y planificación, o renunciar a las estadísticas por completo. Sin embargo, este ya no es el caso, y a menudo se encuentra un punto medio entre estos dos extremos. Consulta a tu proveedor de estadísticas para conocer las opciones de configuración a fin de limitar los datos recopilados y reducir la cantidad y duración de su almacenamiento. Dado que tienes los registros de la auditoría técnica que se describió antes, puedes volver a ejecutar las secciones relevantes de esa auditoría para confirmar que el cambio de estos parámetros de configuración reduce en realidad la cantidad de datos recopilados. Si realizas esta transición en un sitio existente, es posible que obtengas alguna medida cuantificable sobre la que es posible escribir para los usuarios. Por ejemplo, Google Analytics tiene varias funciones de privacidad que pueden habilitarse (por lo tanto, están desactivadas de forma predeterminada), muchas de las cuales pueden ser útiles para cumplir con las leyes locales de protección de datos. Algunas opciones que debes tener en cuenta cuando configuras Google Analytics incluyen establecer un período de retención de los datos recopilados (Administrador > Información de seguimiento > Retención de datos) en un valor inferior al predeterminado de 26 meses y habilitar algunas de las soluciones más técnicas, como la anonimización parcial de la IP (consulta https://support.google.com/analytics/answer/9019185 para obtener más detalles).

Utilización de terceros de una manera que preserva la privacidad

Hasta ahora, discutimos cómo proteger a tus usuarios de terceros durante la fase de diseño de tu aplicación, mientras planificas lo que hará esa aplicación. La decisión de no usar un tercero en particular es parte de esta planificación, y la auditoría de tus usos también entra en esta categoría: se trata de tomar decisiones sobre tu posición de privacidad. Sin embargo, estas decisiones no son muy detalladas de forma inherente; elegir recurrir a un tercero en particular o elegir no hacerlo no es una decisión con matices. Es mucho más probable que quieras algo intermedio: necesitar o planificar usar una oferta de terceros en particular, pero mitigar las tendencias que incumplan la privacidad (ya sean deliberadas o accidentales). Esta es la tarea de proteger a los usuarios en el "tiempo de compilación": agregar protecciones para reducir los daños que no preveías. Todos estos son encabezados HTTP nuevos que puedes proporcionar cuando entregas páginas y que sugieren o piden al usuario-agente que tome ciertas posturas de privacidad o seguridad.

Política de referente

Sí

Establece una política de strict-origin-when-cross-origin o noreferrer para evitar que otros sitios reciban un encabezado de referencia cuando te vincules a ellos o cuando una página los cargue como subrecursos:

index.html:
<meta name="referrer" content="strict-origin-when-cross-origin" />

O del servidor, por ejemplo en Exprés:

const helmet = require('helmet');
app.use(helmet.referrerPolicy({policy: 'strict-origin-when-cross-origin'}));

Si es necesario, establece una política más laxa para elementos o solicitudes específicos.

Por qué esto protege la privacidad del usuario

De forma predeterminada, cada solicitud HTTP que realiza el navegador pasa un encabezado Referer que contiene la URL de la página que inicia la solicitud, ya sea un vínculo, una imagen incorporada o una secuencia de comandos. Esto puede ser un problema de privacidad porque las URLs pueden contener información privada y las URLs disponibles para terceros les pasan esa información privada. Web.dev enumera algunos ejemplos de URLs que contienen datos privados (saber que un usuario llegó a tu sitio desde https://social.example.com/user/me@example.com te indica quién es, lo que es una filtración indudable). Pero incluso una URL que no expone información privada expone que ese usuario en particular (a quien quizás conozcas, si accedió a su cuenta) vino aquí desde otro sitio y, por lo tanto, revela que ese usuario visitó ese otro sitio. Se trata de una exposición de información que quizás no deberías conocer sobre el historial de navegación de tu usuario.

Proporcionar un encabezado Referrer-Policy (con la ortografía correcta) te permite modificar esto para que se pase parte de la URL de referencia o ninguna. MDN enumera todos los detalles, pero la mayoría de los navegadores ahora adoptaron un valor supuesto de strict-origin-when-cross-origin de forma predeterminada, lo que significa que la URL de referencia ahora se pasa solo a terceros como origen (https://web.dev en lugar de https://web.dev/learn/privacy). Esta es una protección de la privacidad útil sin que tengas que hacer nada. Sin embargo, puedes reforzar esto aún más si especificas Referrer-Policy: same-origin a fin de evitar pasar información de referencia a terceros (o Referrer-Policy: no-referrer para evitar pasar a alguien, incluido tu propio origen). (Este es un buen ejemplo de equilibrio entre la privacidad y la utilidad; la configuración predeterminada nueva preserva mucho más la privacidad que antes, pero aún proporciona información de alto nivel a los terceros que elijas, como tu proveedor de estadísticas).

También es útil especificar explícitamente este encabezado porque luego sabrás exactamente cuál es la política, en lugar de depender de los valores predeterminados del navegador. Si no puedes configurar encabezados, puedes establecer una política de URL de referencia para toda una página HTML con un metaelemento en <head>: <meta name="referrer" content="same-origin">. Si te preocupan terceros específicos, también puedes establecer un atributo referrerpolicy en elementos individuales, como <script>, <a> o <iframe>: <script src="https://thirdparty.example.com/data.js" referrerpolicy="no-referrer">.

Política de seguridad del contenido

El encabezado Content-Security-Policy, a menudo denominado “CSP”, determina desde dónde se pueden cargar los recursos externos. Se usa principalmente con fines de seguridad, ya que evita ataques de secuencias de comandos entre sitios y la inyección de secuencias de comandos, pero cuando se usa junto con tus auditorías habituales, también puede limitar el destino al que pueden pasar los datos los terceros elegidos.

Esta experiencia del usuario podría no ser tan buena: si una de tus secuencias de comandos de terceros comienza a cargar una dependencia de un origen que no está en tu lista, esa solicitud se bloqueará, la secuencia de comandos fallará y tu aplicación podría fallar (o, al menos, se reducirá a su versión alternativa con fallas de JavaScript). Esto es útil cuando la CSP se implementa por motivos de seguridad, que es su propósito normal: brindar protección contra problemas de secuencias de comandos entre sitios (y, para hacerlo, usar una CSP estricta). Cuando conozcas todas las secuencias de comandos intercaladas que usa tu página, puedes crear una lista de ellas, calcular un valor de hash o agregar un valor aleatorio (llamado “nonce”) a cada una y, luego, agregar la lista de hash a tu Política de Seguridad del Contenido. Esto evitará que se cargue cualquier secuencia de comandos que no esté en la lista. Esto debe integrarse en el proceso de producción del sitio: las secuencias de comandos de tus páginas deben incluir el nonce o tener un hash calculado como parte de la compilación. Consulta el artículo sobre strict-csp para conocer todos los detalles.

Afortunadamente, los navegadores admiten un encabezado relacionado, Content-Security-Policy-Report-Only. Si se proporciona este encabezado, no se bloquearán las solicitudes que infrinjan la política proporcionada, pero se enviará un informe JSON a la URL proporcionada. Este encabezado podría verse así: Content-Security-Policy-Report-Only: script-src 3p.example.com; report-uri https://example.com/report/, y si el navegador carga una secuencia de comandos desde cualquier lugar que no sea 3p.example.com, esa solicitud se realizará correctamente, pero se enviará un informe al report-uri proporcionado. Por lo general, esto se usa para experimentar con una política antes de implementarla, pero una idea útil es usarlo como una forma de realizar una "auditoría continua". Además de la auditoría normal descrita anteriormente, puedes activar los informes de CSP para ver si aparecen dominios inesperados, lo que podría significar que los recursos de terceros cargan recursos de terceros propios y que debes considerar y evaluar. (También puede ser un indicio de vulnerabilidades de secuencias de comandos entre sitios que superaron tu límite de seguridad, por supuesto, que también es importante conocer).

Content-Security-Policy es una API compleja y compleja. Esto es conocido, y aún se está trabajando para compilar la "próxima generación" de CSP, que cumplirá con los mismos objetivos, pero no será tan complicado de usar.Aún no está listo, pero si deseas saber adónde se dirige (o quieres participar y ayudar en su diseño), visita https://github.com/WICG/csp-next para obtener más detalles.

Sí

Agrega este encabezado HTTP a las páginas entregadas: Content-Security-Policy-Report-Only: default-src 'self'; report-uri https://a-url-you-control. Cuando se publique JSON en esa URL, almacénalo. Revisa esos datos almacenados para obtener una colección de los dominios de terceros que solicita tu sitio web cuando los visitan otras personas. Actualiza el encabezado Content-Security-Policy-Report-Only para enumerar los dominios que esperas y ver cuándo cambia la lista:

Content-Security-Policy-Report-Only: default-src 'self' https://expected1.example.com https://expected2.example.com ; report-uri https://a-url-you-control

Por qué

Esto forma parte de la auditoría técnica de manera continua. La auditoría técnica inicial que realices te proporcionará una lista de terceros a los que tu sitio comparte o transfiere datos de los usuarios. Este encabezado hará que las solicitudes de página informen qué terceros se están contactando, y podrás hacer un seguimiento de los cambios a lo largo del tiempo. Esto no solo te alerta sobre los cambios realizados por los terceros existentes, sino que también marca los terceros agregados recientemente que no se agregaron a la auditoría técnica. Es importante actualizar el encabezado para dejar de informar sobre los dominios que esperas, pero también repetir la auditoría técnica manual de vez en cuando (porque el enfoque Content-Security-Policy no marca qué datos se pasan, solo que se realizó una solicitud).

Ten en cuenta que no es necesario agregarla a las páginas publicadas siempre ni a todas las páginas. Ajusta cuántas respuestas de la página reciben el encabezado para obtener una muestra representativa de informes que no sean abrumadores en cantidad.

Política de permisos

El encabezado Permissions-Policy (que se introdujo con el nombre Feature-Policy) es similar en concepto a Content-Security-Policy, pero restringe el acceso a funciones potentes del navegador. Por ejemplo, es posible restringir el uso de hardware del dispositivo, como el acelerómetro, la cámara o los dispositivos USB, o restringir funciones que no son de hardware, como el permiso para activar la pantalla completa o usar XMLHTTPRequest síncrono. Estas restricciones se pueden aplicar a una página de nivel superior (para evitar que las secuencias de comandos cargadas intenten usar estas funciones) o a páginas con submarcos cargadas mediante un iframe. Esta restricción del uso de la API no se trata de la huella digital del navegador, sino de impedir que terceros realicen acciones invasivas (como usar APIs potentes, abrir ventanas de permisos emergentes, etcétera). En el modelo de amenazas a la privacidad de los objetivos, esto se define como “intrusión”.

Un encabezado Permissions-Policy se especifica como una lista de pares de elementos (atributos, orígenes permitidos), por lo tanto:

Permissions-Policy: geolocation=(self "https://example.com"), camera=(), fullscreen=*

En este ejemplo, se permite que esta página ("self") y <iframe> del origen example.com usen las APIs de navigator.geolocation desde JavaScript. Permite que esta página y todos los submarcos usen la API de pantalla completa y prohíbe que cualquier página, incluida esta, use una cámara para leer información de video. Hay muchos más detalles y una lista de posibles ejemplos aquí.

La lista de funciones que controla el encabezado Permissions-Policy es amplia y puede cambiar. Actualmente, la lista se mantiene en https://github.com/w3c/webappsec-permissions-policy/blob/main/features.md.

Sí

De forma predeterminada, los navegadores compatibles con Permissions-Policy inhabilitan las funciones potentes en los submarcos, por lo que debes habilitarlas. Este enfoque es privado de forma predeterminada. Si consideras que los submarcos de tu sitio requieren estos permisos, puedes agregarlos de manera selectiva. Sin embargo, no se aplica una política de permisos a la página principal de forma predeterminada, por lo que las secuencias de comandos (incluidas las de terceros) que carga la página principal no tienen restringido el uso de estas funciones. Por este motivo, es útil aplicar un Permissions-Policy restrictivo a todas las páginas de forma predeterminada y, luego, volver a agregar gradualmente las funciones que requieren tus páginas.

Algunos ejemplos de funciones potentes a las que afecta Permissions-Policy incluyen la solicitud de la ubicación del usuario, el acceso a sensores (incluidos el acelerómetro, el giroscopio y el magnetómetro), el permiso para activar la pantalla completa y la solicitud de acceso a la cámara y el micrófono del usuario. La lista completa (en cambio) de funciones se encuentra en el vínculo anterior.

Lamentablemente, para bloquear todas las funciones de forma predeterminada y volver a permitirlas de forma selectiva, es necesario enumerar todas las funciones en el encabezado, lo que puede parecer poco elegante. No obstante, un encabezado Permissions-Policy como este es un buen punto de partida. permissionspolicy.com/ tiene un generador en el que se puede hacer clic de manera conveniente para crear este encabezado: usarlo para crear un encabezado que inhabilita todas las funciones da como resultado lo siguiente:

Permissions-Policy: accelerometer=(), ambient-light-sensor=(), autoplay=(), battery=(), camera=(), cross-origin-isolated=(),
display-capture=(), document-domain=(), encrypted-media=(), execution-while-not-rendered=(), execution-while-out-of-viewport=(),
fullscreen=(), geolocation=(), gyroscope=(), keyboard-map=(), magnetometer=(), microphone=(), midi=(), navigation-override=(),
payment=(), picture-in-picture=(), publickey-credentials-get=(), screen-wake-lock=(), sync-xhr=(), usb=(), web-share=(), xr-spatial-tracking=()

Comprende las funciones de privacidad integradas en los navegadores web

Además de las protecciones de "tiempo de compilación" y "tiempo de diseño", también existen protecciones de la privacidad que ocurren en el "tiempo de ejecución", es decir, funciones de privacidad que se implementan en los navegadores para proteger a los usuarios. No son funciones que puedas controlar directamente o aprovechar como desarrollador de sitios (son funciones de productos), pero son funciones que debes conocer, ya que tus sitios pueden verse afectados por estas decisiones de productos en los navegadores. A modo de ejemplo, en este caso, la forma en que estas protecciones del navegador podrían afectar tu sitio

Incluyen la Prevención de seguimiento inteligente en Safari (y el motor subyacente WebKit) y la Protección contra el rastreo mejorada en Firefox (y su motor, Gecko). Todos estos elementos dificultan que los terceros puedan crear perfiles detallados de tus usuarios.

Los enfoques de los navegadores sobre las funciones de privacidad cambian con frecuencia, por lo que es importante mantenerse actualizado. La siguiente lista de protecciones es correcta al momento de redactar este artículo. Los navegadores también pueden implementar otras protecciones, pero estas listas no son exhaustivas. Consulta el módulo sobre prácticas recomendadas para conocer las formas de mantenerte al día con los cambios aquí y asegúrate de realizar pruebas con las próximas versiones del navegador para detectar los cambios que podrían afectar tus proyectos. Ten en cuenta que, en ocasiones, los modos de navegación privada o incógnito implementan una configuración diferente de la predeterminada del navegador (por ejemplo, las cookies de terceros pueden bloquearse de forma predeterminada en esos modos). Por lo tanto, es posible que las pruebas en el modo Incógnito no siempre reflejen la experiencia de navegación típica de la mayoría de los usuarios si no usan la navegación privada. También ten en cuenta que, si bloqueas las cookies en varias situaciones, es posible que también se bloqueen otras soluciones de almacenamiento, como window.localStorage, no solo las cookies.

Chrome

  • Las cookies de terceros se bloquearán en el futuro. En el momento en que se escribe este documento, no están bloqueados de forma predeterminada (pero un usuario puede habilitarlo): https://support.google.com/chrome/answer/95647 explica los detalles.
  • Las funciones de privacidad de Chrome y, en particular, las funciones de Chrome que se comunican con Google y servicios de terceros se describen en privacysandbox.com/.

Conexión de integración

  • Las cookies de terceros no se bloquean de forma predeterminada (pero un usuario puede habilitar esta opción).
  • La función Prevención de seguimiento de Edge bloquea los seguimientos de sitios no visitados, y las herramientas de seguimiento dañinas conocidas se bloquean de forma predeterminada.

Firefox

Para obtener algunas estadísticas sobre lo que puede estar bloqueado y ayudar a depurar problemas, haz clic en el ícono de escudo en la barra de direcciones o visita about:protections en Firefox (desde una computadora de escritorio).

Safari

  • Las cookies de terceros se bloquean de forma predeterminada.
  • Como parte de su función de Prevención de rastreo inteligente, Safari reduce la URL de referencia que se envía a otras páginas para que sean un sitio de nivel superior, en lugar de una página específica: (https://something.example.com en lugar de https://something.example.com/this/specific/page).
  • Los datos de localStorage del navegador se borran después de siete días.

(en https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/, se resumen estas funciones).

Para obtener información sobre lo que se puede bloquear y depurar problemas, habilita el "Modo de depuración de Prevención de seguimiento inteligente" en el menú para desarrolladores de Safari (en computadoras de escritorio). (Consulta https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/ para obtener más información).

Propuestas de API

¿Por qué necesitamos APIs nuevas?

Si bien las nuevas funciones y políticas que preservan la privacidad en los productos de navegador ayudan a preservar la privacidad del usuario, también conllevan desafíos. Muchas tecnologías web se pueden usar para el seguimiento entre sitios, a pesar de que están diseñadas y utilizadas para otros fines. Por ejemplo, muchos sistemas de federación de identidades que usamos todos los días dependen de cookies de terceros. Hay muchas soluciones publicitarias en las que los editores confían hoy en día para obtener ingresos y se basan en cookies de terceros. Muchas soluciones de detección de fraudes dependen de la creación de huellas digitales. ¿Qué sucede con estos casos de uso cuando desaparecen las cookies de terceros y la creación de huellas digitales?

Sería difícil y propenso a errores para los navegadores diferenciar los casos de uso y distinguir de manera confiable los usos que incumplen la privacidad de los demás. Esta es la razón por la que la mayoría de los principales navegadores bloquearon las cookies de terceros y la creación de huellas digitales, o tienen la intención de hacerlo, para proteger la privacidad del usuario.

Se necesita un nuevo enfoque: a medida que se eliminan gradualmente las cookies de terceros y se mitiga la creación de huellas digitales, los desarrolladores necesitan APIs diseñadas para propósitos específicos que cumplan con los casos de uso (que no han desaparecido), pero que estén diseñadas de una manera que preserve la privacidad. El objetivo es diseñar y compilar APIs que no pueden usarse para el seguimiento entre sitios. A diferencia de las funciones del navegador descritas en la sección anterior, estas tecnologías aspiran a convertirse en APIs entre navegadores.

Ejemplos de propuestas de API

La siguiente lista no es exhaustiva, sino algo de lo que se está conversando.

Ejemplos de propuestas de APIs para reemplazar tecnologías basadas en cookies de terceros:

Ejemplos de propuestas de API para reemplazar tecnologías basadas en el seguimiento pasivo:

Ejemplos de otras propuestas sobre las que se pueden basar otras APIs en un futuro sin cookies de terceros:

Además, está surgiendo otro tipo de propuesta de API para probar mitigaciones de seguimiento encubiertas específicas del navegador hasta ahora. Un ejemplo es el Presupuesto de privacidad. En todos estos casos de uso, las APIs que propuso Chrome inicialmente se encuentran bajo el término general de Privacy Sandbox.

Global-Privacy-Control es un encabezado que tiene como objetivo comunicar a un sitio que el usuario no desea compartir con otros sitios los datos personales recopilados. Su intención es similar a la de Do Not Track, que ya no está disponible.

Estado de las propuestas de la API

La mayoría de estas propuestas de APIs aún no se han implementado, o se implementan solo detrás de marcas o en entornos limitados para la experimentación.

Esta fase de incubación pública es importante: los proveedores de navegadores y los desarrolladores recopilan comentarios y experiencias sobre si estas APIs son útiles y si realmente hacen para qué se diseñaron. Los desarrolladores, los proveedores de navegadores y otros actores del ecosistema usan esta fase para iterar el diseño de la API.

El mejor lugar para mantenerse al tanto de las nuevas APIs que se proponen es actualmente la lista de propuestas del grupo de privacidad en GitHub.

¿Necesitas usar estas APIs?

Si tu producto se basa directamente en cookies o técnicas de terceros, como la creación de huellas digitales, debes participar en estas APIs nuevas, experimentar con ellas y aportar tus propias experiencias a los debates y el diseño de las APIs. En todos los demás casos, no necesariamente necesitas conocer todos los detalles de estas nuevas APIs al momento de escribir, pero es bueno estar al tanto de las próximas novedades.