¿Qué es un tercero?
Es bastante raro que un sitio web sea completamente independiente. El HTTP Web Almanac muestra que la mayoría de los sitios web (alrededor del 95%) incluyen contenido de terceros.
El Almanaque define el contenido de terceros como algo alojado en un origen compartido y público, que es muy utilizado por una variedad de sitios y no influenciados por un propietario individual del sitio. Pueden ser imágenes u otro 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 que se suma. El contenido de terceros no es esencial para desarrollar un sitio pero también podría ser; lo más probable es que uses algo cargado desde un servidor compartido público, ya sean fuentes web, iframes incorporados de videos, anuncios o bibliotecas de JavaScript. Por ejemplo, puedes usar fuentes web de Google Fonts, o mediciones de análisis con Google Analytics; es posible que hayas agregado botones de Me gusta o de Acceder con de redes sociales; Es posible que incorpores mapas o videos, o que administres compras a través de servicios de terceros. es posible que estés haciendo un seguimiento de los errores y registros para tus equipos de desarrollo a través de herramientas de supervisión de terceros.
Por motivos de privacidad, es útil considerar una definición ligeramente diferente y menos amplia: un recurso de terceros, y en en particular, una secuencia de comandos de terceros, se entrega desde un origen compartido y público, y se usa ampliamente como ilustrado, pero también es de autor por alguien que no sea el propietario del sitio. El aspecto de la autoría de terceros es clave cuando consideras cómo proteger de los usuarios la privacidad de los demás. Esto te llevará a considerar qué riesgos están presentes y luego decidir cómo o si utilizar una recurso de terceros en función de esos riesgos. Como ya lo mencioné, estas cosas te ayudarán a comprender el contexto y por lo tanto, para entender qué concesiones debes hacer y qué significan.
No es exactamente lo que se quiere decir cuando se habla de "recursos de terceros" en general: la distinción entre datos de origen y o terceros tiene que ver con el contexto en el que se usa algo. Una secuencia de comandos que se carga desde otro sitio web es de terceros recurso, y la solicitud HTTP que carga la secuencia de comandos puede incluir cookies que, en realidad, no son "cookies de terceros"; solo son cookies, y si son "de terceros" o "de origen" depende de si la secuencia de comandos se carga en una de tu sitio o 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 expuestas a los usuarios o funciones para desarrolladores, como el seguimiento de errores, pero reducen la carga de desarrollo, y las secuencias de comandos se mantienen por alguien más: el equipo de desarrollo del servicio que está incluyendo. Todo esto funciona debido a la componibilidad de la Web: poder juntar partes para formar un todo mayor que su suma.
El Almanac web del archivo HTTP proporciona una buena descripción:
Los terceros proporcionan un conjunto interminable de imágenes, videos, fuentes, herramientas, bibliotecas, widgets, herramientas de seguimiento, anuncios y todo lo que se pueda incorporar a nuestras páginas web. Esto permite incluso los menos técnicos para poder crear y publicar contenido en la Web. Sin terceros, es probable que la Web ser un medio académico aburrido, basado en textos, en lugar de una plataforma rica, inmersiva y compleja que es esencial en la vida de muchos de nosotros en la actualidad.
¿Qué pueden hacer los recursos de terceros?
Acceder a cierta información
Cuando usas un recurso de terceros en tu sitio web, independientemente de lo que sea, cierta información se pasa a ese tercero. Por ejemplo, si incluyes una imagen de otro sitio, la solicitud HTTP que realice el navegador del usuario pasará por una URL 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 del tercero, puede incluir una cookie que Se devolverá al tercero cuando el usuario solicite la imagen. Esto significa que el tercero puede saber que su se usa en tu sitio y esta puede devolver una cookie, posiblemente con un ID único para ese usuario. Esto significa que la próxima vez que el usuario visite su sitio o cualquier otro sitio que incluya un recurso de ese tercero, su sitio Se volverá a enviar la cookie de ID. Esto permite al tercero crear un registro de los lugares que visita ese usuario: tu sitio, otros sitios que usan el mismo recurso de terceros en toda la Web.
Este es el seguimiento entre sitios: permitir que un tercero recopile un registro de la actividad de un usuario en muchos sitios web, siempre y cuando todos los sitios web utilizan un recurso del mismo tercero. Puede ser una fuente, una imagen o una hoja de estilo; todos son recursos estáticos. También puede ser un recurso dinámico: un guion, un botón de redes sociales o un anuncio. La secuencia de comandos incluida puede recopilar aún más porque es dinámica: puede inspeccionar el navegador y el entorno del usuario, y pasar esos datos de vuelta al originador. Cualquier secuencia de comandos puede hacer esto hasta cierto punto, al igual que los recursos dinámicos que no están presentes como una secuencia de comandos, como una incorporación en redes sociales o un anuncio o un botón para compartir. Si observas los detalles de un banner de cookies en sitios web populares, puedes ver una lista de las organizaciones. que pueden agregar una cookie de seguimiento a sus usuarios para crear una imagen de sus actividades y crear un perfil de ese usuario. Hay pueden ser cientos de ellos. Si un tercero ofrece un servicio de forma gratuita, una de las formas en que puede ser económicamente viable porque recopilan y monetizan los datos.
El Modelo de amenazas de privacidad objetivo es una guía útil sobre los tipos de problemas de privacidad contra los que un navegador debe proteger a sus usuarios. Este documento aún está en debate en el momento de su redacción, pero ofrece algunas clasificaciones de alto nivel de los tipos de amenazas de privacidad existentes. Los riesgos de recursos de terceros son principalmente "reconocimiento no deseado entre sitios", donde un un sitio web puede identificar al mismo usuario en varios sitios, y la "divulgación de información confidencial", donde un sitio puede recopilar información que un usuario considera sensible.
Esta es una distinción clave: el reconocimiento no deseado entre sitios es malo incluso si el tercero no recopila datos sensibles información extraída de ella, ya que les quita el control al usuario sobre su identidad. Cómo obtener acceso a la URL de referencia y a la dirección IP de un usuario y las cookies es una divulgación no deseada en sí misma. El uso de recursos de terceros viene con un componente de planificación de cómo los utilizarás de una manera que preserve la privacidad. Parte de ese trabajo es responsabilidad tuya como desarrollador del sitio y otra parte lo realiza el navegador en su rol 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 cuando sea posible. A continuación, veremos en más detalle las mitigaciones y los enfoques en un navegador. y el de desarrollo del sitio.
Código de terceros del servidor
Nuestra definición anterior de un tercero alteró deliberadamente el enfoque del Almanac HTTP en lugar del enfoque del cliente (según corresponda). para su informe), para incluir la autoría de terceros porque, desde una perspectiva de privacidad, un tercero es cualquiera que sabe algo. sobre los usuarios que no son tú.
Esto incluye a terceros que proporcionan servicios que usas en el servidor, así como al cliente. Desde una desde el punto de vista de una biblioteca de terceros (como algo incluido en NPM, Composer o NuGet) también es importante entenderlo. ¿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 incluyen también "teléfono celular" para los autores, es posible que infrinjan las políticas privacidad y, por lo tanto, deben auditarse. Por lo general, hay que entregarle los datos del usuario a un tercero basado en el servidor, que los datos a los que está expuesto estén más bajo tu control. En cambio, un tercero basado en el cliente (una secuencia de comandos o un recurso HTTP) se incluyen en tu sitio web y son recuperadas por el navegador del usuario) pueden recopilar algunos datos directamente del usuario sin ese proceso. que sea mediado por ti. La mayor parte de este módulo se centrará en cómo identificar a los terceros del cliente. ha elegido incluir y exponer a sus usuarios, precisamente porque hay menos mediación posible. Pero vale la pena considera proteger tu código del servidor para que comprendas las comunicaciones salientes de este y puedas registrar o bloquear son inesperados. Los detalles sobre cómo hacer esto exactamente están fuera de nuestro alcance aquí (y dependen mucho de la configuración de tu servidor), pero esta es otra parte de su postura relacionada con la seguridad y la privacidad.
¿Por qué hay que ser cuidadoso con los terceros?
Las secuencias de comandos y funciones de terceros son muy importantes, y nuestro objetivo como desarrolladores web debería ser integrar estas funciones, de no alejarse de ellos. Pero hay problemas potenciales. El contenido de terceros puede causar problemas de rendimiento problemas de seguridad porque permite ingresar un servicio externo dentro de su límite de confianza. Sin embargo, los tu contenido también puede generar problemas de privacidad.
Cuando hablamos de recursos externos en la Web, es útil pensar en los problemas de seguridad (entre otras cosas) en los que un tercero puede robar datos de su empresa y para contrastarlos con los problemas de privacidad, que son (entre otras cosas) cuando un tercero que usted incluyó roba u obtiene acceso a los datos de sus usuarios datos sin que usted (o ellos) otorguen su consentimiento.
Un ejemplo de un problema de seguridad es cuando los "skimmers web" 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 datos de la tarjeta de crédito, es posible que se los robe y los envíe el tercero malicioso. Quienes crean estos guiones skimmer son muy creativos al buscar lugares donde ocultarlos. Un resumen describe cómo los scripts de skimmer Se ocultaron en contenido de terceros, como las imágenes que se usan para logotipos de sitios, í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 su oferta. para mantener las capacidades de tus usuarios confía en ti, debes estar seguro de que los usuarios pueden confiar en ellos. Si un tercero que usas recopila datos sobre a tus usuarios y luego lo utiliza de forma inadecuada, dificulta la eliminación o el descubrimiento, sufre una violación de la seguridad de los datos o infringe la expectativas, es probable que los usuarios perciban que es un desglose de la confianza de tu servicio y no solo del tercero. Es tu reputación y tu relación en línea. Por eso, es importante que te preguntes: ¿Confías en los terceros que utiliza en su sitio?
¿Cuáles son algunos ejemplos de terceros?
Estamos hablando de "terceros" en general, pero existen tipos diferentes
y tienen acceso a distintas cantidades de datos del usuario.
Por ejemplo, si agregas un elemento <img>
a tu código HTML, cargado desde otro servidor, se le proporcionará información distinta a ese servidor.
sobre tus usuarios que agregar un <iframe>
o un elemento <script>
. Estos son ejemplos más que una lista completa, pero
es útil para comprender las distinciones entre los diferentes tipos de elementos de terceros que puede utilizar su sitio.
Solicita 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>
. Ejemplos
incluyen <img>
, <audio>
, <video>
, fuentes web cargadas por CSS y texturas WebGL. Todos se cargan a través de una solicitud HTTP y como
como se describió anteriormente, esas solicitudes HTTP incluirán cualquier cookie que haya establecido el otro sitio, la dirección IP del usuario solicitante
y la URL de la página actual como URL de referencia. Históricamente, todas las solicitudes de terceros incluían estos datos de forma predeterminada, aunque
se realizan esfuerzos por reducir o aislar los datos que varios navegadores transmiten a terceros, tal como se describe en la sección "Comprensión
Protecciones de terceros para navegadores" más adelante.
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 del trifecta
de cookies, dirección IP y URL de referencia. Las APIs que están disponibles para <iframe>
d páginas y la forma en que solicitan acceso es específica del navegador
y se están realizando cambios actualmente: consulta "Política de Permisos" a continuación sobre las iniciativas actuales para restringir o supervisar el acceso a las APIs en
documentos.
Cómo ejecutar JavaScript entre sitios
Incluir un elemento <script>
carga y ejecuta JavaScript entre sitios en el contexto de nivel superior de tu página. Esto significa que el
de comandos que se ejecute tiene acceso completo
a todas las acciones de sus 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 la aceptación del usuario. Pero cualquier información presente en la página o
disponibles, ya que esas secuencias de comandos pueden leer variables de JavaScript, lo que incluye no solo las cookies que se pasan al tercero
como parte de la solicitud, pero también las cookies destinadas únicamente a su sitio. De igual forma, se cargará una secuencia de comandos de terceros en tu
puede hacer las mismas solicitudes HTTP que tu propio código, lo que significa que podría hacer solicitudes fetch()
a tus APIs de backend para obtener datos.
Cómo incluir bibliotecas de terceros en tus dependencias
Como se describió anteriormente, es probable que tu código del servidor incluya dependencias de terceros, que no pueden distinguirse de las tuyas. el código en su poder; código que incluyes desde un repositorio de GitHub o de tu biblioteca de lenguaje de programación (npm, PyPI, composer, etcétera) puede leer los mismos datos que tu otro código.
Cómo conocer a sus terceros
Esto, por lo tanto, requiere algunos conocimientos de su lista de proveedores externos y de cuáles son sus controles de privacidad, recopilación de datos y y cómo son las posturas y las políticas de la experiencia. Esa comprensión forma parte de una serie de compensaciones: qué tan útiles e importantes son es el servicio, equilibrado con respecto a cuán invasivo, molesto o inquietante son sus exigencias para los usuarios. Terceros El contenido aporta valor, ya que toma el trabajo pesado de ti como propietario del sitio y te permite enfocarte en tus competencias principales. Por eso, es valioso hacer ese intercambio y sacrificar la comodidad y la privacidad del usuario por una mejor experiencia del usuario. Sin embargo, es importante no confundir la experiencia del usuario con la del desarrollador: "a nuestro equipo de desarrollo le resulta más fácil compilar el servicio" no es una historia convincente para los usuarios.
La forma de 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 tanto técnica como no técnicamente, y para un tercero individual y para toda tu colección.
Ejecuta 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, revisa las políticas de privacidad. Son extensas y están llenas de texto legal, y es posible que algunos documentos usen algunos de estos enfoques advertencias específicas en módulos anteriores, como declaraciones excesivamente generales y sin indicaciones 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 de los datos recopilados en tu sitio, incluidos los de terceros, se regirán por estas políticas de privacidad. Incluso si todo correctamente, cuando eres transparente sobre tus objetivos y superas las expectativas de las expectativas de la privacidad de los datos y los usuarios pueden responsabilizarlo de cualquier tarea que realicen los terceros seleccionados. Si hay algo en las políticas de privacidad, lo que no desearía mencionar en sus propias políticas, ya que reduciría la cantidad de confianza, entonces considerar si hay un proveedor alternativo.
Esto es algo que útilmente puede ir de la mano con la auditoría técnica que se analiza más adelante, ya que informan con el otro. Debes conocer los recursos de terceros que incorporas por motivos comerciales (como las redes de publicidad). o contenido incorporado) porque se establecerá una relación comercial. Este es un buen punto de partida auditoría de Cloud. Es probable que la auditoría técnica también identifique a terceros, en especial a aquellos incluidos en actividades técnicas que por motivos empresariales (componentes externos, análisis, bibliotecas de utilidades), y esa lista puede combinarse con la lista de terceros enfocados en la empresa. En este caso, el objetivo es que, como propietario del sitio, las partes que agregas a tu sitio, y para ti, como empresa, poder presentar a tu asesor legal con este inventario de terceros para asegurarse de que cumple con las obligaciones requeridas.
Ejecuta 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 y, luego, inspeccionarlo de esa manera. Asegúrate de ver cómo las dependencias actúan como parte de tu sitio web real. implementadas en la Internet pública, en lugar de hacerlo en modo de prueba o desarrollo. Es muy útil ver tu propio sitio web como un usuario nuevo. Abre el navegador con 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 a este nuevo usuario
de adquisición de clientes nuevos desde una perspectiva de UX, pero puede ser ilustrativo abordarlo desde una perspectiva de privacidad. No te limites a hacer clic
"Aceptar" en los términos y condiciones, la advertencia de cookies o la política de privacidad; establece la tarea de usar tu propio servicio
sin divulgar información personal ni tener cookies de seguimiento, y ve si puedes hacerlo y cuán difícil es hacerlo.
También puede ser útil consultar las herramientas para desarrolladores del navegador para ver a qué sitios se accede y qué datos se pasan
esos sitios. Las herramientas para desarrolladores proporcionan una lista de solicitudes HTTP independientes (generalmente 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 nueva columna para mostrar el dominio de cada solicitud, que indicará cuántos lugares diferentes se contactan
y es posible que haya “solicitudes de terceros” para mostrar solo los terceros. (También puede ser útil utilizar Content-Security-Policy
la elaboración de informes para realizar una auditoría continua, para lo cual se debe obtener más información).
La herramienta "Request Map Generator" de Simon Hearne también puede ser una descripción general útil de todos las subsolicitudes que realiza una página de acceso público.
Aquí también puedes incluir a los terceros centrados en la empresa 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). El objetivo aquí es para hacer coincidir la lista de terceros que cree que utiliza (de registros financieros y legales) y la lista que está realmente usando (observando las solicitudes HTTP de terceros que realiza tu sitio web). Deberías poder identificar para cada tercero de los negocios parte de la cual se realizan las solicitudes técnicas salientes. Si no puede identificar solicitudes en la auditoría técnica de un tercero identificados por la relación comercial, es importante averiguar por qué y contar con esa información que guíe sus pruebas. El recurso solo se carga en un país determinado, en un tipo de dispositivo determinado o para usuarios registrados. Esto ampliará la una lista de áreas del sitio que se deben auditar y asegurarse de que puede ver todos los accesos salientes. (O tal vez identifique a un tercero recurso que pagas y que no usas, lo que siempre alienta al departamento de finanzas).
Una vez que hayas reducido la lista de solicitudes a los terceros que te gustaría incluir en la auditoría, haz clic en un se mostrarán todos sus detalles y, en particular, qué datos se pasaron a esa solicitud. Además, es muy es común que una solicitud de terceros que inicia tu código y luego inicie muchas otras solicitudes de terceros. Estos terceros adicionales también se "importan". en tu propia política de privacidad. Esta tarea es compleja pero valiosa, y a menudo, puede insertarse en los análisis existentes; su equipo de desarrollo de frontend ya debería auditar las solicitudes por motivos de rendimiento (quizás con la ayuda de herramientas existentes como WebPageTest o Lighthouse) y la incorporación de un conjunto de datos la auditoría de privacidad y la auditoría de privacidad en ese proceso.
Qué debes hacer
Abrir un navegador con un nuevo perfil de usuario limpio, de modo que no accedas ni tengas acuerdos almacenados. luego, abre el navegador en el panel Network de las herramientas de desarrollo para ver todas las solicitudes salientes. Agrega una columna nueva para mostrar el dominio de cada solicitud y verifica el "solicitudes de terceros" para mostrar solo los terceros si están presentes. Luego:
- Visita tu sitio.
- Regístrate para obtener una cuenta nueva si proporcionas cuentas de usuario.
- Intenta borrar la cuenta que creaste.
- Realiza una o dos acciones normales en el sitio (exactamente esto dependerá de lo que haga tu sitio, pero elige acciones comunes que realice la mayoría de los usuarios).
- Realiza una o dos acciones que sepas que involucran dependencias de terceros en particular. Estas podrían incluir compartir contenido con redes sociales, iniciar un proceso de confirmación de la compra o incorporar contenido de otro sitio.
Cuando realices cada una de estas tareas, crea un registro de los recursos solicitados de dominios que no sean tuyos en el panel Red según se describe. Estos son algunos de tus terceros. Una buena forma de hacerlo es usar las herramientas de red del navegador para capturar la red de solicitudes en un archivo HAR.
archivos HAR y la captura
Un archivo Hadoop es un formato JSON estandarizado de todas las solicitudes de red que realiza una página. Para obtener un archivo HAR para 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 Red y carga (o actualiza) la página. En la esquina superior derecha, cerca del menú desplegable Sin limitación, selecciona el símbolo de guardado de la flecha hacia abajo.
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 regulación. En el menú, selecciona Save All As HAR**.
Safari
Abre las herramientas para desarrolladores del navegador (Menú > Desarrollo > Mostrar Inspector web; si no tienes un menú Desarrollo, habilítalo en Menú > Safari > Preferencias > Avanzado > Mostrar el menú Desarrollo en la barra de menú), ve al panel Red y carga (o actualiza) la página. Selecciona Exportar en la parte superior derecha (a la derecha de Conservar registro; es posible que debas agrandar la ventana).
Para obtener más detalles, también puedes registrar lo que se transmite a terceros (en la sección Solicitud), aunque estos datos suelen ser ofuscados y no se puedan interpretar de manera útil.
Prácticas recomendadas para la integración de terceros
Puede establecer sus propias políticas sobre los terceros que utiliza su sitio: cambiar el proveedor de anuncios que utiliza según sus prácticas, o cuán molesta o invasiva es la ventana emergente de consentimiento de las cookies, o si quieres usar botones de redes sociales en tu sitio o los vínculos de seguimiento en tus correos electrónicos o los vínculos utm_campaign para realizar un seguimiento en Google Analytics en tus tweets. Un aspecto a tener en cuenta cuando desarrollar un sitio es la postura de privacidad y seguridad de tu servicio de análisis. Algunos servicios de estadísticas comercian explícitamente resguardando la privacidad. A menudo, 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 seguridad su privacidad y protegerlos de la recopilación de datos de terceros, y quizás ya sean soluciones. Por último, muchos proveedores externos son más sensibles a los problemas relacionados con la recopilación de datos ahora que en el pasado. y, a menudo, se pueden agregar funciones o parámetros para brindar un modo de protección más alto al usuario. Aquí tienes algunos ejemplos.
Cuando agregues un botón para compartir en redes sociales
Considera incorporar botones HTML directamente: el sitio https://sharingbuttons.io/ tiene algunos ejemplos bien diseñados. O puedes agregar vínculos HTML sin formato. La desventaja es que pierdes el "recuento de acciones". y tu capacidad para clasificar a tus clientes en tus estadísticas de Facebook. Este es un ejemplo de compensación entre usar un proveedor externo y recibir menos datos estadísticos.
En términos más generales, cuando incorporas un widget interactivo de algún tipo de un tercero, a menudo es posible proporcionar un a un tercero. Esto significa que tu sitio no tiene la experiencia intercalada, pero cambia la decisión de compartirla datos con el tercero que hayas compartido a tu usuario, quien puede elegir interactuar o no según sus preferencias.
Por ejemplo, puedes agregar vínculos de 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!&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.
Al insertar un video
Cuando incorpores videos de sitios que los alojan, busca opciones que preserven la privacidad en el código de incorporación.
Por ejemplo, en el caso de YouTube, reemplaza youtube.com
en la URL incorporada por www.youtube-nocookie.com
para evitar las cookies de seguimiento.
colocarse sobre los usuarios
que ven la página de incorporación. También puedes marcar "Habilitar el modo de privacidad mejorada" cuando se genera el
Compartir/incorporar un vínculo desde YouTube Este es un buen ejemplo de cómo se usa un modo de protección contra el usuario proporcionado por un tercero.
(https://support.google.com/youtube/answer/171780 describe esto en 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 manera de incorporar videos sin realizar un seguimiento. al momento de la redacción de este documento. Puedes alojar los videos por tu cuenta (con una alternativa), pero también puede ser mucho más trabajo, especialmente para admitir muchos dispositivos.
Al igual que con los widgets interactivos analizados anteriormente, a menudo es posible reemplazar un video incrustado con un enlace al sitio web que los proporciona.
Este formato es menos interactivo porque el video no se reproduce de forma intercalada, pero deja la opción de mirarlo con el usuario. Puede ser
Se usa como ejemplo del "patrón de fachada", el nombre para reemplazar dinámicamente el contenido interactivo con algo que requiere un usuario.
acción para activarla. Un video de TikTok incorporado puede reemplazarse por un vínculo simple a la página del video de TikTok, pero con algo más.
es posible recuperar y mostrar una miniatura para el video y convertirlo en un vínculo. Incluso si el proveedor de video elegido
admiten una manera fácil de incorporar videos sin seguimiento, muchos hosts de videos admiten oEmbed, una API que, cuando se proporciona
un vínculo a un video o contenido incorporado, mostrará detalles programáticos del mismo, incluida 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 convertir (de forma manual o programática) 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. WordPress lo usa a menudo para solicitar oEmbed para el contenido incorporado, por ejemplo. Puedes usarlo de manera programática
para mostrar una "fachada" que se vea interactivo y cambie a incorporar un video interactivo o vincularlo a él cuando el usuario elige hacer clic en él.
Cuando incorpores secuencias de comandos de Analytics
Analytics está diseñado para recopilar información sobre tus usuarios de modo que se pueda analizar: para esto se usa. Los sistemas de analítica son, en esencia, servicios para recopilar y mostrar datos sobre accesos y usuarios, lo cual se realiza en un servidor de terceros, como Google Analytics, para facilitar el de la implementación. También existen sistemas analíticos autoalojados, como https://matomo.org/, aunque esto es más trabajo que usar un una solución de terceros para ello. Sin embargo, ejecutar un sistema de este tipo en tu propia infraestructura ayuda a reducir la recopilación de datos. porque no abandona tu propio ecosistema. Por otro lado, administrar esos datos, quitarlos y establecer políticas para ellos pasa a ser tu responsabilidad. Gran parte de la preocupación por el seguimiento entre sitios surge cuando se hace en forma clandestina y secretamente, o como un efecto secundario del uso de un servicio que no necesita contener la recopilación de datos en absoluto. El software de análisis es evidente diseñados para recopilar datos con el fin de informar a los propietarios del sitio acerca de sus usuarios.
Históricamente, se han recopilado todos los datos posibles sobre todo, como una red de pesca gigante y para luego analizarlos en busca de patrones interesantes. Esta mentalidad, en gran parte, creó una sensación de incomodidad y inquietud sobre la recopilación de datos, que se analizó en la parte 1 de este curso. Ahora, muchos sitios primero determinan qué preguntas hacer y y, luego, recopilar datos específicos y limitados para responder esas preguntas.
Si tu sitio y otros sitios usan algún servicio de terceros y, además, incluye el código JavaScript que usas en tu sitio y establece cookies para cada usuario, es importante considerar que podrían estar haciendo un reconocimiento no deseado entre sitios. es decir, el seguimiento de tus usuarios en los sitios. Algunos pueden y otros no, pero la postura que protege la privacidad es asumir que este servicio de terceros, en realidad, realiza un seguimiento entre sitios, a menos que tenga un buen motivo para pensar o saber lo contrario. Esto no es en sí un motivo para evitar esos servicios, pero sí es algo que debes considerar cuando evalúes las compensaciones. de usarlos.
En el análisis, el equilibrio solía ser solo decidir si se usaran o no: recopilar todos los datos y comprometer la privacidad a cambio. para obtener estadísticas y la planificación, o bien renunciar por completo a estadísticas. Sin embargo, ya no es así y ahora suele haber un punto medio entre estos dos extremos. Consulta a tu proveedor de servicios de analítica para conocer las opciones de configuración que existen para limitar los datos recopilados y reducen la cantidad y duración de su almacenamiento. Dado que tienes los registros de la auditoría técnica como se describió anteriormente, puedes volver a ejecutar las secciones relevantes de esa auditoría para confirmar que el cambio de estos parámetros de configuración realmente reducir la cantidad de datos recopilados. Si estás haciendo esta transición en un sitio existente, esto te puede dar alguna medida cuantificable sobre la que se pueda escribir para tus usuarios. Por ejemplo, Google Analytics tiene una serie de habilitaciones (por lo tanto, las inhabilitan de forma predeterminada). de privacidad, muchas de las cuales pueden ser útiles para cumplir con las leyes locales de protección de datos. Algunas opciones para tener en cuenta cuando configures Google Las estadísticas incluyen configurar el período de retención de los datos recopilados (Administrador > Información de seguimiento > Retención de datos) con un período inferior al predeterminado de 26 meses. y habilitar algunas de las soluciones más técnicas, como la anonimización parcial de IP (consulta https://support.google.com/analytics/answer/9019185 para obtener más detalles).
Uso de terceros de una manera que preserve la privacidad
Hasta ahora, hemos hablado de cómo proteger a tus usuarios de terceros durante la fase de diseño de tu aplicación, mientras estás planificando lo que hará esa aplicación. La decisión de no contratar a un tercero en particular es parte de esta planificación, y auditar tus usos también entra en esta categoría: se trata de tomar decisiones sobre tu postura de privacidad. Sin embargo, estos las decisiones son intrínsecamente poco detalladas; elegir utilizar un tercero en particular o no hacerlo no es una decisión con matices. Es mucho más probable que quiera usar algo intermedio: necesita o planea usar una oferta determinada de un tercero, pero mitigar cualquier tendencia que incumpla la privacidad (ya sea deliberada o accidental) Esta es la tarea de proteger a los usuarios en el “momento de la compilación”: agregar protecciones para reducir el daño que no anticipabas. Todos estos son encabezados HTTP nuevos que puedes proporcionar al publicar y cuáles le indicarán o le indicarán al usuario-agente que adopte ciertas posturas de privacidad o seguridad.
Política de referencia
Qué debes hacer
Establece una política de strict-origin-when-cross-origin
o noreferrer
para evitar que otros sitios reciban un encabezado de referencia
cuando se vinculan a ellos o cuando una página los carga como subrecursos:
index.html:
<meta name="referrer" content="strict-origin-when-cross-origin" />
O del servidor, por ejemplo en Express:
const helmet = require('helmet');
app.use(helmet.referrerPolicy({policy: 'strict-origin-when-cross-origin'}));
Si es necesario, establece una política más laxa en solicitudes o elementos específicos.
Por qué esto protege la privacidad del usuario
De forma predeterminada, cada solicitud HTTP que realiza el navegador pasa en 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 esas URLs
estar disponible para terceros les pasa esa información privada. Web.dev enumera algunos ejemplos
de las 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 ese usuario)
que es una fuga definitiva. Pero incluso una URL que no expone información privada sí expone que ese usuario en particular (que quizás conozcas,
(si accedió) vino aquí desde otro sitio y, por lo tanto, esto revela que el usuario visitó ese otro sitio. Esto es por sí mismo la exposición
sobre el historial de navegación del usuario.
Proporcionar un encabezado Referrer-Policy
(con la ortografía correcta) te permite modificar esto para que se pase una parte o ninguna de las URLs de referencia.
MDN muestra los detalles completos, pero la mayoría de los navegadores tienen
Ahora se adoptó un valor supuesto de strict-origin-when-cross-origin
de forma predeterminada, lo que significa que la URL de referencia ahora se pasa a terceros.
terceros solo como origen (https://web.dev
en lugar de https://web.dev/learn/privacy
). Esta es una protección de la privacidad útil sin
sin tener que hacer nada. Pero puedes ajustar esto aún más si especificas Referrer-Policy: same-origin
para evitar pasar cualquier
información de referencia a terceros (o Referrer-Policy: no-referrer
para evitar transmitirla a nadie, incluido tu propio origen).
(Este es un buen ejemplo del equilibrio entre privacidad y utilidad; el nuevo valor predeterminado preserva mucho más la privacidad que antes, pero
sigue proporcionando información de alto nivel a los terceros que elijas, como tu proveedor de servicios de analítica).
También es útil especificar explícitamente este encabezado porque, luego, sabrás exactamente de qué se trata la política, en lugar de depender de los valores predeterminados del navegador.
Si no puedes configurar los encabezados, es posible establecer una política de URL de referencia para toda una página HTML con un metaelemento en las <head>
:
<meta name="referrer" content="same-origin">
; y, si te preocupan terceros específicos, también es posible establecer un referrerpolicy
en elementos individuales, como <script>
, <a>
o <iframe>
: <script src="https://thirdparty.example.com/data.js" referrerpolicy="no-referrer">
Content-Security-Policy
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 e inyección de secuencias de comandos, pero cuando se usa
Además de sus auditorías habituales, también puede limitar a dónde pueden pasar datos los terceros que eligió.
Esto es potencialmente una experiencia del usuario poco satisfactoria. si una de tus secuencias de comandos de terceros comienza a cargar una dependencia desde un origen fuera de tu lista, se bloqueará la solicitud, la secuencia de comandos fallará y tu aplicación podría fallar (o al menos reducirse a su versión de resguardo con errores de JavaScript). Esto es útil cuando se implementa CSP por motivos de seguridad, cuyo propósito normal es proteger contra los problemas de secuencias de comandos entre sitios (para ello, debes usar una CSP estricta). Una vez que sepas todas las secuencias de comandos intercaladas que usa tu página, puedes hacer una lista de ellas, calcular un valor de hash o agregar un valor aleatorio (denominado “nonce”) para cada uno y, luego, agrega la lista de hashes a tu Política de Seguridad del Contenido. Esto evitará que 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 para incluir el nonce o calcular un hash como parte de la compilación. Consulta el artículo sobre strict-csp para obtener todos los detalles.
Por suerte, los navegadores admiten un encabezado relacionado: Content-Security-Policy-Report-Only
. Si se proporciona este encabezado, las solicitudes
que infrinjan la política indicada no se bloquearán, pero se enviará un informe JSON a esa URL. Ese 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 de cualquier lugar que no sea 3p.example.com
, esa solicitud se realizará correctamente, pero un informe
al report-uri
proporcionado. Normalmente, se usa para experimentar con una política antes de implementarla, pero es útil
idea es usarla como una forma de llevar a cabo una "auditoría continua". Además de la auditoría habitual descrita anteriormente,
Puedes activar los informes de CSP para ver si aparecen dominios inesperados, lo que podría significar que se están cargando tus recursos de terceros
recursos de terceros propios y que debes considerar y evaluar. (También puede ser una señal de algunos errores
vulnerabilidades de secuencias de comandos que traspasaron los límites de seguridad, por supuesto, algo que también es importante conocer).
Content-Security-Policy
es una API compleja y difícil de usar. Esto es conocido y todavía se está trabajando para construir la "próxima generación" de los CSP
que cumplirá con los mismos objetivos, pero no será tan complicado de usar.Aún no está listo, pero si quieres ver hacia dónde nos dirigimos
(o participar y ayudar con su diseño) y consulta https://github.com/WICG/csp-next para obtener más información.
Qué debes hacer
Agrega este encabezado HTTP a las páginas publicadas: 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 los datos almacenados para obtener una colección de dominios de terceros que solicita tu sitio web cuando lo visitan otras personas.
Actualiza el encabezado Content-Security-Policy-Report-Only
para enumerar los dominios que esperas y, así, 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 tu auditoría técnica de forma continua. La auditoría técnica inicial que realizaste
lista de terceros con los que el sitio comparte o pasa los datos del usuario. Este encabezado hará que las solicitudes de página se informen
con qué terceros se contactan y puedes hacer un seguimiento de los cambios a lo largo del tiempo. Esto no solo te alerta sobre los cambios
que hayan realizado los terceros existentes, pero también marcarán los terceros agregados recientemente que no se hayan agregado a la auditoría técnica.
Es importante actualizar el encabezado para dejar de informar sobre los dominios que esperas, pero también repetir el manual
auditoría técnica ocasionalmente (porque el enfoque Content-Security-Policy
no marca qué datos se pasan, solo
que se ha realizado una solicitud).
Ten en cuenta que no es necesario agregarlo a las páginas publicadas cada vez ni a cada página. Reducir la cantidad de respuestas de la página que se reciben el encabezado para obtener una muestra representativa de informes cuya cantidad no sea abrumadora.
Política de Permisos
El encabezado Permissions-Policy
(que se introdujo con el nombre Feature-Policy
) es similar en concepto al 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,
cámara o dispositivos USB, o restringir funciones que no son de hardware, como el permiso para ver el modo de 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 para
páginas submarcoadas cargadas a través de un iframe. Esta restricción del uso de la API no tiene que ver realmente con la huella digital del navegador. Se trata de impedir que terceros realicen acciones intrusivas (como usar APIs potentes, ventanas emergentes
ventanas de permisos, etc.). Esto se define en el Modelo de amenazas de privacidad objetivo como “intrusión”.
Se especifica un encabezado Permissions-Policy
como una lista de pares (atributo, orígenes permitidos), por lo siguiente:
Permissions-Policy: geolocation=(self "https://example.com"), camera=(), fullscreen=*
En este ejemplo, se permite que esta página ("self") y los <iframe>
del example.com
de origen 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 cualquier página, incluida esta página,
usar una cámara para leer información de video. Encontrarás más detalles y una lista de posibles ejemplos aquí.
La lista de funciones que controla el encabezado Permissions-Policy es extensa y puede variar. Actualmente, la lista es mantenido en https://github.com/w3c/webappsec-permissions-policy/blob/main/features.md.
Qué debes hacer
Los navegadores compatibles con Permissions-Policy
no permiten funciones potentes en los submarcos de forma predeterminada, y debes actuar para habilitarlas.
Este enfoque es privado de forma predeterminada. Si descubres que los submarcos de tu sitio requieren estos permisos, puedes agregarlos de manera selectiva.
Sin embargo, no existe una política de permisos aplicada a la página principal de forma predeterminada. Por lo tanto, las secuencias de comandos (incluidas las de terceros) que son
cargados por la página principal no tienen limitaciones en cuanto al uso de estas funciones. Por este motivo, es útil aplicar una restricción
Permissions-Policy
a todas las páginas de forma predeterminada y, luego, vuelve a agregar gradualmente las funciones que requieren tus páginas.
Algunos ejemplos de funciones potentes a las que afecta Permissions-Policy
incluyen solicitar la ubicación del usuario, acceder a sensores (como
acelerómetro, giroscopio y magnetómetro), permiso para acceder a pantalla completa y solicitar acceso a la cámara y el micrófono del usuario.
La lista completa (cambiante) de funciones está vinculada anteriormente.
Lamentablemente, para bloquear todas las funciones de forma predeterminada y volver a permitirlas de forma selectiva, es necesario enumerar todas las características en el encabezado.
lo que puede parecer poco elegante. No obstante, un encabezado Permissions-Policy
de este tipo es un buen punto de partida. permissionspolicy.com/
tiene un generador en el que se puede hacer clic convenientemente para crear un encabezado de este tipo: si se usa para crear un encabezado que inhabilita todas las funciones, se produce 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=()
Información sobre las funciones de privacidad integradas en los navegadores web
Además del “tiempo de compilación”, y "tiempo de diseño" medidas de protección, también existen protecciones de la privacidad que se aplican durante el "tiempo de ejecución", es decir, la privacidad funciones implementadas en los navegadores para proteger a los usuarios. Estas no son funciones que puedas controlar directamente ni aprovechar como sitio desarrollador, son funciones de productos, pero son funciones que debe tener en cuenta, ya que sus sitios pueden verse afectados por estas decisiones sobre los productos en navegadores. Si tienes un código JavaScript del cliente que espera, a modo de ejemplo, cómo estas protecciones del navegador pueden afectar tu sitio para que una dependencia de terceros se cargue antes de continuar con la configuración de la página y esa dependencia de terceros nunca se cargue, la configuración de la página por lo que el usuario ve una página a mitad de camino.
Incluyen la Prevención de rastreo inteligente en Safari. (y el motor WebKit subyacente) y la Protección contra seguimiento mejorada en Firefox (y su motor, Gecko). Todo esto dificulta que los terceros creen perfiles detallados de tus usuarios.
Los enfoques de los navegadores respecto a las funciones de privacidad cambian con frecuencia y es importante mantenerse actualizados. la siguiente lista de protecciones
sean correctos en el momento de la redacción. Los navegadores también pueden implementar otras protecciones. 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 probar las próximas versiones del navegador para detectar cambios que puedan afectar tus proyectos.
Ten en cuenta que, en ocasiones, los modos de navegación privada o de incógnito implementan una configuración distinta de la predeterminada del navegador (es posible que se bloqueen las cookies de terceros).
de forma predeterminada en esos modos, por ejemplo). Por lo tanto, es posible que las pruebas en el modo Incógnito no siempre reflejen la experiencia de navegación habitual de la mayoría de los usuarios si
no usan la navegación privada. Además, ten en cuenta que bloquear cookies en diversas situaciones puede provocar que otras soluciones de almacenamiento, como window.localStorage
,
se bloquean, no solo las cookies.
Chrome
- Se planea bloquear las cookies de terceros en el futuro. A partir de este momento, no están bloqueados de forma predeterminada. (pero un usuario puede habilitar esta opción): 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/.
Edge
- Las cookies de terceros no se bloquean de forma predeterminada (pero un usuario puede habilitarlas).
- Bloques de funciones de Prevención de seguimiento de Edge los dispositivos de rastreo de sitios no visitados y los dispositivos de rastreo dañinos conocidos se bloquean de forma predeterminada.
Firefox
- Las cookies de terceros no se bloquean de forma predeterminada (pero un usuario puede habilitarlas).
- La Protección contra seguimiento mejorada de Firefox bloquea las cookies de seguimiento de forma predeterminada. secuencias de comandos de huellas digitales, secuencias de criptomineros y rastreadores conocidos. (https://support.mozilla.org/kb/trackers-and-scripts-firefox-blocks-enhanced-track proporciona más detalles).
- Las cookies de terceros están limitadas por el sitio, por lo que cada sitio básicamente tiene un almacén de cookies independiente y no puede correlacionarse. (Mozilla lo llama "Protección total de cookies").
Para obtener información sobre lo que puede bloquearse 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 la función Prevención de seguimiento inteligente,
Safari reduce la URL de referencia que se pasa a otras páginas para que sea un sitio de nivel superior en lugar de una página específica: (
https://something.example.com
, en lugar dehttps://something.example.com/this/specific/page
). - Los datos del navegador
localStorage
se borran después de siete días.
(https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/ resume estas funciones).
Para obtener información sobre lo que podría bloquearse y ayudar a depurar problemas, habilita el "Modo de depuración de Intelligent Tracking Prevention" en la carpeta de destino de Safari en el menú del desarrollador (en computadoras de escritorio). Consulta https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/ para obtener más información.
Propuestas de la API
¿Por qué necesitamos APIs nuevas?
Si bien las nuevas funciones y políticas de los productos de navegadores que preservan la privacidad 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 estar 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. Diversas soluciones publicitarias que los editores que nuestros clientes utilizan para obtener ingresos actuales se basan en cookies de terceros. Muchas soluciones de detección de fraudes se basan en la creación de huellas digitales. Qué ¿qué sucede con estos casos de uso cuando las cookies de terceros y la creación de huellas digitales desaparecen?
Sería difícil y propenso a errores para los navegadores diferenciar los casos de uso y distinguir de forma confiable aquellos usos que infringen la privacidad de otras personas. Es por eso 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 a los usuarios. la privacidad.
Se necesita un nuevo enfoque: a medida que las cookies de terceros se eliminan y se mitiga la creación de huellas digitales, los desarrolladores necesitan APIs diseñadas para propósitos específicos. que satisfagan los casos de uso (que no desaparecieron), pero que se diseñaron de una manera que preserva la privacidad. El objetivo es diseñar y construir APIs que no se pueden usar 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, es una muestra de lo que se está debatiendo.
Ejemplos de propuestas de API para reemplazar las tecnologías compiladas en cookies de terceros:
- Casos de uso de identidad: FedCM
- Casos de uso de Google Ads: Medición de clics privados, atribución privada interoperable, Informes de atribución, Temas FLEDGE y PARAKEET.
Ejemplos de propuestas de API para reemplazar las tecnologías basadas en el seguimiento pasivo:
- Casos de uso de detección de fraudes: Trust Tokens.
Estos son algunos ejemplos de otras propuestas en las que pueden basarse otras APIs en el futuro sin cookies de terceros:
Además, está surgiendo otro tipo de propuesta de API para probar y tener mitigaciones de seguimiento encubiertas específicas de cada navegador. Un ejemplo es el Presupuesto de privacidad. En estos diversos de casos de uso, las APIs propuestas inicialmente por Chrome se encuentran bajo el término general de Privacy Sandbox.
Global-Privacy-Control es un encabezado que tiene como objetivo comunicar un sitio al usuario. deseas que los datos personales recopilados no se compartan con otros sitios. Su intención es similar a Do Not Track, que se descontinuó.
Estado de las propuestas de la API
La mayoría de estas propuestas de API aún no se implementan, o bien solo se implementan detrás de marcas o en entornos limitados para la experimentación.
Esta fase de incubación pública es importante: los proveedores y desarrolladores de navegadores recopilan el debate y la experiencia con respecto a si estas APIs útiles y si realmente hacen para lo que fueron diseñados. Los desarrolladores, proveedores de navegadores y otros agentes del ecosistema utilizan esta fase para iterar el diseño de la API.
El mejor lugar para mantenerse al tanto de las nuevas APIs que se proponen actualmente es la lista de propuestas del grupo de privacidad en GitHub.
¿Necesitas usar estas APIs?
Si tu producto se crea directamente sobre cookies de terceros o técnicas como la creación de huellas digitales, debes participar en estas nuevas APIs, experimentar con ellas y aportar tus propias experiencias a los debates y al diseño de la API. En todos los demás casos, no es necesario que conozcas todos los detalles sobre estas nuevas APIs al momento de escribir este documento, pero es bueno estar al tanto de lo que se avecina.