Google tar fyra gigabyte utan att fråga – och det är bara toppen av AI-säkerhetsisberget
Google laddar ner fyra gigabyte AI-data på din dator – utan att fråga.
När infrastrukturen rör sig snabbare än förtroendet
Det är lätt att glömma bort att varje ny AI-funktion som rullas ut i en webbläsare eller ett ramverk inte bara är en produktnyhet – det är också ett säkerhets- och integritetsbeslut. Den insikten fick miljontals Chrome-användare erfara på ett ovälkommet sätt den här veckan, när det uppdagades att Google har börjat installera en fil vid namn weights.bin på användarnas hårddiskar utan att be om lov. Filen på fyra gigabyte är kärnan i Gemini Nano, Googles nedskalade språkmodell avsedd för lokal körning direkt i webbläsaren.
Som systemutvecklare förstår jag logiken bakom beslutet. Lokal inferens – att köra modellen på din egen maskin i stället för på en fjärrserver – är faktiskt bra för integriteten på lång sikt. Inget data skickas till Google, svarstiderna minskar och funktioner som bedrägerivarningar kan fungera utan nätuppkoppling. Det är en tekniskt sund arkitektur.
Men teknisk sundhet och etisk sundhet är inte samma sak. Att ta fyra gigabyte av en användares lagringsutrymme i anspråk – utan förvarning, utan godkännande, utan ens ett litet dialogfönster – är ett förtroendeproblem, inte ett prestandaproblem. Enligt Ny Teknik försöker Googles Chrometeam lugna användarna med att filen är nödvändig för lokala AI-funktioner. Det kanske stämmer. Men att informera i efterhand är inte detsamma som att be om tillåtelse.
Ett opatchat hål mitt i AI-ekosystemets hjärta
Samtidigt rapporterar SecurityWeek om ett betydligt allvarligare problem. Säkerhetsföretaget HiddenLayer har avslöjat en kritisk sårbarhet i ChromaDB – en öppen källkods-databas som används för att bygga AI-tillämpningar och som laddas ned ungefär 13 miljoner gånger i månaden via pakethanteraren pip. Sårbarheten har fått smeknamnet ChromaToast och möjliggör fjärrstyrning av servern utan att angriparen ens behöver autentisera sig.
Mekanismen är snyggt obehaglig: ChromaDB litar på de modellidentifierare som klienten skickar med och agerar på dem – laddar ner och kör modellen – innan behörighetskontrollen ens hinner genomföras. En angripare kan alltså peka ut en skadlig modell på HuggingFace och få servern att hämta och exekvera godtycklig kod. Allt på servern är sedan tillgängligt: API-nycklar, miljövariabler, lagrade hemligheter, filer.
Det som gör detta extra bekymmersamt är att ingen korrigering finns på plats. Alla versioner från 1.0.0 och framåt är drabbade, och HiddenLayer uppskattar att ungefär 73 procent av internetanslutna installationer är sårbara. Välkända organisationer finns bland de exponerade. Det är precis den typ av sårbarhet som kriminella aktörer aktivt söker efter.
Angriparna har skaffat sig en affärsmodell
Och de kriminella aktörerna är inte längre löst sammansatta grupper av ensamma hackare. HPE Threat Labs dokumenterar i sin rapport In the Wild Report hur cyberbrottsligheten alltmer organiserar sig i professionella hierarkier – med specialiserade roller, arbetsdelning och AI-driven automation. De utnyttjar kända sårbarheter i större skala och med högre hastighet än vad traditionella säkerhetsteam klarar att möta. En opatchad ChromaDB-installation är precis det som ryms i deras automatiserade sökningar.
Till det ska läggas forskningsresultat från arXiv som visar att maskerade diffusionsspråkmodeller har betydligt sämre integritetsskydd än tidigare antagits. Forskarna lyckades med så kallade medlemskapsinferensattacker – tekniker för att avgöra om specifik data använts vid träning av en modell – med ett genomsnittligt träffsäkerhetsvärde på 0,878. Ännu mer oroväckande: attackerna fungerade även med surrogatmodeller tränade på helt andra domäner, utan tillgång till målmodellens träningsdata. Det öppnar för att känslig träningsdata kan läcka ur modeller som vi trodde var skyddade.
Resiliens måste byggas in från början
Det finns ett svar på allt detta, och det handlar inte om att bromsa AI-utbyggnaden. Det handlar om att bygga cyberresiliens som en grundförutsättning, inte som en eftertanke. SecurityWeek lyfter hur moderna organisationer behöver identifiera sin minsta livskraftiga verksamhet – vilka processer, system och leverantörskedjor som måste hålla även när något går fel – och sedan dimensionera säkerhetsarbetet utifrån det.
Det är ett tankesätt som AI-plattformar och webbläsarutvecklare lika gärna kan ta till sig. Vad är den minsta livskraftiga integritetsgarantin ni kan erbjuda era användare? Svaret borde aldrig vara: vi ber om förlåtelse i efterhand.
Vår analys
De fem nyheterna den här veckan hänger ihop på ett sätt som är lätt att missa om man läser dem var för sig. Det handlar inte om isolerade misstag – det handlar om ett strukturellt mönster där AI-teknikens utbyggnadstakt konsekvent springer ifrån säkerhets- och integritetsarbetet.
Google-incidenten är i grunden ett styrningsproblem, inte ett tekniskt problem. ChromaDB-sårbarheten är ett symptom på att öppen källkods-ekosystemet för AI saknar de granskningsprocesser som mer mogen infrastruktur har byggt upp under decennier. Och de industrialiserade angreppen är en logisk konsekvens av att angriparna nu kan automatisera det som försvararna fortfarande gör manuellt.
Den goda nyheten är att vi vet vad som behövs: tydligare samtycke i produktdesign, säkrare standardinställningar i AI-ramverk och organisatorisk resiliens som tar höjd för det oförutsägbara. Det är lösbara problem – men bara om vi behandlar dem som förstahandsprioriteringar, inte som punkter på en framtida att-göra-lista.