Chrome 153 llegó al canal Stable el 8 de septiembre de 2026 e inaugura el ciclo de versiones principales de Chrome cada dos semanas. Para los equipos que mantienen inicio de sesión entre dominios, embeds autenticados o solicitudes cross-site con cookies, la incompatibilidad más concreta de esta versión es otra: Chrome 153 elimina Related Website Sets (RWS) y document.requestStorageAccessFor(). Chrome incluye ambas en las eliminaciones del hito 153, por lo que conviene auditarlas antes de actualizar el entorno de pruebas o publicar código que dependa de ellas.
La clave es separar dos casos. Una llamada directa a requestStorageAccessFor() pierde la propia API y debe eliminarse o rediseñarse. Una integración que sigue usando la API estándar document.requestStorageAccess() dentro de un iframe no pierde esa API, pero deja de recibir el tratamiento específico de RWS y pasa al comportamiento normal de Storage Access API fuera de un conjunto relacionado.
Qué elimina realmente Chrome 153
- document.requestStorageAccessFor(): era una extensión específica de Chrome que permitía al documento de nivel superior solicitar acceso a cookies no particionadas en nombre de un origen embebido. Chrome indica que la API solo podía utilizarse entre sitios de Related Website Sets y, por eso, se elimina junto con RWS.
- Related Website Sets: el mecanismo para declarar relaciones entre sitios y habilitar un tratamiento especial del acceso cross-site deja de formar parte de Chrome 153. La configuración de un conjunto deja de aportar el beneficio de concesión asociado a RWS.
- La concesión automática de SAA basada en RWS: las llamadas a requestStorageAccess() entre sitios que antes pertenecían al mismo conjunto pasan a seguir las reglas normales de Storage Access API sin el atajo de RWS.
La documentación de Chrome 153 beta enumera de forma explícita ambas eliminaciones. Las notas de Chrome Platform Status para el hito 153 añaden que el uso de Storage Access API dentro de un antiguo conjunto vuelve al comportamiento de la API fuera de RWS.
Qué no debe confundirse con esta eliminación
La Storage Access API estándar no fue eliminada. Métodos como document.requestStorageAccess() siguen siendo la vía estándar para que un contenido embebido solicite acceso a almacenamiento no particionado cuando el caso de uso realmente lo necesita. Lo que desaparece es el tratamiento específico de RWS. Fuera de RWS, el flujo puede requerir interacción del usuario, comprobaciones de contexto y una decisión de permiso, de modo que una ruta que antes parecía automática puede empezar a mostrar un aviso, ser rechazada o necesitar un paso adicional de UX.
Chrome 153 tampoco supone una eliminación general de las cookies de terceros. El propio Chrome relaciona la retirada de RWS y requestStorageAccessFor() con la decisión de mantener el enfoque actual para las cookies de terceros. Aun así, la configuración del usuario, las políticas, el modo de navegación y otros controles pueden restringir cookies cross-site, por lo que las pruebas de compatibilidad deben incluir escenarios con restricciones.
Las políticas empresariales y la API de extensiones relacionada con RWS no deben tratarse automáticamente como eliminadas en el mismo paso. El intent de Chromium indica que las políticas empresariales ligadas a RWS y chrome.privacy.relatedWebsiteSetsEnabled también están previstas para descontinuación, pero mediante procesos propios. Si mantienes una extensión o un entorno administrado, audítalos por separado y confirma el hito específico antes de retirarlos.
Checklist de búsqueda: dónde localizar dependencias en el repositorio
Empieza con búsquedas literales en el código de la aplicación, pruebas, manifests e infraestructura. Un comando sencillo con ripgrep puede acelerar el triage:
rg -n "requestStorageAccessFor|top-level-storage-access|relatedWebsiteSetsEnabled|related-website-set|First-Party Sets|Related Website Sets|requestStorageAccess\(" .
| Término o patrón | Qué puede indicar | Prioridad |
|---|---|---|
| requestStorageAccessFor | Dependencia directa de la API eliminada. | Alta: corregir antes de publicar. |
| top-level-storage-access | Consulta de permiso ligada al flujo de requestStorageAccessFor(). | Alta: rediseñar junto con la llamada. |
| requestStorageAccess() | Uso de Storage Access API estándar que puede haber dependido de la concesión automática de RWS. | Alta: volver a probar UX y permisos. |
| relatedWebsiteSetsEnabled | Integración de extensión o configuración específica de RWS. | Media/alta: seguir en una pista separada. |
| /.well-known/related-website-set.json | Metadatos de pertenencia a RWS. | Media: dejar de contar con efecto en Chrome 153. |
| First-Party Sets o Related Website Sets | Nombres antiguo/actual en documentación interna, flags o pruebas. | Media: localizar supuestos heredados. |
| credentials: "include" y crossorigin="use-credentials" | Señales secundarias de solicitudes cross-site que pueden depender de cookies después de una concesión de storage access. | Media: revisar con el flujo de autenticación. |
No limites la auditoría al front-end. RWS también puede aparecer en archivos .well-known, configuración de infraestructura, documentación operativa, pruebas end-to-end, flags de CI, políticas empresariales y código de extensiones. Una coincidencia sin llamada a SAA puede ser configuración muerta; una aparición de requestStorageAccessFor() en producción es una incompatibilidad directa.
Clasifica cada aparición antes de cambiar el código
1. Llamada directa a requestStorageAccessFor()
Es el caso más sencillo: la API fue eliminada. La detección de características puede evitar un error inmediato en tiempo de ejecución, pero mantener la ruta antigua como implementación principal no conserva la función porque el comportamiento que ofrecía ya no existe en Chrome 153. El flujo necesita otra arquitectura.
2. requestStorageAccess() dentro de un iframe que dependía de RWS
La API estándar permanece, pero la relación del antiguo conjunto deja de ofrecer la ruta privilegiada. Repite la prueba con un perfil limpio y comprueba que la solicitud se ejecuta en un contexto compatible con SAA, que existe una acción del usuario cuando sea necesaria y que la aplicación gestiona rechazo o prompt. La documentación de Storage Access API describe la diferencia entre usar SAA con y sin RWS y enumera alternativas por caso de uso.
3. Solo configuración de Related Website Sets
Los archivos .well-known, las referencias a la lista de conjuntos o la documentación de registro dejan de ser un mecanismo de compatibilidad para Chrome 153. Antes de borrarlos, confirma si otro proceso interno los consume; para el comportamiento del navegador, sin embargo, no diseñes la experiencia suponiendo un beneficio de RWS.
4. Política empresarial o extensión
Trátalo como una pista separada. El plan público de Chromium incluye la descontinuación de políticas y de chrome.privacy.relatedWebsiteSetsEnabled, pero no es seguro convertir esa intención en “eliminado en 153” sin confirmar el hito correspondiente.
Cómo rediseñar el flujo sin buscar un sustituto 1:1
No existe un reemplazo universal que reproduzca requestStorageAccessFor() desde el nivel superior. La migración depende de por qué el sitio necesitaba cookies o estado no particionado entre orígenes.
- Usa la Storage Access API estándar cuando el embed realmente necesite el mismo estado no particionado: mueve la solicitud al contenido embebido, gestiona el requisito de interacción del usuario e implementa rutas de éxito, denegación y recuperación. Comprueba el comportamiento de negocio, no solo la presencia del método.
- Considera CHIPS cuando el estado pueda particionarse por sitio de nivel superior: las cookies Partitioned encajan en widgets y componentes que necesitan mantener estado dentro de cada sitio que los embebe, pero no compartir la misma sesión entre todos los embeds.
- Considera FedCM para identidad federada: cuando el problema central es el inicio de sesión entre un proveedor de identidad y una relying party, FedCM puede encajar mejor que intentar conservar acceso amplio a cookies cross-site.
- Reduce el estado cross-site cuando sea posible: consolidación de orígenes, redirects autenticados, tokens de corta duración o APIs de backend pueden ser más predecibles que depender de una excepción de cookies. La elección correcta depende de la arquitectura y del modelo de seguridad del producto.
La página de Storage Access API del Privacy Sandbox compara SAA, CHIPS y FedCM y es una mejor referencia para elegir por caso de uso que buscar una API con la misma forma que requestStorageAccessFor().
Plan de pruebas: compara Chrome 152 y 153 con el mismo escenario
Para evitar el “en mi máquina funciona”, fija versiones del navegador. Chrome for Testing permite descargar versiones concretas y emparejar Chrome con ChromeDriver, lo que facilita reproducir la misma prueba en el hito anterior y en el 153.
- Monta un caso mínimo en Chrome 152 y Chrome 153: mismo origen top-level, mismo iframe, mismas cookies y la misma secuencia de clics.
- Usa un perfil limpio: permisos anteriores pueden ocultar el comportamiento de primera visita. Repite también el caso con una concesión ya existente si es relevante para el producto.
- Prueba con cookies de terceros restringidas: el panel Privacy and security de DevTools permite limitar temporalmente las cookies de terceros durante la prueba. Esto expone flujos que dependen de una concesión de storage access.
- Observa la ruta de código: en M153, una comprobación como typeof document.requestStorageAccessFor === "function" debe dejar claro que la ruta específica de Chrome no está disponible. Aun así, la aplicación debe validarse por su comportamiento final.
- Observa la red: en DevTools, comprueba si el encabezado Cookie se envía en solicitudes cross-site y revisa avisos en Cookies/Issues. La documentación de cookies de DevTools muestra dónde inspeccionar cookies enviadas y bloqueadas.
- Prueba denegación y ausencia de gesto: un flujo de SAA también debe comportarse correctamente cuando el acceso no se concede. Evita bucles, fallos silenciosos o supuestos de concesión automática.
- Lleva el caso a CI: fija Chrome 153 en la prueba end-to-end de login/embed y mantén una aserción sobre el resultado visible para el usuario, como una sesión reconocida, un recurso cargado o un fallback explícito.
Eliminación, origin trial y función nueva son categorías diferentes
El post de Chrome 153 separa estos cambios en secciones distintas. RWS y requestStorageAccessFor() aparecen en Deprecations and removals: son cambios de compatibilidad que deben auditarse ahora. JavaScript Self-Profiling Markers, en cambio, aparece como un nuevo origin trial: es un experimento opt-in y no explica una regresión en código que dependía de RWS.
Del mismo modo, el nuevo ciclo de dos semanas es un cambio del calendario de lanzamientos, no una API de compatibilidad. Chrome anunció el hito 153 como el primer Stable de ese ciclo, publicado el 8 de septiembre de 2026. Al hacer triage de regresiones, registra por separado: “eliminación que cambia comportamiento existente”, “trial que exige opt-in” y “función nueva”. Así se evita culpar a una novedad experimental por una eliminación ya documentada.
Gate de publicación para proyectos afectados
- No queda ninguna llamada de producción a document.requestStorageAccessFor() sin migrar.
- Cualquier flujo con requestStorageAccess() que dependía de RWS se volvió a probar sin la concesión automática de RWS.
- El flujo gestiona permiso, denegación y fallback sin suponer acceso automático.
- Los archivos y la documentación de RWS fueron identificados y ya no se tratan como requisito de compatibilidad de Chrome 153.
- Las cookies y solicitudes con credenciales se inspeccionaron en DevTools con un perfil limpio.
- Chrome 153 se añadió a las pruebas automatizadas con una versión fijada de Chrome for Testing.
- Las políticas empresariales y APIs de extensión relacionadas con RWS se siguen por separado, sin suponer que comparten el mismo hito de eliminación.
- Los origin trials y las nuevas funciones de Chrome 153 se mantienen separados de la lista de incompatibilidades.
Con estas comprobaciones cubiertas, la actualización deja de ser una apuesta basada en el changelog y se convierte en una verificación de comportamiento: donde la API desapareció, el código se rediseñó; donde la API estándar permanece, el flujo se probó sin el beneficio de RWS.
Fuentes principales: Chrome 153 beta, ciclo de lanzamientos de dos semanas de Chrome, Chrome 153 Release Notes, Storage Access API, guía de Related Website Sets y Chrome for Testing.
