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.
La inclusión de cookies se determina mediante el atributo SameSite
de estas:
- El contexto del mismo sitio con
SameSite=Lax
,Strict
oNone
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.
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.
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.
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.
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 deLax
para incluir contextos del mismo tercero cuando se admitan, pero recurrirá a las restricciones deLax
si no es así.SameSite=None; SameParty
restringirá la funcionalidadNone
solo a contextos del mismo tercero cuando se admitan, pero recurrirá a los permisosNone
más amplios si no es así.
Existen algunos requisitos adicionales:
- Las cookies
SameParty
deben incluirSecure
. - Las cookies
SameParty
no deben incluirSameSite=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:
- Debate sobre el grupo de la comunidad de privacidad de conjuntos propios
- Debate sobre el atributo de las cookies de SameParty
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íafly.brandx.site
ydrive.brandx.site
, esos son subdominios diferentes dentro del mismo sitio. Las cookies pueden usarSameSite=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 enmy-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.