Chrome 153 para devs: o que quebra com RWS e requestStorageAccessFor

O Chrome 153 chegou ao canal Stable em 8 de setembro de 2026 e inaugura o ciclo de versões principais a cada duas semanas. Para equipes que mantêm login entre domínios, embeds autenticados ou requisições cross-site com cookies, a incompatibilidade mais concreta desta versão é outra: o Chrome 153 remove Related Website Sets (RWS) e document.requestStorageAccessFor(). A mudança foi listada pelo Chrome entre as remoções do marco 153 e merece uma auditoria antes de atualizar o ambiente de teste ou publicar código dependente dessas APIs.

O ponto principal é separar dois casos. Uma chamada direta a requestStorageAccessFor() perde a API em si e precisa ser removida ou redesenhada. Já uma integração que continua usando a API padrão document.requestStorageAccess() dentro de um iframe não perde essa API, mas deixa de receber o tratamento especial de RWS e passa a seguir o comportamento normal da Storage Access API fora de um conjunto relacionado.

O que o Chrome 153 remove de fato

• document.requestStorageAccessFor(): era uma extensão específica do Chrome que permitia ao documento de nível superior pedir acesso a cookies não particionados em nome de uma origem incorporada. O Chrome informa que a API só era utilizável entre sites de Related Website Sets e, por isso, ela é removida junto com RWS.
• Related Website Sets: o mecanismo que declarava relações entre sites e permitia tratamento especial para acesso cross-site deixa de fazer parte do Chrome 153. Configurações de conjunto deixam de produzir o benefício de concessão associado a RWS.
• O auto-grant de SAA baseado em RWS: chamadas a requestStorageAccess() entre sites que antes pertenciam ao mesmo conjunto passam a seguir as regras comuns da Storage Access API, sem o atalho de RWS.

A documentação do Chrome 153 beta é explícita sobre as duas remoções. O Chrome Platform Status do marco 153 acrescenta que o uso de Storage Access API dentro de um antigo conjunto cai para o comportamento normal da API fora de RWS.

O que não deve ser confundido com essa remoção

A Storage Access API padrão não foi removida. Métodos como document.requestStorageAccess() continuam sendo a via padrão para um conteúdo incorporado solicitar acesso a armazenamento não particionado quando o caso realmente exige isso. O que muda é a ausência do tratamento especial de RWS. Fora de RWS, o fluxo pode exigir interação do usuário, verificação de contexto e uma decisão de permissão; portanto, um caminho que antes parecia automático pode passar a exibir prompt, ser negado ou exigir outra etapa de UX.

Chrome 153 também não representa uma remoção geral dos cookies de terceiros. O próprio Chrome relaciona a retirada de RWS e requestStorageAccessFor() à decisão de manter a abordagem atual para cookies de terceiros. Ainda assim, configurações do usuário, políticas, modo de navegação e outros controles podem limitar cookies cross-site, então o teste de compatibilidade precisa incluir cenários com restrição.

Políticas corporativas e a API de extensão relacionada a RWS não devem ser tratadas automaticamente como removidas no mesmo passo. O intento do Chromium diz que políticas de empresa ligadas a RWS e chrome.privacy.relatedWebsiteSetsEnabled também seriam descontinuadas, mas por processos próprios. Para uma extensão ou ambiente gerenciado, audite esses pontos separadamente e confirme o marco específico antes de removê-los.

Checklist de busca: onde localizar dependências no repositório

Comece por busca literal no código, nos testes, nos manifests e na infraestrutura. Um comando simples com ripgrep pode acelerar a triagem:

rg -n "requestStorageAccessFor|top-level-storage-access|relatedWebsiteSetsEnabled|related-website-set|First-Party Sets|Related Website Sets|requestStorageAccess\(" .

Não limite a auditoria ao front-end. RWS também podia aparecer em arquivos .well-known, configuração de infraestrutura, documentação operacional, testes end-to-end, flags de CI, políticas corporativas e código de extensão. Uma ocorrência sem chamada de SAA pode ser apenas configuração morta; uma ocorrência de requestStorageAccessFor() em produção é incompatibilidade direta.

Classifique cada ocorrência antes de alterar o código

1. Chamada direta a requestStorageAccessFor()

Esse é o caso mais simples: a API foi removida. Não basta proteger a chamada com feature detection e manter o mesmo fluxo como principal, porque o comportamento que ela oferecia não existe mais no Chrome 153. A detecção pode servir como proteção temporária contra erro, mas a funcionalidade precisa de outra arquitetura.

2. requestStorageAccess() dentro de iframe que dependia de RWS

A API padrão continua existindo, porém o antigo vínculo do conjunto deixa de conceder o caminho privilegiado. Refaça o teste com um perfil limpo e valide se a solicitação ocorre em um contexto compatível com SAA, se há uma ação do usuário quando necessária e se o código trata rejeição ou prompt. A documentação da Storage Access API descreve a diferença entre o uso com e sem RWS e lista alternativas por caso de uso.

3. Apenas configuração de Related Website Sets

Arquivos .well-known, referências à lista de conjuntos ou documentação de cadastro deixam de ser mecanismo de compatibilidade para Chrome 153. Antes de apagá-los, confirme se algum outro processo interno ainda os consome; para o navegador, porém, não planeje a experiência supondo o benefício de RWS.

4. Política corporativa ou extensão

Trate como trilha separada. O plano público do Chromium prevê descontinuação das políticas e da configuração chrome.privacy.relatedWebsiteSetsEnabled, mas não é seguro converter essa intenção em “foi removido no 153” sem confirmação do marco correspondente.

Como redesenhar o fluxo sem procurar um substituto 1:1

Não há um substituto universal que replique requestStorageAccessFor() a partir do top-level. A migração depende da razão pela qual o site precisava de cookies ou estado não particionado entre origens.

• Use a Storage Access API padrão quando o embed realmente precisar do mesmo estado não particionado: mova a solicitação para o conteúdo incorporado, trate a necessidade de interação do usuário e implemente caminhos de sucesso, negação e recuperação. O objetivo deve ser testar o resultado do fluxo, não apenas a existência do método.
• Considere CHIPS quando o estado puder ser particionado por site de nível superior: cookies Partitioned atendem widgets e componentes que precisam manter estado no contexto de cada site, mas não precisam compartilhar a mesma sessão entre todos os embeds.
• Considere FedCM para identidade federada: quando o problema é login entre provedor de identidade e relying party, FedCM pode ser uma opção mais adequada que tentar preservar cookies cross-site indiscriminadamente.
• Reduza a necessidade de estado cross-site quando possível: consolidação de origens, redirects autenticados, tokens de curta duração ou APIs de backend podem ser mais previsíveis do que depender de uma exceção de cookie. A escolha depende do modelo de segurança e da arquitetura do produto.

A página da Storage Access API do Privacy Sandbox compara SAA, CHIPS e FedCM e é uma referência melhor para escolher por caso de uso do que procurar uma API com o mesmo formato de requestStorageAccessFor().

Plano de teste: compare Chrome 152 e 153 com o mesmo cenário

Para evitar “funciona na minha máquina”, fixe versões do navegador. O Chrome for Testing permite baixar versões específicas e parear Chrome com ChromeDriver, o que facilita reproduzir o mesmo teste no marco anterior e no 153.

1. Monte um caso mínimo em Chrome 152 e Chrome 153: mesma origem top-level, mesmo iframe, mesmos cookies e mesma sequência de cliques.
2. Use um perfil limpo: permissões antigas podem mascarar o comportamento real de primeira visita. Repita também o caso com uma concessão já existente se esse for um cenário relevante do produto.
3. Teste com restrição de cookies de terceiros: o painel Privacy and security do DevTools permite limitar temporariamente cookies de terceiros durante o teste. Isso expõe fluxos que dependem de concessão de acesso.
4. Observe o código: em M153, uma checagem como typeof document.requestStorageAccessFor === "function" deve deixar claro que o caminho específico não está disponível. A aplicação, porém, deve ser validada pelo comportamento final.
5. Observe a rede: no DevTools, confira se o cabeçalho Cookie está ou não sendo enviado nas requisições cross-site e revise avisos na aba Cookies/Issues. A documentação de cookies no DevTools mostra onde inspecionar cookies enviados e bloqueados.
6. Teste negação e ausência de gesto: um fluxo de SAA precisa funcionar também quando o acesso não é concedido. Evite uma experiência que entra em loop, falha silenciosamente ou pressupõe auto-grant.
7. Leve o caso para CI: fixe o Chrome 153 no teste end-to-end de login/embed e mantenha uma asserção sobre o resultado do usuário — por exemplo, sessão reconhecida, recurso carregado ou fallback exibido.

Remoção, origin trial e feature nova são coisas diferentes

O post do Chrome 153 organiza essas mudanças em blocos diferentes. RWS e requestStorageAccessFor() aparecem em Deprecations and removals: são mudanças de compatibilidade que precisam ser auditadas agora. Já JavaScript Self-Profiling Markers aparece como um novo origin trial: é uma experiência opt-in e não explica uma quebra de código que dependia de RWS.

Da mesma forma, o novo ciclo de duas semanas é uma mudança de calendário, não uma API de compatibilidade. O Chrome informou que o marco 153 é o primeiro Stable desse ciclo, com lançamento em 8 de setembro de 2026. Para a triagem de regressões, registre separadamente: “remoção que altera comportamento existente”, “trial que exige opt-in” e “feature nova”. Isso evita culpar uma novidade experimental por uma incompatibilidade já documentada.

Gate de publicação para projetos afetados

• Não existe chamada de produção a document.requestStorageAccessFor() ainda sem migração.
• Qualquer uso de requestStorageAccess() que dependia de RWS foi retestado fora do auto-grant.
• O fluxo trata permissão, negação e fallback sem depender de comportamento automático.
• Arquivos e documentação de RWS foram identificados e não são mais considerados requisito de compatibilidade no Chrome 153.
• Cookies e requisições com credenciais foram inspecionados no DevTools em um perfil limpo.
• Chrome 153 foi incluído no teste automatizado com versão fixa do Chrome for Testing.
• Políticas corporativas e APIs de extensão relacionadas a RWS estão em uma trilha de acompanhamento separada, sem presumir o mesmo marco de remoção.
• Origin trials e features novas do 153 estão separados da lista de incompatibilidades.

Se todos esses pontos estiverem cobertos, a atualização deixa de ser uma aposta baseada no changelog e vira uma verificação de comportamento: onde a API sumiu, o código foi redesenhado; onde a API padrão permanece, o fluxo foi testado sem o benefício de RWS.

Fontes principais: Chrome 153 beta, ciclo de duas semanas do Chrome, Chrome 153 Release Notes, Storage Access API, guia de Related Website Sets e Chrome for Testing.