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.

La inclusión de cookies se determina mediante el atributo SameSite
de la cookie:
- Mismo sitio
contextual con
SameSite=Lax
,Strict
oNone
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.

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.

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.

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á.

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 deLax
a se incluyen contextos de la misma parte cuando se admiten, pero recurre aLax
restricciones si no lo son.SameSite=None; SameParty
restringirá la funcionalidad deNone
a o solo contextos del mismo tipo cuando se admita, pero recurre aNone
.
Estos son algunos requisitos adicionales:
- Las cookies
SameParty
deben incluirSecure
. - Las cookies
SameParty
no deben incluirSameSite=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
yfbcdn.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:
- Debate del grupo de la comunidad sobre la privacidad de conjuntos propios
- Debate sobre el atributo de cookie de SameParty
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
tuvierafly.brandx.site
ydrive.brandx.site
, entonces esos son subdominios diferentes, todos dentro del mismo sitio. Las cookies pueden usarSameSite=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 enmy-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.