API de Storage Access

El bloqueo de cookies de terceros por parte de los navegadores, la configuración del usuario y la división del almacenamiento representan un desafío para los sitios y servicios que dependen de las cookies y otros tipos de almacenamiento en contextos integrados, para los recorridos del usuario, como la autenticación. La API de Storage Access (SAA) permite que estos casos de uso sigan funcionando y, al mismo tiempo, limita el seguimiento en sitios cruzados tanto como sea posible.

Estado de implementación

La API de Storage Access está disponible en todos los navegadores principales, pero existen ligeras diferencias de implementación entre los navegadores. Estas diferencias se destacaron en las secciones pertinentes de esta publicación.

Se sigue trabajando para resolver todos los problemas de bloqueo restantes antes de estandarizar la API.

¿Qué es la API de Storage Access?

La API de Storage Access es una API de JavaScript que permite que los elementos iframe soliciten permisos de acceso al almacenamiento cuando, de lo contrario, la configuración del navegador denegaría el acceso. Las incorporaciones con casos de uso que dependen de la carga de recursos de sitios cruzados pueden usar la API para solicitar permiso de acceso al usuario, según sea necesario.

Si se otorga la solicitud de almacenamiento, el iframe tendrá acceso a sus cookies y almacenamiento sin particionar, que también están disponibles cuando los usuarios lo visitan como un sitio de nivel superior.

La API de Storage Access permite proporcionar acceso específico a cookies y almacenamiento sin particionar con una carga mínima para el usuario final, al mismo tiempo que evita el acceso genérico a cookies y almacenamiento sin particionar, como se suele usar para el seguimiento del usuario.

Casos de uso

Algunos elementos incorporados de terceros requieren acceso a cookies o almacenamiento sin particionar para brindar una mejor experiencia al usuario, algo que no estará disponible cuando se restrinjan las cookies de terceros y se habilite la partición del almacenamiento.

En los casos de uso, se incluye lo siguiente:

• Widgets de comentarios integrados que requieren detalles de la sesión de acceso
• Botones de "Me gusta" de redes sociales que requieren detalles de la sesión de acceso
• Documentos incorporados que requieren detalles de la sesión de acceso.
• Es una experiencia premium que se proporciona a un video incorporado (por ejemplo, para no mostrar anuncios a los usuarios que accedieron a sus cuentas o para conocer las preferencias del usuario en cuanto a subtítulos o restringir ciertos tipos de videos).
• Sistemas de pago integrados

Muchos de estos casos de uso implican conservar el acceso de inicio de sesión en elementos iframe incorporados.

Cuándo usar la API de Storage Access en lugar de otras APIs

La API de Storage Access es una de las alternativas al uso de cookies y almacenamiento sin particionar, por lo que es importante comprender cuándo usar esta API en comparación con las demás. Está diseñado para casos de uso en los que se cumplen las siguientes condiciones:

• El usuario interactuará con el contenido incorporado, es decir, no es un iframe pasivo ni oculto.
• El usuario visitó el origen incorporado en un contexto de nivel superior, es decir, cuando ese origen no está incorporado en otro sitio.

Existen APIs alternativas para una variedad de casos de uso:

• Cookies Having Independent Partitioned State (CHIPS) permite que los desarrolladores habiliten el almacenamiento "particionado" de una cookie, con un contenedor de cookies independiente por sitio de nivel superior. Por ejemplo, un widget de chat web de terceros puede depender de la configuración de una cookie para guardar la información de la sesión. La información de la sesión se guarda por sitio, por lo que no es necesario acceder a la cookie establecida por el widget en otros sitios web en los que también está incorporado. La API de Storage Access es útil cuando un widget integrado de terceros depende de compartir la misma información en diferentes orígenes (por ejemplo, para los detalles o las preferencias de la sesión iniciada).
• El aislamiento del almacenamiento es una forma de que los elementos iframe de sitios cruzados usen los mecanismos de almacenamiento de JavaScript existentes y, al mismo tiempo, dividan el almacenamiento subyacente por sitio. Esto evita que el mismo elemento incorporado en otros sitios web acceda al almacenamiento incorporado en un sitio web.
• Los Conjuntos de sitios web relacionados (RWS) son una forma en que una organización puede declarar relaciones entre sitios para que los navegadores permitan el acceso limitado a cookies y almacenamiento sin particionar para fines específicos. Los sitios aún deben solicitar acceso con la API de Storage Access, pero, en el caso de los sitios que forman parte del conjunto, se puede otorgar acceso sin instrucciones del usuario.
• Federated Credential Management (FedCM) es un enfoque que preserva la privacidad para los servicios de identidad federada. La API de Storage Access se encarga de acceder a las cookies y al almacenamiento sin particionar después del acceso. Para algunos casos de uso, FedCM proporciona una solución alternativa a la API de Storage Access y puede ser preferible, ya que incluye un mensaje del navegador más orientado al acceso. Sin embargo, adoptar FedCM suele requerir cambios adicionales en tu código, por ejemplo, para admitir sus extremos HTTP.
• También existen APIs de prevención de fraude, relacionadas con anuncios y de medición, y la API de Storage Access no está diseñada para abordar esas inquietudes.

Usa la API de Storage Access

La API de Storage Access tiene dos métodos basados en promesas:

• Document.hasStorageAccess() (también disponible con el nuevo nombre Document.hasUnpartitionedCookieAccess() a partir de Chrome 125)
• Document.requestStorageAccess()

También se integra con la API de Permissions. Esto te permite verificar el estado del permiso de acceso al almacenamiento en un contexto de terceros, lo que indica si se otorgaría automáticamente una llamada a document.requestStorageAccess():

• navigator.permissions.query({name: "storage-access"});

Usa el método hasStorageAccess()

Cuando un sitio se carga por primera vez, puede usar el método hasStorageAccess() para verificar si ya se otorgó acceso a las cookies de terceros.

// Set a hasAccess boolean variable which defaults to false.
let hasAccess = false;

async function handleCookieAccessInit() {
  if (!document.hasStorageAccess) {
    // Storage Access API is not supported so best we can do is
    // hope it's an older browser that doesn't block 3P cookies.
    hasAccess = true;
  } else {
    // Check whether access has been granted using the Storage Access API.
    hasAccess = await document.hasStorageAccess();
    if (!hasAccess) {
      // Handle the lack of access (covered later)
    }
  }
  if (hasAccess) {
    // Use the cookies.
  }
}
handleCookieAccessInit();

La API de Storage Access solo otorga acceso al almacenamiento a un documento iframe después de que llama a requestStorageAccess(),, por lo que hasStorageAccess() puede devolver false inicialmente, por ejemplo, si el usuario bloquea las cookies de terceros de forma predeterminada. (Sin embargo, la configuración del usuario específica del sitio también puede permitir el acceso a las cookies en un sitio en particular, incluso si el usuario bloquea las cookies de terceros de forma predeterminada). El acceso al almacenamiento con esta API se conserva en las navegaciones del mismo origen dentro del iframe específicamente para permitir recargas después de otorgar acceso a las páginas que requieren que las cookies estén presentes en la solicitud inicial del documento HTML.

Usa requestStorageAccess()

Si el iframe no tiene acceso, es posible que deba solicitarlo con el método requestStorageAccess():

if (!hasAccess) {
  try {
    await document.requestStorageAccess();
  } catch (err) {
    // Access was not granted and it may be gated behind an interaction
    return;
  }
}

La primera vez que se solicita, es posible que el usuario deba aprobar este acceso con un mensaje del navegador, después de lo cual se resolverá la promesa o se rechazará, lo que generará una excepción si se usa await.

Para evitar abusos, este mensaje del navegador solo se mostrará después de una interacción del usuario. Por eso, requestStorageAccess() debe llamarse inicialmente desde un controlador de eventos activado por el usuario, en lugar de hacerlo inmediatamente cuando se carga el iframe:

async function doClick() {

  // Only do this extra check if access hasn't already been given
  // based on the hasAccess variable.
  if (!hasAccess) {
    try {
      await document.requestStorageAccess();
      hasAccess = true; // Can assume this was true if requestStorageAccess() did not reject.
    } catch (err) {
      // Access was not granted.
      return;
    }
  }

  if (hasAccess) {
    // Use the cookies
  }
}

document.querySelector('#my-button').addEventListener('click', doClick);

Mensajes de permisos

Cuando el usuario haga clic en el botón por primera vez, el mensaje del navegador aparecerá automáticamente en la mayoría de los casos, por lo general, en la barra de direcciones. En la siguiente captura de pantalla, se muestra un ejemplo del mensaje de Chrome, pero otros navegadores tienen una IU similar:

En ciertas circunstancias, el navegador puede omitir la solicitud y otorgar el permiso automáticamente:

• Si la página y el iframe se usaron en los últimos 30 días después de aceptar el mensaje.
• Si el iframe incorporado forma parte de un Conjunto de sitios web relacionados
• Si FedCM se usa como un indicador de confianza para el acceso al almacenamiento
• En Firefox, la instrucción también se omite para los sitios web conocidos (aquellos con los que interactuaste en el nivel superior) durante los primeros cinco intentos.

Como alternativa, es posible que el método se rechace automáticamente sin mostrar el mensaje en ciertas circunstancias:

• Si el usuario no visitó ni interactuó previamente con el sitio propietario del iframe como documento de nivel superior, no en un iframe. Esto significa que la API de Storage Access solo es útil para los sitios incorporados que los usuarios visitaron anteriormente en un contexto de origen.
• Si se llama al método requestStorageAccess() fuera de un evento de interacción del usuario sin aprobación previa de la instrucción después de una interacción

Si bien se le pedirá al usuario que resuelva requestStorageAccess() en el uso inicial, las visitas posteriores pueden resolverlo sin un mensaje y sin requerir la interacción del usuario en Chrome y Firefox. Ten en cuenta que Safari siempre requiere una interacción del usuario.

Dado que el acceso a las cookies y al almacenamiento se puede otorgar sin un mensaje ni interacción del usuario, a menudo es posible obtener acceso a las cookies o al almacenamiento sin particionar antes de que se produzca una interacción del usuario en los navegadores que admiten esta función (Chrome y Firefox) llamando a requestStorageAccess() en la carga de la página. Esto puede permitirte acceder a las cookies y al almacenamiento sin particionar de inmediato, y brindar una experiencia más completa, incluso antes de que el usuario interactúe con el iframe. En algunas situaciones, esto puede brindar una mejor experiencia del usuario que esperar a que este interactúe.

FedCM como indicador de confianza para la SAA

FedCM (Federated Credential Management) es un enfoque que preserva la privacidad para los servicios de identidad federada (como "Acceder con…") que no se basa en cookies de terceros ni redireccionamientos de navegación.

Cuando un usuario accede a una parte de confianza (RP) que tiene contenido incorporado de un proveedor de identidad (IdP) externo con FedCM, el contenido incorporado del IdP puede obtener automáticamente acceso al almacenamiento de sus propias cookies sin particionar de nivel superior. Para habilitar el acceso automático al almacenamiento con FedCM, se deben cumplir las siguientes condiciones:

• La autenticación de FedCM (el estado de acceso del usuario) debe estar activa.
• El RP habilitó la opción configurando el permiso identity-credentials-get, por ejemplo:

<iframe src="https://idp.example" allow="identity-credentials-get"></iframe>

Por ejemplo, un iframe de idp.example está incorporado en rp.example. Cuando el usuario accede con FedCM, el iframe de idp.example puede solicitar acceso al almacenamiento para sus propias cookies de nivel superior.

El rp.example realiza una llamada a FedCM para permitir que el usuario acceda con el proveedor de identidad idp.example:

// The user will be asked to grant FedCM permission.
const cred = await navigator.credentials.get({
  identity: {
    providers: [{
      configURL: 'https://idp.example/fedcm.json',
      clientId: '123',
    }],
  },
});

Después de que el usuario accede, el IdP puede llamar a requestStorageAccess() desde el iframe de idp.example, siempre y cuando el RP lo haya permitido explícitamente con la Política de permisos. La incorporación recibirá automáticamente acceso de almacenamiento a su propia cookie de nivel superior, sin activación del usuario ni necesidad de otra solicitud de permiso:

// Make this call within the embedded IdP iframe:

// No user gesture is needed, and the storage access will be auto-granted.
await document.requestStorageAccess();

// This returns `true`.
const hasAccess = await document.hasStorageAccess();

El permiso se otorgará automáticamente solo mientras el usuario haya accedido con FedCM. Una vez que la autenticación esté inactiva, se aplicarán los requisitos de la SAA estándar para otorgar acceso al almacenamiento.

API de Storage Access para el almacenamiento sin cookies

Para solicitar acceso al almacenamiento local sin particionar, pasa el parámetro types a tu llamada de requestStorageAccess. Por ejemplo, para solicitar acceso al almacenamiento local sin particionar, puedes llamar a requestStorageAccess({localStorage: true}).

Si las cookies de terceros están habilitadas, este método otorgará acceso sin necesidad de que el usuario active la función ni de que aparezca un mensaje de permiso. Si el usuario inhabilitó las cookies de terceros, se le deberá mostrar un mensaje antes de otorgarle acceso al almacenamiento.

Primero, verifica si el navegador ya tiene acceso al almacenamiento:

async function hasCookieAccess(){
  // Check if Storage Access API is supported
  if (!document.requestStorageAccess) {
    // Storage Access API is not supported, so we assume it's an older browser that doesn't partition storage.
    throw new Error("requestStorageAccess is not supported")
  }

  // Check if access has already been granted or if the user has 3-party cookies enabled
  return document.hasStorageAccess();
}

Si las cookies de terceros están habilitadas, solicita el acceso al almacenamiento:

// Request storage access and return the storage handle
async function requestStorageHandle(){
// You can request for multiple types of non-cookie storage
// at once, or request for all of them with all:true
return document.requestStorageAccess({all:true});
}

Si se bloquean las cookies de terceros (por ejemplo, en el modo Incógnito), verifica los permisos de consulta para decidir si se requiere una instrucción del usuario. El estado del permiso navigator.permissions.query({name: 'storage-access'}) puede tener los siguientes valores:

• granted: El usuario ya otorgó acceso. Llama a requestStorageAccess para obtener acceso al almacenamiento sin particiones sin necesidad de un mensaje adicional para el usuario.
• prompt: El usuario aún no otorgó acceso. Establece un objeto de escucha de clics y vuelve a llamar a requestStorageAccess después de una interacción del usuario.
• error. El permiso no es compatible. Cuando se admite la API de Storage Access, es probable que también se admita este permiso.

// Returns `granted`, or `prompt`; or throws an error if storage-access
// permission is not supported
async function getStorageAccessPermission(){
  // Check the storage-access permission
  // Wrap this in a try/catch for browsers that support the
  // Storage Access API but not this permission check
    return navigator.permissions.query({name: 'storage-access'});
}

El flujo completo para controlar el almacenamiento particionado que no se basa en cookies se puede implementar de la siguiente manera:

async function getStorageHandle() {
    // Check if the user has 3-party cookie access
    if (await hasCookieAccess()) {
    // If the user has access, requestStorageAccess() will resolve automatically
        return requestStorageHandle();
    }

    // If the browser blocks third party cookies, check if the user has
    // accepted the prompt and granted access. If they have,
    // requestStorageAccess() will resolve automatically
    const permission = await getStorageAccessPermission();
    if (permission == 'granted') { // User has seen prompt and granted access
        return requestStorageHandle();
    }

    // Wait for user activation to prompt the user again
    // (or put your silent failure logic here instead)
    return new Promise((resolve, reject) => {
        document.querySelector('#myButton').addEventListener(e => {
            requestStorageHandle().then(resolve, reject);
        })
    })
}

// Use your storage
getStorageHandle().then(handle=>{
    handle.indexedDB.open(...);
}).catch(() => {
    // If the promise is rejected, you can use regular partitioned storage
    indexedDB.open(...);
})

Cargas posteriores con encabezados de Storage Access

Los encabezados de Storage Access son una forma recomendada y más eficiente de habilitar la carga de contenido incorporado, incluidos los recursos que no son de iframe. La función está disponible a partir de Chrome 133. Con los encabezados de Storage Access, el navegador puede reconocer cuando el usuario ya otorgó permiso de storage-access al origen de terceros en el contexto actual y puede cargar recursos con acceso a cookies sin particionar durante las visitas posteriores.

Flujo de encabezados de acceso al almacenamiento

Con los encabezados de Storage Access, las visitas a páginas posteriores activarán el siguiente flujo:

1. El usuario ya visitó website.example, que incorpora un recurso calendar.example, y otorgó storage-access con la llamada document.requestStorageAccess().
2. El usuario visita website.example, que tiene el recurso calendar.example incorporado nuevamente. Esta solicitud aún no tiene acceso a la cookie, como antes. Sin embargo, el usuario ya otorgó el permiso storage-access y la recuperación incluye un encabezado Sec-Fetch-Storage-Access: inactive para indicar que el acceso a cookies no particionadas está disponible, pero no activado.
3. El servidor calendar.example responde con un encabezado Activate-Storage-Access: retry; allowed-origin='<origin>' (en este caso, <origin> sería https://website.example) para indicar que la recuperación de recursos requiere el uso de cookies sin particionar con el permiso storage-access.
4. El navegador vuelve a intentar realizar la solicitud, esta vez incluyendo cookies sin particionar (activando el permiso storage-access para esta recuperación y las recuperaciones posteriores).
5. El servidor calendar.example responde con el contenido personalizado del iframe. La respuesta incluye un encabezado Activate-Storage-Access: load para indicar que el navegador debe cargar el contenido con el permiso storage-access activado (en otras palabras, cargar con acceso a cookies sin particionar, como si se hubiera llamado a document.requestStorageAccess()).
6. El agente de usuario carga el contenido del iframe con acceso a cookies sin particionar a través del permiso storage-access. Después de este paso, el widget puede funcionar según lo esperado.

Usa encabezados de acceso al almacenamiento

En la siguiente tabla, se enumeran los encabezados de Storage Access.

Por ejemplo, los encabezados de acceso al almacenamiento se pueden usar para cargar una imagen de un tercero:

  // On the client side
  <img src="https://server.example/image">

En este caso, server.example debe implementar la siguiente lógica en el servidor:

  app.get('/image', (req, res) => {
  const storageAccessHeader = req.headers['sec-fetch-storage-access'];

  if (storageAccessHeader === 'inactive') {
    // The user needs to grant permission, trigger a prompt

    // Check if the requesting origin is allowed
    // to send credentialed requests to this server.
    // Assuming the `validate_origin(origin)` method is previously defined:
    if (!validate_origin(req.headers.origin)) {
      res.status(401).send(req.headers.origin +
        ' is not allowed to send credentialed requests to this server.');
      return;
    }
    // 'retry' header value indicates that the content load request should be re-sent after the user has granted permissions
    res.set('Activate-Storage-Access', `retry; allowed-origin='${req.headers.origin}'`);
    res.status(401).send('This resource requires storage access. Please grant permission.');
  } else if (storageAccessHeader === 'active') {
    // User has granted permission, proceed with access
    res.set('Activate-Storage-Access', 'load');
    // Include the actual iframe content here
    res.send('This is the content that requires cookie access.');
  } else {
    // Handle other cases (e.g., 'Sec-Fetch-Storage-Access': 'none')
  }
});

La demostración de la API de Storage Access incorpora contenido de terceros (incluida una imagen que no es de iframe) con encabezados de Storage Access.

Usa la consulta de permiso storage-access

Para verificar si se puede otorgar acceso sin una interacción del usuario, puedes verificar el estado del permiso storage-access y solo realizar la llamada requestStoreAccess() de forma anticipada si no se requiere ninguna acción del usuario, en lugar de llamarla y hacer que falle cuando se requiere una interacción.

Esto también te permite abordar la necesidad de un mensaje de forma anticipada mostrando contenido diferente, por ejemplo, un botón de acceso.

En el siguiente código, se agrega la verificación de permisos storage-access al ejemplo anterior:

// Set a hasAccess boolean variable which defaults to false except for
// browsers which don't support the API - where we assume
// such browsers also don't block third-party cookies.
let hasAccess = false;

async function hasCookieAccess() {
  // Check if Storage Access API is supported
  if (!document.requestStorageAccess) {
    // Storage Access API is not supported so best we can do is
    // hope it's an older browser that doesn't block 3P cookies.
    return true;
  }

  // Check if access has already been granted
  if (await document.hasStorageAccess()) {
    return true;
  }

  // Check the storage-access permission
  // Wrap this in a try/catch for browsers that support the
  // Storage Access API but not this permission check
  // (e.g. Safari and earlier versions of Firefox).
  let permission;
  try {
    permission = await navigator.permissions.query(
      {name: 'storage-access'}
    );
  } catch (error) {
    // storage-access permission not supported. Assume no cookie access.
    return false;
  }

    if (permission) {
    if (permission.state === 'granted') {
      // Permission has previously been granted so can just call
      // requestStorageAccess() without a user interaction and
      // it will resolve automatically.
      try {
        await document.requestStorageAccess();
        return true;
      } catch (error) {
        // This shouldn't really fail if access is granted, but return false
        // if it does.
        return false;
      }
    } else if (permission.state === 'prompt') {
      // Need to call requestStorageAccess() after a user interaction
      // (potentially with a prompt). Can't do anything further here,
      // so handle this in the click handler.
      return false;
          } else if (permission.state === 'denied') {
            // Not used: see https://github.com/privacycg/storage-access/issues/149
      return false;
          }
    }

  // By default return false, though should really be caught by earlier tests.
  return false;
}

async function handleCookieAccessInit() {
  hasAccess = await hasCookieAccess();

  if (hasAccess) {
    // Use the cookies.
  }
}

handleCookieAccessInit();

Iframes en zona de pruebas

Cuando se usa la API de Storage Access en iframes con zona de pruebas, se requieren los siguientes permisos de zona de pruebas:

• Se requiere allow-storage-access-by-user-activation para permitir el acceso a la API de Storage Access.
• Se requiere allow-scripts para permitir el uso de JavaScript para llamar a la API.
• allow-same-origin es obligatorio para permitir el acceso a las cookies y a otro tipo de almacenamiento del mismo origen.

Por ejemplo:

<iframe sandbox="allow-storage-access-by-user-activation
                 allow-scripts
                 allow-same-origin"
        src="..."></iframe>

Requisitos de cookies

Para acceder a las cookies entre sitios con la API de Storage Access en Chrome, estas deben establecerse con los siguientes dos atributos:

• SameSite=None, que es obligatorio para marcar la cookie como de varios sitios
• Secure, que garantiza que solo se pueda acceder a las cookies establecidas por sitios HTTPS.

En Firefox y Safari, las cookies se establecen de forma predeterminada en SameSite=None y no restringen el SAA a las cookies de Secure, por lo que no se requieren estos atributos. Se recomienda ser explícito sobre el atributo SameSite y usar siempre cookies Secure.

Acceso a la página de nivel superior

La API de Storage Access está diseñada para habilitar el acceso a cookies de terceros dentro de iframes incorporados.

También hay otros casos de uso en los que la página de nivel superior requiere acceso a cookies de terceros. Por ejemplo, imágenes o secuencias de comandos restringidas por cookies, que los propietarios de sitios pueden querer incluir directamente en el documento de nivel superior en lugar de en un iframe. Para abordar este caso de uso, Chrome propuso una extensión de la API de Storage Access que agrega un métodorequestStorageAccessFor().

El método requestStorageAccessFor()

El método requestStorageAccessFor() funciona de manera similar a requestStorageAccess(), pero para los recursos de nivel superior. Solo se puede usar para sitios dentro de un conjunto de sitios web relacionados para evitar otorgar acceso general a las cookies de terceros.

Para obtener más detalles sobre cómo usar requestStorageAccessFor(), consulta la guía para desarrolladores de Conjuntos de sitios web relacionados.

La consulta de permiso top-level-storage-access

De manera similar al permiso storage-access, existe un permiso top-level-storage-access para verificar si se puede otorgar acceso a requestStorageAccessFor().

¿En qué se diferencia la API de Storage Access cuando se usa con RWS?

Cuando se usan los Conjuntos de sitios web relacionados con la API de Storage Access, se encuentran disponibles ciertas capacidades adicionales, como se detalla en la siguiente tabla:

Demostración: Cómo configurar cookies y acceder a ellas

En la siguiente demostración, se muestra cómo se puede acceder a una cookie que tú mismo estableciste en la primera pantalla de la demostración en un iframe incorporado en el segundo sitio de la demostración:

storage-access-api-demo.glitch.me

La demostración requiere un navegador con las cookies de terceros inhabilitadas:

• Chrome 118 o versiones posteriores con la marca chrome://flags/#test-third-party-cookie-phaseout establecida y el navegador reiniciado
• Firefox
• Safari

Demostración: Configuración del almacenamiento local

En la siguiente demostración, se muestra cómo acceder a canales de transmisión sin particionar desde un iframe de terceros con la API de Storage Access:

https://saa-beyond-cookies.glitch.me/

La demostración requiere Chrome 125 o una versión posterior con la marca test-third-party-cookie-phaseout habilitada.

Recursos

• Lee la especificación que proporciona acceso a cookies de terceros o sigue y plantea problemas.
• Lee la especificación que proporciona acceso al almacenamiento sin particiones o sigue y plantea problemas.
• Documentación de la API y guía
• Documentación de Chrome sobre el uso de la API de Storage Access en Conjuntos de sitios web relacionados