[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 se están moviendo hacia hacer obsoletas las cookies de terceros para mejorar la privacidad en la Web, pero los sitios como estos suelen depender de las cookies para las funciones que requieren mantener y acceder al estado en todos los dominios (como el acceso único y la administración de consentimiento).

Los conjuntos propios pueden permitir que los nombres de dominio relacionados que son propiedad de la misma entidad y que esta opera se traten como propios en situaciones en las que los propios y los de terceros se tratan de manera diferente. Los nombres de dominio dentro de un conjunto propio se consideran del mismo propietario y pueden etiquetar qué cookies se deben configurar o enviar en el contexto del mismo propietario. El objetivo es encontrar un equilibrio entre evitar que terceros realicen un seguimiento entre sitios y, al mismo tiempo, mantener una ruta que no interrumpa los casos de uso válidos.

Actualmente, la propuesta de conjuntos propios se encuentra en la fase de pruebas. Sigue 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 o de terceros, sino que depende del contexto actual en el que se incluye la cookie. Esto se puede hacer en una solicitud en el encabezado cookie o a través de document.cookie en JavaScript.

Si, por ejemplo, video.site tiene una cookie theme=dark, cuando navegas por video.site y se realiza una solicitud a video.site, se trata de un contexto de 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 se realiza la solicitud de my-blog.site a video.site, ese 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 del mismo sitio cuando el contexto de nivel superior también es video.site. La cookie es entre sitios cuando el contexto de nivel superior es my-blog.site con video.site en un iframe.

La inclusión de cookies se determina según el atributo SameSite de la cookie:

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

Sin embargo, esto no siempre es tan claro. Imagina que brandx.site es un sitio de reservas de viajes y que también usa fly-brandx.site y drive-brandx.site para separar vuelos y alquiler de automóviles. A lo largo de la reserva de un viaje, los visitantes alternan entre estos sitios para seleccionar sus diferentes opciones. Esperan que su "carrito de compras" de selecciones persista en todos estos sitios. brandx.site administra la sesión del usuario con una cookie SameSite=None para permitirla en contextos de varios sitios. Sin embargo, el inconveniente 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 entre sitios, pero la misma organización es propietaria y opera todos esos sitios. Los visitantes también entienden que se trata de la misma organización y quieren la misma sesión, en otras palabras, una identidad compartida en todos ellos.

Diagrama que muestra cómo una cookie aún se puede incluir en un contexto entre sitios si los sitios forman parte del mismo conjunto propio, pero que se rechazaría para los contextos entre sitios fuera del conjunto.

Política de First-Party Sets

Los conjuntos propios proponen un método para definir de forma explícita esta relación en varios sitios que son propiedad de la misma parte y están bajo su administración. Esto permitiría que brandx.site definiera su relación propia con fly-brandx.site, drive-brandx.site, etcétera.

El modelo de privacidad que impulsa las diversas propuestas de Privacy Sandbox se basa en el concepto de particionar la identidad para evitar el seguimiento entre sitios, lo que establece un límite entre los sitios que limita el acceso a cualquier información que se pueda 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 entre 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 evita la actividad de vinculación entre esos sitios.

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

Diagrama que muestra cómo la misma instancia de una cookie para un conjunto se puede incluir 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 de 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 pertenecen a la misma entidad. La idea es garantizar que un conjunto propio se asocie a algo que una persona entienda como propio y no se use como una forma de compartir la identidad entre diferentes partes.

Una forma posible en que un sitio puede registrar un conjunto propio es que envíe su grupo propuesto de dominios a un servicio de seguimiento público (como un repositorio de GitHub dedicado) junto con la información necesaria para satisfacer la política del navegador.

Una vez que se verifique la aserción del conjunto propio según la política, los navegadores pueden 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 permanezcan iguales:

  • La misma organización debe ser propietaria y operar los dominios de un conjunto propio.
  • Los usuarios deben poder reconocer los dominios 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 propio de tu organización, un paso fundamental será enviar el conjunto propuesto para su aprobación. El proceso exacto aún está en discusión.

Para declarar un conjunto propio, los recursos JSON estáticos que enumeran a los miembros y propietarios deben alojarse 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 lo siguiente:

{ "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 superposiciones ni combinaciones.
  • El objetivo de la lista de miembros es que sea relativamente legible y no demasiado grande.

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

El ingrediente coincidente para las cookies es el atributo SameParty propuesto. Especificar SameParty le indica al navegador que incluya la cookie cuando su contexto forme parte del mismo conjunto propio que el contexto de nivel superior.

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

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

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

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

Hasta que SameParty sea compatible con muchos dispositivos, usa el atributo SameSite junto con él para definir el comportamiento de resguardo de las cookies. Puedes pensar en el atributo SameParty como una configuración entre SameSite=Lax y SameSite=None.

  • SameSite=Lax; SameParty expandirá la funcionalidad de Lax para incluir contextos de la misma parte cuando sea compatible, pero recurrirá a las restricciones de Lax si no es así.
  • SameSite=None; SameParty restringirá la funcionalidad de None solo a los contextos de la misma parte cuando sea compatible, pero recurrirá a los permisos más amplios de None si no es así.

Existen algunos requisitos adicionales:

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

Secure es obligatorio, ya que aún se trata de un ataque entre sitios, y debes mitigar esos riesgos asegurando conexiones seguras (HTTPS). Del mismo modo, como se trata de una relación entre sitios, SameSite=Strict no es válida, ya que aún permite una protección contra CSRF basada en el sitio 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. En este caso, la identidad compartida puede ser desde una solución de inicio de sesión único completa hasta solo necesitar una preferencia compartida en todos los sitios.

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

  • Dominios de la app: office.com,live.com, microsoft.com
  • Dominios de marca: amazon.com, audible.com / disney.com, pixar.com
  • Dominios específicos del 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 y fbcdn.net
  • Dominios de 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 puedes participar?

Si tienes un conjunto de sitios que coinciden con los criterios anteriores, hay varias opciones para participar. La inversión más ligera es leer y unirse al 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 proporcionar una lista de sitios separados por comas.

Puedes probar esto 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 deseas realizar pruebas en tu entorno de desarrollo o si quieres intentar agregar el atributo SameParty en un entorno en vivo para ver cómo un conjunto propio afectaría a las cookies.

Si tienes el ancho de banda para la experimentación y los comentarios, también puedes registrarte en la prueba de origen para conjuntos propios y de terceros, que está disponible en Chrome desde la versión 89 a la 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, estos son dos patrones que debes tener en cuenta.

Opción 1

En primer lugar, si tienes cookies que etiquetaste como SameSite=None, pero quieres 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 entre 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 requiere más trabajo, pero te permite separar por completo la prueba de origen de la funcionalidad existente y, específicamente, permite probar la combinación de 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 busques la cookie en las solicitudes entrantes, solo deberías 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 rechazar la versión anterior.

¿Por qué no necesitas un conjunto propio?

Para la mayoría de los sitios, el límite del sitio es un lugar aceptable para dibujar la partición o el límite de privacidad. Esta es la ruta que se propone con CHIPS (cookies con estado particionado independiente), que les daría a los sitios una ruta de participación a través del atributo Partitioned para seguir teniendo esas incorporaciones, recursos, APIs y servicios críticos entre sitios, a la vez que se evita la filtración de información de identificación entre sitios.

Estos son otros aspectos que debes tener en cuenta y que podrían indicar que tu sitio está bien sin necesidad de un conjunto:

  • Los alojas en diferentes orígenes, no en diferentes sitios. En el ejemplo anterior, si brandx.site tuviera fly.brandx.site y drive.brandx.site, esos serían subdominios diferentes dentro del mismo sitio. Las cookies pueden usar SameSite=Lax y no es necesario establecer nada.
  • 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 operan los sitios, y los usuarios los ven como entidades independientes. Esos dos sitios no deben estar juntos en un conjunto.
  • Proporcionas servicios de acceso a redes sociales de terceros. Los proveedores de identidad que usan OAuth o OpenID Connect suelen depender de cookies de terceros para brindar una experiencia de acceso más fluida a los usuarios. Es un caso de uso válido, pero no es adecuado para los conjuntos propios, ya que hay una clara diferencia en las organizaciones. Las primeras propuestas, como WebID, exploran formas de habilitar estos casos de uso.