Google släppte Chrome 153 i Stable-kanalen den 8 september för desktop, Android och iOS. Det är den första versionen som levereras enligt den tvåveckorscykel Google tillkännagav i mars, och versionsanteckningarna, publicerade samma dag, visar hur en Chrome varannan vecka ser ut i praktiken: två nya HTML-element för kamera- och mikrofonåtkomst, en minnessäker XML-parser skriven i Rust, en handfull tillägg i CSS och JavaScript samt en avvecklingslista som i det tysta sätter punkt för större delen av Privacy Sandbox.

Chrome 154 följer den 22 september enligt 9to5Google, som också återger Googles motivering till det snabbare tempot: rättningar når användarna tidigare, och en mindre release gör det lättare att ringa in en regression när en sådan slinker igenom.

Kamera och mikrofon blir HTML-element

Den största nyheten för utvecklare är ett par av vad Google kallar ”capability elements”, kapacitetselement. Elementet <camera> begär videoupptagning och elementet <microphone> begär ljudupptagning. Rachel Andrews inlägg ”New in Chrome 153” beskriver dem som ”declarative, user-activated HTML controls”, alltså deklarativa HTML-kontroller som användaren själv aktiverar: webbläsaren ritar knappen, användaren måste klicka på den, och först då visas en behörighetsfråga eller startas en ström.

De bygger på elementet <usermedia> som kom i Chrome 151 i juni. Det tidigare inlägget, av Mari Viana och Minh Le, förklarade resonemanget. Ett klick på en knapp som webbläsaren kontrollerar är ”a trusted signal of intent”, en pålitlig avsiktssignal, vilket spelar roll eftersom behörighetsförfrågningar som avfyras från ett skript utan någon tydlig användarhandling är just de som webbläsare allt oftare blockerar eller gömmer undan. Elementet har också en väg tillbaka: om en användare nekade kameraåtkomst för flera månader sedan ”utlöser” ett tryck på elementet ”ett särskilt återställningsflöde som låter dig aktivera kameran eller mikrofonen igen direkt på sidan, utan att navigera i krångliga webbläsarinställningar”.

Stilreglerna är avsiktligt strikta så att knappen inte kan förklädas: <usermedia>-inlägget listar en minsta textkontrast på 3:1, ingen transparens och inga negativa marginaler, och transformationer begränsade till 2D-förflyttning och proportionell skalning. De nya elementen med en enda kapacitet behåller, med beta-inläggets ord, ”samma säkerhetsmodell, strikta stilbegränsningar och inbyggda väg för återställning av behörigheter som <usermedia>-MVP:n”.

Minnessäker XML-tolkning

Chrome 153 flyttar XML-tolkningen för flera vanliga vägar till en implementation i Rust. Versionsanteckningarna nämner DOMParser, egenskapen responseXML hos XMLHttpRequest samt fristående och externa SVG-bilder. XSLT-scenarier omfattas inte av ändringen. Googles uttalade mål är, enligt beta-inlägget, att ”eliminera potentiella minneskorruptionsbuggar med bibehållen full kompatibilitet med befintliga webbspecifikationer”.

För en sajtägare är den praktiska betydelsen SVG. Logotyper, ikoner och illustrationer som levereras som SVG-filer går nu genom den nya parsern. Google säger att kompatibiliteten bibehålls och att inget behöver göras, men om en SVG-fil renderas annorlunda efter uppdateringen är det här ändringen att titta på först.

Tillägg i CSS och JavaScript

Två CSS-ändringar rör scrollning. Egenskapen overflow accepterar nu ett scrollbart värde tillsammans med clip, så att overflow: scroll clip skapar en scrollcontainer längs en axel medan den andra axeln förblir klippt på plats. Versionsanteckningarna påpekar att detta gör att position: sticky kan begränsas av olika överordnade scrollcontainrar per axel. En ny egenskap, scroll-axis-lock, låter utvecklaren tala om för webbläsaren att inte låsa en scrollgest till en enda axel när diagonal scrollning önskas.

JavaScript får två TC39-förslag. Iterator.prototype.join() slår ihop en iterators utdata till en sträng, i linje med Array.prototype.join(). Joint Iteration lägger till Iterator.zip() och Iterator.zipKeyed(), som går igenom flera iterabler i takt och ger arrayer eller objekt med nycklar; lägena är ”shortest” som standard, ”longest” med valfri utfyllnad, och ”strict”, som kastar ett TypeError när längderna skiljer sig åt.

I övrigt avkodar Chrome 153 containern Immersive Audio Model and Formats, ett öppet och royaltyfritt format för rumsligt ljud, via Media Source Extensions; WebTransport-anslutningar kan bära egna HTTP-huvuden; och Long Animation Frames API rapporterar nu även från web workers.

Privacy Sandbox hamnar på avvecklingslistan

Anteckningarna för Chrome 153 anger att Protected Audience API, Shared Storage API, Attribution Reporting API, Related Website Sets och document.requestStorageAccessFor var och en är ”planned for deprecation and removal”, alltså planerade för avveckling och borttagning. Skälet som anges för Related Website Sets är att det utformades för en webbläsare utan tredjepartskakor, och Chrome har beslutat att behålla dem. Beta-inlägget från den 20 augusti listade redan Related Website Sets och requestStorageAccessFor som borttagningar.

Inget av detta är en överraskning. Den 17 oktober 2025 meddelade Anthony Chavez, Googles vicepresident för Privacy Sandbox, att Google lade ner tio Privacy Sandbox-tekniker, däribland Topics, Protected Audience, Attribution Reporting, Private Aggregation med Shared Storage och Related Website Sets, med hänvisning till ”ecosystem feedback about their expected value and in light of their low levels of adoption”, det vill säga ekosystemets återkoppling om deras förväntade värde och deras låga användning. Inlägget lovade att detaljerna skulle ”följa Chromes och Androids processer för att fasa ut dessa tekniker”. Chrome 153 är där dessa processer blir synliga i en versionsanteckning.

Vad det betyder för din verksamhet

Om din sajt använder kamera eller mikrofon är de nya elementen värda att införa tidigt. Identitetskontroller, virtuell provning, ett ”skanna ditt dokument”-flöde: vart och ett av dessa inleds i dag med ett JavaScript-anrop och en behörighetsfråga som många användare reflexmässigt klickar bort. En knapp som webbläsaren ritar och som användaren själv väljer att klicka på, med en inbyggd väg för att återfå en tidigare nekad behörighet, träffar exakt det ögonblick där sådana flöden tappar folk. Chrome är i dag den enda webbläsaren som levererar detta, så det måste ske som progressiv förbättring: behåll den befintliga getUserMedia-vägen som reserv.

Om din annonsstack eller analys någonsin integrerade ett Privacy Sandbox-API är det dags att ta bort den koden. Integrationer av Attribution Reporting, Protected Audience och Shared Storage gjordes oftast av ad tech-leverantörer snarare än av sajtägare direkt, men taggar och samtyckeskonfigurationer som refererar till dem finns fortfarande kvar. Fråga din leverantör vad som händer när API:erna försvinner, och se till att din konverteringsmätning inte i det tysta är beroende av något av dem. Tredjepartskakorna blir kvar, vilket betyder att den mätuppsättning du hade före Sandbox är den som består.

Related Website Sets påverkade en specifik grupp: företag som driver flera domäner med gemensam inloggning eller varukorg. Om du deklarerade ett set för att kakor skulle kunna flöda mellan dina varumärkesdomäner dras den mekanismen nu tillbaka. Storage Access API i sig finns kvar; det är bara den setbaserade genvägen och requestStorageAccessFor som försvinner. Kontrollera all inloggning och utcheckning över domängränser nu, i stället för när en kund rapporterar det.

Inget i den här releasen bör knäcka en vanlig marknadsföringssajt. XML- och SVG-ändringen är tänkt att vara osynlig, CSS-tilläggen är frivilliga och JavaScript-metoderna är nya snarare än ändrade. Vanan vi rekommenderar, och bygger in i varje webbplats vi förvaltar, är densamma som förra veckan: en webbläsarprofil på Beta-kanalen och en genomgång av dina formulär, din kassa och eventuella kameraflöden varannan vecka. Chrome 154 Beta är redan ute; den blir Stable den 22 september.

Vår läsning är att Chrome 153 är en blygsam release med en viktig signal. Funktionerna är inkrementella, men avvecklingslistan bekräftar att webbläsaren har slutat försöka ersätta tredjepartskakor med sina egna annons-API:er. För ett företag tar det bort en variabel som har hängt över planerna för webbanalys och annonsering i sex år. Planera utifrån kakor, samtycke och förstapartsdata, och behandla allt som är märkt Privacy Sandbox som föråldrat.

← Alla artiklar