[OUTDATED] Conjuntos propios y el atributo SameParty

Muchas organizaciones tienen sitios relacionados con diferentes nombres de dominio, como brandx.site y fly-brandx.site, o dominios para diferentes países, como example.com, example.rs, example.co.uk, etcétera.

Los navegadores están dejar de usar cookies de terceros para mejorar la privacidad en la Web. Sin embargo, los sitios como estos, a menudo, dependen de cookies para funcionalidades que requieren el mantenimiento y acceso al estado en los dominios (como el inicio de sesión único y la administración del consentimiento).

Los conjuntos propios pueden permitir que los nombres de dominio relacionados que pertenecen a una misma entidad y están bajo su administración se traten como propios en situaciones en las que los nombres de origen y de terceros se tratan de manera diferente. Los nombres de dominio dentro de un conjunto propio se consideran del mismo y pueden etiquetar qué cookies están destinadas a establecerse o enviarse en el contexto del mismo. El objetivo es encontrar un equilibrio entre evitar el seguimiento entre sitios por parte de terceros y, al mismo tiempo, mantener una ruta que no rompa los casos de uso válidos.

Actualmente, la propuesta de conjuntos propios se encuentra en la fase de prueba. Continúa leyendo para descubrir cómo funciona y cómo puedes probarla.

¿Cuál es la diferencia entre las cookies propias y las de terceros?

Las cookies no son inherentemente propias ni de terceros, y dependen del contexto actual en el que se incluyan. Eso se hace en una solicitud en el encabezado cookie o a través de document.cookie en JavaScript.

Por ejemplo, si video.site tiene una cookie theme=dark, cuando estás navegando en video.site y se hace una solicitud a video.site, es un contexto del mismo sitio y la cookie incluida es propia.

Sin embargo, si estás en my-blog.site, que incorpora un reproductor de iframe para video.site, cuando la solicitud se realiza de my-blog.site a video.site, es un contexto entre sitios y la cookie theme es de terceros.

Diagrama que muestra una cookie de video.site en dos contextos. La cookie es el mismo sitio cuando el contexto de nivel superior también es video.site. La cookie se utiliza en varios sitios cuando el contexto de nivel superior es my-blog.site con video.site en un iframe.

La inclusión de cookies se determina mediante el atributo SameSite de estas:

  • El contexto del mismo sitio con SameSite=Lax, Strict o None hace que la cookie sea propia.
  • El contexto de varios sitios con SameSite=None convierte a la cookie en de terceros.

Sin embargo, esto no siempre es tan claro. Imagina que brandx.site es un sitio para reservar viajes y también usa fly-brandx.site y drive-brandx.site para separar los vuelos y el alquiler de vehículos. Durante el transcurso de la reserva de un recorrido, los visitantes pasan de un sitio a otro para seleccionar sus diferentes opciones y esperan que las selecciones de su "carrito de compras" persistan en todos ellos. brandx.site administra la sesión del usuario con una cookie SameSite=None para permitirla en contextos de varios sitios. Sin embargo, la desventaja es que ahora la cookie no tiene protección contra la falsificación de solicitudes entre sitios (CSRF). Si evil.site incluye una solicitud a brandx.site, entonces incluiría esa cookie.

La cookie es de varios sitios, pero la misma organización es propiedad y está bajo su control de todos esos sitios. Los visitantes también entienden que se trata de la misma organización y que quieren la misma sesión, es decir, una identidad compartida entre todos.

Diagrama que muestra cómo una cookie aún podría incluirse en un contexto de varios sitios si estos forman parte del mismo conjunto propio, pero que se rechazaría para contextos de varios sitios fuera del conjunto.

Política de Conjuntos propios

First-Party Sets propone un método para definir explícitamente esta relación en varios sitios administrados por una misma parte y de su propiedad. Esto permitiría que brandx.site defina su relación de origen con fly-brandx.site, drive-brandx.site, etcétera.

El modelo de privacidad que impulsa las distintas propuestas de Privacy Sandbox se basa en el concepto de particionar la identidad para evitar el seguimiento entre sitios, es decir, dibuja un límite entre sitios que limita el acceso a cualquier información que se puede usar para identificar a los usuarios.

Diagrama que muestra el estado no particionado en el que se puede acceder a la misma cookie de terceros en varios contextos de varios sitios, en contraste con un modelo particionado en el que cada contexto de nivel superior tiene una instancia independiente de la cookie entre sitios que impide la actividad de vinculación en esos sitios.

Si bien la opción predeterminada es particionar por sitio, lo que resuelve muchos casos de uso propios, en el ejemplo de brandx.site, se muestra que un origen puede ser más grande que un solo sitio.

Diagrama que muestra cómo la misma instancia de una cookie para un conjunto puede incluirse en contextos de varios sitios cuando todos esos sitios forman parte del mismo conjunto.

Una parte importante de la propuesta de Conjuntos propios es garantizar que la política en todos los navegadores evite el abuso o el uso inadecuado. Por ejemplo, los Conjuntos propios no deben permitir el intercambio de información del usuario entre sitios no relacionados ni la agrupación de sitios que no pertenezcan a la misma entidad. La idea es garantizar que un conjunto propio se asigne a algo que una persona entienda como un conjunto propio y no se use como una forma de compartir identidad entre diferentes partes.

Una posible forma de que un sitio registre un conjunto propio podría ser enviar el grupo de dominios propuestos a una herramienta de seguimiento pública (como un repositorio dedicado de GitHub) junto con la información necesaria para cumplir con la política del navegador.

Una vez que se haya verificado la aserción del conjunto propio de acuerdo con la política, los navegadores podrán recuperar listas de conjuntos a través de un proceso de actualización.

La prueba de origen tiene una política definida que no es definitiva, pero es probable que los principios sigan siendo los mismos:

  • Los dominios de un conjunto propio deben ser propiedad de y operar de la misma organización.
  • Los dominios deben ser reconocibles para los usuarios como un grupo.
  • Los dominios deben compartir una política de privacidad común.

Cómo definir un conjunto propio

Una vez que identifiques a los miembros y al propietario del conjunto de origen de tu organización, un paso fundamental será enviar el conjunto propuesto para su aprobación. El proceso exacto todavía está en debate.

Para declarar un conjunto propio, los recursos JSON estáticos que enumeran los miembros y propietarios deben estar alojados en /.well-known/first-party-set en el nivel superior de cada dominio incluido.

En el ejemplo del conjunto propio brandx, el dominio del propietario aloja lo siguiente en https://brandx.site/.well-known/first-party-set:

{
  "owner": "brandx.site",
  "version": 1,
  "members": ["fly-brandx.site", "drive-brandx.site"]
}

Cada miembro del conjunto también aloja un recurso JSON estático que apunta al propietario del conjunto. En https://fly-brandx.site/.well-known/first-party-set tenemos:

{ "owner": "brandx.site" }

Y en https://drive-brandx.site/.well-known/first-party-set:

{ "owner": "brandx.site" }

Existen algunas restricciones para los conjuntos propios:

  • Un conjunto solo puede tener un propietario.
  • Un miembro solo puede pertenecer a un conjunto, sin superposición ni mezcla.
  • El propósito de la lista de miembros es que sea relativamente legible por humanos y no sea demasiado grande.

¿Cómo afectan los Conjuntos propios a las cookies?

El ingrediente coincidente de las galletas es el atributo SameParty propuesto. Cuando especificas SameParty, se le indica al navegador que incluya la cookie cuando su contexto forma parte del mismo conjunto propio que el contexto de nivel superior.

Esto significa que, si brandx.site establece esta cookie, sucederá lo siguiente:

Set-Cookie: session=123; Secure; SameSite=Lax; SameParty

Luego, cuando el visitante esté en fly-brandx.site y una solicitud vaya a brandx.site, la cookie session se incluirá en esa solicitud. Si otro sitio que no forma parte del conjunto propio, como hotel.xyz, envía una solicitud a brandx.site, no se incluirá la cookie.

Diagrama en el que se muestra la cookie brandx.site permitida o bloqueada en contextos de varios sitios, como se describe.

Hasta que SameParty sea ampliamente compatible, usa el atributo SameSite junto con él para definir el comportamiento de resguardo de las cookies. Considera que el atributo SameParty te proporciona una configuración entre SameSite=Lax y SameSite=None.

  • SameSite=Lax; SameParty expandirá la funcionalidad de Lax para incluir contextos del mismo tercero cuando se admitan, pero recurrirá a las restricciones de Lax si no es así.
  • SameSite=None; SameParty restringirá la funcionalidad None solo a contextos del mismo tercero cuando se admitan, pero recurrirá a los permisos None más amplios si no es así.

Existen algunos requisitos adicionales:

  • Las cookies SameParty deben incluir Secure.
  • Las cookies SameParty no deben incluir SameSite=Strict.

Se requiere Secure, ya que sigue siendo entre sitios, y debes mitigar esos riesgos garantizando conexiones seguras (HTTPS). Del mismo modo, debido a que esta es una relación entre sitios, SameSite=Strict no es válido, ya que aún permite la protección de CSRF basada en el sitio de manera estricta dentro de un conjunto.

¿Qué casos de uso son adecuados para los conjuntos propios?

Los conjuntos propios son una buena opción para los casos en los que una organización necesita una forma de identidad compartida en diferentes sitios de nivel superior. La identidad compartida en este caso significa cualquier cosa, desde una solución de inicio de sesión único completa a la necesidad de una preferencia compartida entre los sitios.

Es posible que tu organización tenga diferentes dominios de nivel superior para lo siguiente:

  • Dominios de aplicación: office.com,live.com, microsoft.com
  • Dominios de marca: amazon.com, audible.com / disney.com, pixar.com
  • Dominios específicos de país para habilitar la localización: google.co.in, google.co.uk
  • Dominios de servicio con los que los usuarios nunca interactúan directamente, pero que proporcionan servicios en los sitios de la misma organización: gstatic.com, githubassets.com, fbcdn.net
  • Dominios de la zona de pruebas con los que los usuarios nunca interactúan directamente, pero que existen por motivos de seguridad: googleusercontent.com, githubusercontent.com

¿Cómo se involucran?

Si tienes un conjunto de sitios que coinciden con los criterios anteriores, existen varias opciones para participar. La inversión más simple es leer y unir el debate sobre las dos propuestas:

Durante la fase de prueba, puedes probar la funcionalidad con la marca de línea de comandos --use-first-party-set y con una lista de sitios separados por comas.

Puedes probarlo en el sitio de demostración en https://fps-member1.glitch.me/ después de iniciar Chrome con la siguiente marca:

--use-first-party-set=https://fps-member1.glitch.me,https://fps-member2.glitch.me,https://fps-member3.glitch.me

Esto es útil si quieres realizar pruebas en tu entorno de desarrollo o agregar el atributo SameParty en un entorno real para ver cómo un conjunto propio afectaría las cookies.

Si tienes el ancho de banda suficiente para la experimentación y los comentarios, también puedes registrarte en la prueba de origen para conjuntos propios y SameParty, que está disponible en Chrome desde las versiones 89 a 93.

Cómo actualizar las cookies para la prueba de origen

Si te unes a la prueba de origen y pruebas el atributo SameParty en tus cookies, aquí hay dos patrones que debes considerar.

Opción 1

En primer lugar, cuando tienes cookies que etiquetaste como SameSite=None, pero deseas restringirlas a contextos propios, puedes agregarles el atributo SameParty. En los navegadores en los que la prueba de origen está activa, la cookie no se enviará en contextos de varios sitios fuera del conjunto.

Sin embargo, para la mayoría de los navegadores fuera de la prueba de origen, la cookie se seguirá enviando entre sitios como de costumbre. Considera esto como un enfoque de mejora progresiva.

Antes: set-cookie: cname=cval; SameSite=None; Secure

Después: set-cookie: cname=cval; SameSite=None; Secure; SameParty

Opción 2

La segunda opción implica más trabajo, pero te permite separar por completo la prueba de origen de la funcionalidad existente y, en particular, permite probar la combinación SameSite=Lax; SameParty.

Antes: set-cookie: cname=cval; SameSite=None; Secure

Después:

set-cookie: cname=cval; SameSite=None; Secure
set-cookie: cname-fps=cval; SameSite=Lax; Secure; SameParty

Cuando verificas la cookie en las solicitudes entrantes, solo deberías esperar ver la cookie cname-fps en una solicitud entre sitios si los sitios involucrados están en el conjunto y el navegador está en la prueba de origen. Considera este enfoque como un lanzamiento simultáneo de una función actualizada antes de desactivar la versión anterior.

¿Por qué es posible que no necesites un conjunto propio?

En la mayoría de los sitios, el límite de estos es un lugar aceptable para trazar la partición o el límite de privacidad. Esta es la ruta que se propone con CHIPS (Cookies con estado particionado independiente), que daría a los sitios una ruta de habilitación a través del atributo Partitioned para seguir teniendo esas incorporaciones, recursos, APIs y servicios críticos entre sitios, y evitar la filtración de información de identificación en los sitios.

Estos son otros aspectos que debes tener en cuenta para considerar que tu sitio podría funcionar sin la necesidad de configurarlo:

  • Alojas en diferentes orígenes, no en sitios diferentes. En el ejemplo anterior, si brandx.site tenía fly.brandx.site y drive.brandx.site, esos son subdominios diferentes dentro del mismo sitio. Las cookies pueden usar SameSite=Lax y no es necesario establecerla.
  • Tú proporcionas incorporaciones de terceros a otros sitios. En la introducción, el ejemplo de un video de video.site incorporado en my-blog.site es una clara división de terceros. Diferentes organizaciones administran los sitios, y los usuarios los ven como entidades separadas. Esos dos sitios no deben estar juntos en un conjunto.
  • Proporciona servicios de acceso a redes sociales de terceros. Los proveedores de identidades que usan elementos como OAuth o OpenId Connect suelen depender de cookies de terceros para ofrecer una experiencia de acceso más fluida a los usuarios. Es un caso de uso válido, pero no es adecuado para conjuntos propios, ya que hay una clara diferencia entre las organizaciones. Las primeras propuestas, como WebID, están explorando formas de habilitar estos casos de uso.