A Google lançou o Chrome 153 no canal Stable a 8 de setembro, para desktop, Android e iOS. É a primeira versão publicada ao abrigo do ciclo de lançamentos quinzenal que a Google anunciou em março, e as notas de lançamento, publicadas no mesmo dia, mostram como é na prática um Chrome de duas em duas semanas: dois novos elementos HTML para acesso à câmara e ao microfone, um analisador XML escrito em Rust e seguro em termos de memória, um punhado de adições a CSS e JavaScript, e uma lista de descontinuações que encerra discretamente o capítulo da maior parte do Privacy Sandbox.
O Chrome 154 segue-se a 22 de setembro, segundo o 9to5Google, que também relata o enquadramento da Google para a cadência mais rápida: as correções chegam mais cedo aos utilizadores, e um lançamento mais pequeno facilita isolar uma regressão quando uma escapa.
Câmara e microfone tornam-se elementos HTML
A principal novidade para programadores é um par daquilo a que a Google chama «elementos de capacidade» (capability elements). O elemento <camera> pede captura de vídeo e o elemento <microphone> pede captura de áudio. O artigo «New in Chrome 153», de Rachel Andrew, descreve-os como «declarative, user-activated HTML controls», ou seja, controlos HTML declarativos e ativados pelo utilizador: o browser desenha o botão, o utilizador tem de clicar nele, e só então aparece um pedido de permissão ou começa uma transmissão.
Os elementos assentam no <usermedia>, lançado no Chrome 151 em junho. Esse artigo anterior, de Mari Viana e Minh Le, explicava o raciocínio. Um clique num botão controlado pelo browser é «a trusted signal of intent», um sinal de intenção fiável, o que importa porque os pedidos de permissão disparados por um script sem uma ação evidente do utilizador são precisamente os que os browsers cada vez mais bloqueiam ou escondem. O elemento traz também um caminho de recuperação: se um utilizador negou o acesso à câmara há meses, tocar no elemento «aciona um fluxo de recuperação especializado que lhe permite reativar a câmara ou o microfone instantaneamente na página, sem navegar por definições complexas do browser».
As regras de estilo são deliberadamente rígidas para que o botão não possa ser disfarçado: o artigo sobre o <usermedia> enumera um contraste mínimo de texto de 3:1, nenhuma transparência nem margens negativas, e transformações limitadas a translação 2D e escala proporcional. Os novos elementos de capacidade única mantêm, nas palavras do artigo da beta, «o mesmo modelo de segurança, as mesmas restrições rígidas de estilo e o mesmo caminho integrado de recuperação de permissões do MVP <usermedia>».
Análise de XML segura em memória
O Chrome 153 transfere a análise de XML em vários caminhos comuns para uma implementação em Rust. As notas de lançamento referem o DOMParser, a propriedade responseXML do XMLHttpRequest e as imagens SVG autónomas e externas. Os cenários XSLT não são abrangidos por esta alteração. O objetivo declarado da Google, segundo o artigo da beta, é «eliminar potenciais erros de corrupção de memória mantendo total compatibilidade com as especificações web existentes».
Para quem gere um site, a relevância prática está no SVG. Logótipos, ícones e ilustrações entregues como ficheiros SVG passam agora pelo novo analisador. A Google diz que a compatibilidade é mantida e que não há nada a fazer, mas se um recurso SVG aparecer diferente depois da atualização, é esta a alteração a examinar primeiro.
Adições a CSS e JavaScript
Duas alterações de CSS tratam do scroll. A propriedade overflow aceita agora um valor de scroll em conjunto com clip, pelo que overflow: scroll clip cria um contentor de scroll num eixo enquanto o outro eixo fica recortado no lugar. As notas de lançamento observam que isto permite que position: sticky seja limitado por contentores de scroll ancestrais diferentes em cada eixo. Uma nova propriedade scroll-axis-lock permite ao programador indicar ao browser que não bloqueie um gesto de scroll a um único eixo quando se pretende scroll na diagonal.
O JavaScript ganha duas propostas TC39. Iterator.prototype.join() concatena a saída de um iterador numa string, à imagem de Array.prototype.join(). A Joint Iteration acrescenta Iterator.zip() e Iterator.zipKeyed(), que percorrem vários iteráveis em simultâneo e devolvem arrays ou objetos com chaves; os modos são «shortest» por omissão, «longest» com preenchimento opcional, e «strict», que lança um TypeError quando os comprimentos diferem.
Noutras frentes, o Chrome 153 descodifica o contentor Immersive Audio Model and Formats, um formato aberto de áudio espacial sem royalties, através das Media Source Extensions; as ligações WebTransport podem transportar cabeçalhos HTTP personalizados; e a Long Animation Frames API passa a reportar também a partir de web workers.
O Privacy Sandbox chega à lista de descontinuações
As notas do Chrome 153 indicam que a Protected Audience API, a Shared Storage API, a Attribution Reporting API, os Related Website Sets e document.requestStorageAccessFor estão, cada um deles, «planned for deprecation and removal», isto é, com descontinuação e remoção planeadas. A razão apresentada para os Related Website Sets é que foram concebidos para um browser sem cookies de terceiros, e o Chrome decidiu mantê-los. O artigo da beta, de 20 de agosto, já listava os Related Website Sets e requestStorageAccessFor como remoções.
Nada disto é surpresa. A 17 de outubro de 2025, Anthony Chavez, vice-presidente da Google para o Privacy Sandbox, anunciou que a Google ia retirar dez tecnologias do Privacy Sandbox, entre elas Topics, Protected Audience, Attribution Reporting, Private Aggregation com Shared Storage e Related Website Sets, invocando «ecosystem feedback about their expected value and in light of their low levels of adoption», ou seja, o feedback do ecossistema sobre o valor esperado e os baixos níveis de adoção. Esse artigo prometia que os detalhes iriam «seguir os processos do Chrome e do Android para a retirada gradual destas tecnologias». O Chrome 153 é o ponto em que esses processos se tornam visíveis numa nota de lançamento.
O que significa para o seu negócio
Se o seu site usa câmara ou microfone, vale a pena adotar cedo os novos elementos. Verificações de identidade, prova virtual, um fluxo de «digitalize o seu documento»: cada um deles abre hoje com uma chamada JavaScript e um pedido de permissão que muitos utilizadores rejeitam por reflexo. Um botão desenhado pelo browser, que o utilizador escolhe clicar, com um caminho integrado para recuperar uma permissão anteriormente negada, ataca exatamente o momento em que esses fluxos perdem pessoas. O Chrome é hoje o único browser a disponibilizar isto, por isso tem de ser melhoria progressiva: mantenha o caminho getUserMedia existente como alternativa.
Se a sua pilha publicitária ou de analytics alguma vez integrou uma API do Privacy Sandbox, está na altura de remover esse código. As integrações de Attribution Reporting, Protected Audience e Shared Storage foram feitas sobretudo por fornecedores de ad-tech e não diretamente por quem gere sites, mas as tags e configurações de consentimento que lhes fazem referência continuam a existir. Pergunte ao seu fornecedor o que acontece quando as APIs desaparecerem e certifique-se de que a sua medição de conversões não depende silenciosamente de uma delas. Os cookies de terceiros ficam, o que significa que a configuração de medição que tinha antes do Sandbox é a que permanece.
Os Related Website Sets afetavam um grupo específico: empresas que operam vários domínios com um login ou um carrinho partilhado. Se declarou um conjunto para que os cookies pudessem circular entre os domínios da sua marca, esse mecanismo está a ser retirado. A Storage Access API em si mantém-se; só o atalho baseado em conjuntos e requestStorageAccessFor desaparecem. Verifique agora qualquer início de sessão ou checkout entre domínios, em vez de esperar que um cliente o reporte.
Nada neste lançamento deverá quebrar um site de marketing normal. A alteração de XML e SVG foi pensada para ser invisível, as adições de CSS são opcionais e os métodos JavaScript são novos, não alterados. O hábito que recomendamos, e que incorporamos em cada website que mantemos, é o mesmo da semana passada: um perfil de browser no canal Beta e uma passagem pelos seus formulários, pelo checkout e por qualquer fluxo de câmara de duas em duas semanas. O Chrome 154 Beta já está disponível; passa a Stable a 22 de setembro.
A nossa leitura é que o Chrome 153 é um lançamento modesto com um sinal importante. As funcionalidades são incrementais, mas a lista de descontinuações confirma que o browser desistiu de tentar substituir os cookies de terceiros pelas suas próprias APIs publicitárias. Para uma empresa, isso elimina uma variável que pairou sobre os planos de analytics e publicidade web durante seis anos. Planeie com base em cookies, consentimento e dados próprios, e trate tudo o que tenha o rótulo Privacy Sandbox como legado.
