[OUTDATED] Conjuntos propios y el atributo SameParty

Muchas organizaciones tienen sitios relacionados con nombres de dominio diferentes, por ejemplo: 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 avanzando para crear cookies de terceros obsoleto para mejorar la privacidad en la Web, pero sitios como estos a menudo dependen de cookies para funcionalidades que requieren mantener el estado y acceder a él en varios dominios (como el inicio de sesión único y la administración del consentimiento).

Los Conjuntos propios pueden permitir nombres de dominio relacionados que sean propiedad y que estén administrados por la misma entidad se trate como propia en situaciones en las que tercero se tratan de otro modo. Los nombres de dominio dentro de de origen se consideran del mismo usuario y pueden etiquetar qué cookies se si se establecen o envían en un contexto de la misma parte. El objetivo es encontrar lograr un equilibrio entre la prevención del seguimiento entre sitios por parte de terceros mantener una ruta de acceso que no dañe los casos de uso válidos.

Actualmente, la propuesta de conjuntos propios se encuentra en prueba fase, siga leyendo para descubrir cómo funciona y cómo puedes probarlo.

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

Las cookies no son intrínsecamente propias ni de terceros, sino que dependen del contextual en el que se incluye la cookie. Ya sea 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 navegas video.site y se realiza una solicitud a video.site, ese es un mismo sitio el contexto y el cookie incluida es propio.

Sin embargo, si usas my-blog.site, que inserta un reproductor iframe para video.site, cuando la solicitud se realiza de my-blog.site a video.site es un contexto de varios 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 se usa 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 la cookie:

  • Mismo sitio contextual con SameSite=Lax, Strict o None hacen que la cookie sea propio.
  • 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 viaje sitio de reservas y también usan fly-brandx.site y drive-brandx.site para vuelos separados y alquiler de autos. En el transcurso de la reserva de un viaje, los visitantes van de estos sitios para seleccionar sus diferentes opciones; ellos esperan "carrito de compras" selecciones para conservar en estos sitios. brandx.site administra la sesión del usuario con una cookie SameSite=None para permitirla contextos entre sitios. Sin embargo, la desventaja es que ahora la cookie no tiene acceso Protección contra la falsificación de solicitudes (CSRF). Si evil.site incluye una solicitud para brandx.site, incluiría esa galleta.

La cookie se ejecuta en varios sitios, pero todos esos sitios son de propiedad y administración de los mismos organización. Los visitantes también entienden que se trata de la misma organización y quieren misma sesión, es decir, una identidad compartida entre todos.

Diagrama que muestra cómo se puede seguir incluyendo una cookie 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

Los conjuntos propios proponen un método para definir explícitamente 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 haga lo siguiente: define 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 basan en el concepto de partición de identidad para evitar el seguimiento entre sitios: limita el acceso a cualquier información que pueda usarse para identificar a los usuarios.

Diagrama en el que se 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 problemas casos de uso, en el ejemplo de brandx.site se muestra que un origen puede ser más grande de un solo sitio.

Diagrama que muestra cómo se puede incluir la misma instancia de una cookie para un conjunto 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 entre navegadores evita 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, o bien el agrupamiento de sitios que no son propiedad de la misma entidad. La idea es garantizar que un El Conjunto propio se asigna a algo que una persona entiende como un origen y es no se usan como una forma de compartir la identidad entre diferentes partes.

Una forma posible de que un sitio registre un conjunto propio podría ser a través del sitio enviar el grupo de dominios propuesto a un rastreador público (como un repositorio exclusivo de GitHub), junto con la información necesaria para cumplir con los requisitos del navegador .

Una vez que se verifica la aserción de conjunto propio según la política, los navegadores pueden y, luego, recuperan 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 los principios son probablemente permanezcan iguales:

  • Los dominios de un conjunto propio deben ser administrados y propiedad de la misma organización.
  • Los dominios deben ser reconocibles para los usuarios como 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 de la información de origen un paso crucial será enviar el conjunto propuesto para su aprobación. El nombre exacto proceso sigue en debate.

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

En el ejemplo del conjunto propio brandx, el dominio propietario aloja la siguiendo a 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, no se puede superponer ni mezclar.
  • La lista de miembros debe ser relativamente legible por humanos y no son demasiado grandes.

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

El ingrediente coincidente de las galletas es el SameParty propuesto. . Especifica SameParty le indica al navegador que incluya la cookie cuando su contexto es el mismo como 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 se envíe una solicitud a brandx.site y, luego, la cookie session se incluirá en esa solicitud. Si otro sitio que no forma parte del conjunto propio, por ejemplo hotel.xyz envía una solicitud a brandx.site; la cookie no se incluirá.

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

Hasta que se admita ampliamente SameParty, usa el atributo SameSite junto con él para y definir el comportamiento de resguardo de las cookies. Puedes pensar en el SameParty te permite establecer una configuración entre SameSite=Lax y SameSite=None

  • SameSite=Lax; SameParty expandirá la funcionalidad de Lax a se incluyen contextos de la misma parte cuando se admiten, pero recurre a Lax restricciones si no lo son.
  • SameSite=None; SameParty restringirá la funcionalidad de None a o solo contextos del mismo tipo cuando se admita, pero recurre a None.

Estos son algunos requisitos adicionales:

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

Se requiere Secure, ya que todavía es entre sitios y debe mitigarlos. a través de conexiones seguras (HTTPS). Del mismo modo, dado que este es un relación entre sitios, SameSite=Strict no es válido, ya que todavía permite una protección CSRF basada en sitios 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. Identidad compartida en este caso significa cualquier cosa, desde una solución de inicio de sesión único completa hasta la necesidad de una preferencia en los sitios.

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

  • Dominios de aplicaciones: office.com,live.com, microsoft.com
  • Dominios de marca: amazon.com, audible.com / disney.com, pixar.com
  • Dominios específicos de país para permitir 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 la zona de pruebas con los que los usuarios nunca interactúan directamente, pero que existen motivos de seguridad: googleusercontent.com, githubusercontent.com

¿Cómo te involucras?

Si tiene un conjunto de sitios que coincide con los criterios anteriores, hay una muchas opciones para participar. La inversión más sencilla es leer y unir el debate sobre las dos propuestas:

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

Puedes probarlo en el sitio de demostración de https://fps-member1.glitch.me/ después de comenzar 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 intenta agregar el atributo SameParty en un entorno activo para ver cómo se el conjunto propio afectaría las cookies.

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

Cómo actualizar las cookies para la prueba de origen

Si te unirás a la prueba de origen y probarás el atributo SameParty en tus cookies, ten en cuenta dos patrones.

Opción 1

Primero, cuando tengas cookies que hayas etiquetado como SameSite=None, pero si quieres restringir el acceso a contextos propios, puedes agregar el SameParty a ellos. En los navegadores donde la prueba de origen está activa, la cookie no deben enviarse en contextos entre sitios fuera del conjunto.

Sin embargo, para la mayoría de 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 el origen. a partir de una funcionalidad existente y permite probar específicamente 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 verifiques 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 y el navegador se encuentra en la prueba de origen. Considera este enfoque como un lanzamiento simultáneo de una función actualizada antes de desactivar la anterior versión.

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

Para la mayoría de los sitios, el límite de su sitio es un lugar aceptable para trazar. la partición o el límite de privacidad. Esta es la ruta que se propone CHIPS (cookies con particiones independientes) estado), lo que permitiría que los sitios a través del atributo Partitioned para seguir teniendo esas recursos, APIs y servicios de Google Cloud, al tiempo que evita la filtración de datos información en los sitios.

Hay otros aspectos que debes tener en cuenta para demostrar que tu sitio podría funcionar bien sin tener que un conjunto:

  • Se alojan en diferentes orígenes, no en distintos sitios. En el ejemplo anterior, si brandx.site tuviera fly.brandx.site y drive.brandx.site, entonces esos son subdominios diferentes, todos dentro del mismo sitio. Las cookies pueden usar SameSite=Lax y no se requiere ningún ajuste.
  • Puedes proporcionar incorporaciones de terceros a otros sitios. En la introducción, el ejemplo de un video de video.site insertado en my-blog.site es un tercero evidente dividir. Distintas organizaciones administran los sitios y los usuarios los ven como entidades independientes. Esos dos sitios no deben estar juntos en un conjunto.
  • Proporcionas servicios de acceso social de terceros. de proveedores de identidad que usan elementos como OAuth u OpenId Connect, a menudo, dependen de cookies de terceros para una una experiencia de acceso más fluida para los usuarios. Es un caso de uso válido, pero adecuada para los Conjuntos propios, ya que existe una diferencia clara entre las organizaciones. Las primeras propuestas, como WebID, son y explorar formas de habilitar estos casos de uso.