Ét commit er ikke et revisionsspor

Ti tusind stjerner og ét commit

Den 14. juli offentliggjorde xAI kildekoden til Grok Build under Apache 2.0, og her til morgen havde repositoryet over ti tusind stjerner. Udgivelsen kom i kølvandet på en test på wire-niveau, der viste, at version 0.2.93 af værktøjet uploadede et tracket repository, og hele dets git-historik som et bundle, til skylagring kontrolleret af xAI, heriblandt et repository, som assistenten havde fået besked på ikke at læse. Vi dækkede det fund den 14. juli, og anvisningen dengang lød, at man skulle rotere alle de hemmeligheder, værktøjet nogensinde havde set. Den anvisning står ved magt.

At offentliggøre koden ligner det stærkest tænkelige svar på et fund af den art. Det er det træk, en ingeniørorganisation gør, når den mener, at optegnelserne frikender den, og sådan bliver det også læst. Det nyttige spørgsmål er derfor ikke, om xAI gjorde ret i at offentliggøre. Det er snævrere og mere praktisk: hvis du nu gik ind i det repository for at skaffe dig vished om, hvad værktøjet foretog sig på dine maskiner, hvad ville du så rent faktisk kunne fastslå?

Meget lidt, viser det sig, og årsagerne er strukturelle snarere end ondsindede. Repositoryet indeholder ét commit, skrevet af en bot den 16. juli klokken 05:46 UTC, med den besked, at det frigiver harness og TUI som open source. Ét commit betyder ingen historik. Der er intet før, ingen diff, ingen række af ændringer, intet at holde noget op imod. Ti tusind stjerner på et repository uden historik er ti tusind mennesker, der bakker op om en gestus.

Hvad repositoryet ikke kan fortælle dig

Begynd med det ene spørgsmål, fundet i virkeligheden rejste: hvor endte koden? Uploadene gik til en Google Cloud Storage-bucket, hvis navn står i den leverede binærfil. I den offentliggjorte kildekode optræder det navn ikke. Det læses fra en miljøvariabel på compile-tidspunktet og fastlægges, når binærfilen bygges. Den, der kompilerer udgivelsen, leverer selv destinationen, og kildekoden siger intet om, hvad den leverede build var rettet mod. Den offentliggjorte kode kan ikke besvare spørgsmålet, hverken i den ene eller den anden retning.

Se dernæst på den funktion, der stod for uploaden. Den ligger der stadig, i shell-cratet, og den gør ikke længere noget. Den tager sine parametre ind, markerer dem som ubrugte, venter på kanalen, smider resultatet væk og returnerer en fejl om, at upload af sessionstilstand ikke er tilgængelig. Selve funktionskroppen er fjernet, mens alt omkring den blev stående: kaldstederne er intakte, manifestet angiver stadig afhængighederne, lagringshjælperne er stadig kompileret ind. Det, du kan læse, er mekanismens skelet med mekanismen taget ud.

Det er samtidig anden gang, at rettelsen er foretaget et sted, du ikke kan efterse. De oprindelige uploads blev stoppet den 13. juli med et flag på serversiden, ikke med en klientudgivelse, og det var det skarpeste ved den første historie: den binærfil, dit team gennemgik og pinnede, var aldrig det, der afgjorde, hvad der forlod maskinen. Nu er koden offentlig, og destinationen er stadig et input på byggetidspunktet, og kontakten sidder stadig på serveren. Det, der kan revideres, og det, der træffer afgørelsen, er ikke rykket det mindste tættere på hinanden.

Fire filer flyttede med, én kom ikke frem

Der er én detalje mere, og den skal formuleres omhyggeligt, for den er let at overfortolke. Strengene inde i den leverede 0.2.93-binærfil nævner et crate ved navn xai-data-collector med fem kildefiler: lagringsklienten, laget til skylagring, køen, en circuit breaker-observer og en tracker, der følger filadgang. Det offentliggjorte repository har intet crate med det navn. Det samme sæt filer ligger i et crate ved navn xai-file-utils, og fire ud af de fem svarer til hinanden. Den femte, trackeren, der følger filadgang, findes slet ikke i den offentliggjorte kildekode.

Hvad det fastslår, og hvad det ikke fastslår, er hele pointen. Det fastslår ikke hensigt. At omdøbe et crate fra noget, der beskriver indsamling af data, til noget, der beskriver håndtering af filer, er præcis det, et team gør, når der ryddes op inden en udgivelse, og at droppe et modul, der ikke længere er koblet til noget, er ganske almindelig oprydning. Der er ingen beviser for tilsløring her, og vi påstår heller ikke, at der er. Det er også værd at bemærke asymmetrien i selve materialet: siden med binærfilen hviler på en tredjeparts udtræk af strenge, mens kildesiden kan efterprøves af enhver, der kloner repositoryet.

Hvad det derimod fastslår, er, at udgivelsen ikke kan fungere som en optegnelse. Den komponent, hvis navn mest direkte beskriver sporing af en brugers filadgang, mangler, dens søskendefiler er til stede under et andet navn, og der findes ingen commit-historik, hvori nogen af de to kendsgerninger kan undersøges. Uskyldige forklaringer og skyldige forklaringer frembringer nøjagtig det samme repository. Det er problemet med at behandle en offentliggørelse som et bevis: det holder kun, hvis artefaktet kan skelne mellem de to, og det kan dette artefakt ikke.

Den påstand, der aldrig blev fremsat

Giv forskeren kredit, for disciplinen på den side af historien er grunden til, at den holder. Analysen på wire-niveau blev lavet med en opsnappende proxy mod en pinnet binærfil, på et engangsrepository udstyret med canary-filer, og den kan gentages: der findes et offentligt harness, og enhver kan køre det. Målingen var utvetydig. Et repository på tolv gigabyte gav 5,10 gibibyte upload-trafik mod 192 kilobyte egentlig modelsamtale, et forhold på omkring otteogtyve tusind til én. Den canary-fil, assistenten havde fået besked på ikke at læse, kom intakt ud af det opsamlede bundle igen.

Og så skrev forskeren ned, hvad testen ikke beviste. At upload ikke er træning, fordi kun transmissionen blev målt. At en enkelt opsamling ved tre gigabyte ikke blev bevaret. At en tidligere konklusion havde været forkert, fordi en netværksmåling afgrænset til processen overså uploads, der gik direkte til Google-adresser, og at den konklusion blev trukket tilbage. Et fund, der offentliggør sine egne grænser og sin egen tilbagetrækning, er et fund, du kan bruge til noget.

Hold det op mod svarene. xAI har sagt, at privatliv ligger virksomheden dybt på sinde, at den respekterer kundernes valg, og at der for teams med zero data retention aldrig gemmes spor- eller kodedata. Elon Musk sagde, at alle brugerdata, der er uploadet indtil nu, vil blive fuldstændig og aldeles slettet, og at absolut intet vil være tilbage. Det kan udmærket passe. Ingen af delene lader sig kontrollere, og sletningen kan ikke verificeres udefra. Mønsteret gennem hele denne episode er konsekvent: de påstande, der kan testes, kom fra personen med proxyen, og de påstande, der ikke kan, kom fra leverandøren.

Tre spørgsmål, før du kalder det løst

Den lektie, der kan generaliseres, har intet med xAI at gøre, og der bliver brug for den igen inden for måneden. Open source er blevet et standardsvar på et sikkerhedsfund, og det er et godt svar, når artefaktet bærer beviser i sig. Det gør det ikke automatisk. Så når en leverandør svarer på et fund om dine data ved at offentliggøre kode, så stil udgivelsen tre spørgsmål, før sagen lukkes.

Kan jeg se historikken? Et squashed første commit er et fotografi, ikke en optegnelse. Hvis repositoryet begynder på udgivelsesdagen, kan det ikke vise, hvad der blev ændret, og det, der er under undersøgelse, er netop en ændring. Svarer det offentliggjorte artefakt til den leverede binærfil? Hvis nogen adfærd af betydning bliver sat på byggetidspunktet eller holdes på en server, er kildekoden en beskrivelse af en mulighed, ikke af det, der kørte på dine maskiner. Indeholder koden den komponent, fundet pegede på? Hvis netop det, der blev fundet, ikke ligger i repositoryet, er fraværet ikke et svar, uanset hvad der er årsagen.

Intet af dette taler for at holde kode lukket, og intet af det er en anklage. Det taler for en sondring, som din indkøbsproces formentlig endnu ikke gør: en offentliggørelse er en oplysning, og en revision er en proces, der frembringer en konklusion. De erstatter ikke hinanden, de er ikke engang nært beslægtede, og en leverandør, der har gjort det første, har ikke gjort det andet. De teams, der behandler et link til et repository som sagen lukket, begår en kategorifejl, og det er den slags fejl, der først bliver synlig i bakspejlet, efter det næste fund.

Læs videre: Sprout slog sine tal og skar 20% samme dag  |  Ingen forbød det. Filteret nægtede alligevel.