The Pulse
Secondo un’indagine, ZCode carica intere cronologie Git senza avvisare
Un’indagine di reverse engineering afferma che ZCode raccoglie interi spazi di lavoro, comprese le cronologie Git e le cache LFS, e carica istantanee cifrate su Aliyun OSS. Una segnalazione pubblica nel repository di feedback di ZCode descr
AI.info Team ·
Un’indagine di reverse engineering pubblicata il 18 settembre afferma che ZCode, l’agente di coding desktop di Zhipu, raccoglie e carica molti più dati dei file che uno sviluppatore invia attivamente a una sessione di IA. L’indagine descrive istantanee cifrate che contengono metadati Git completi, cache Git LFS, reflog e alcuni file di configurazione globali di ZCode, inviate direttamente ad Aliyun Object Storage mentre l’utente è connesso.
L’indagine è stata condotta da ferstar, che ricostruisce il comportamento esaminando file locali, registri dell’applicazione e il codice JavaScript incluso nel client. Documenta un test dettagliato su macOS, ma non stabilisce quanti utenti o spazi di lavoro siano stati coinvolti. Una segnalazione distinta nel repository ufficiale di feedback di ZCode, aperta lo stesso giorno, descrive prove simili raccolte su sistemi macOS e Linux.
Un’istantanea da 313 MB in attesa di caricamento
L’indagine è iniziata quando l’autore ha scoperto che la directory locale di dati di ZCode aveva superato i 700 MB. Nella directory v2/checkpoints dell’applicazione si trovavano un archivio cifrato di 313.070.842 byte e un file di stato che indicava un’istantanea dello spazio di lavoro da 345.549.173 byte. Lo spazio di lavoro apparteneva a quello che l’autore descrive come un progetto commerciale e l’archivio era contrassegnato come un’istantanea «completa» di riferimento.
Il file di stato locale registrava 564 tentativi di caricamento non riusciti. Secondo il rapporto, ZCode aveva analizzato lo spazio di lavoro, escluso directory come node_modules, compresso i dati rimanenti e lasciato l’archivio in una directory in attesa di un nuovo tentativo. L’autore afferma che il repository originale era di circa 10 GB, mentre il materiale selezionato per l’istantanea era di 345 MB e consisteva in gran parte di risorse del progetto.
La segnalazione pubblica nel repository di feedback descrive un meccanismo simile. L’autore afferma che, con ZCode Desktop versione 3.12.3 su macOS e versione 3.10.0 su un sistema remoto Linux, i file di stato locali contenevano valori lastAcceptedManifestHash insieme a manifesti che elencavano un gran numero di percorsi .git. La segnalazione è ancora aperta e non indica un responsabile.
Il percorso di caricamento passa da Aliyun OSS
Secondo l’indagine principale, ZCode richiede prima le credenziali di caricamento a zcode.z.ai tramite /api/v1/snapshot/upload-credential. La risposta fornisce un identificativo dell’istantanea, una chiave pubblica RSA, limiti di dimensione, credenziali per il modulo e una callback. ZCode crea quindi localmente un archivio tar.gz, lo cifra con AES-256-CTR e carica il file risultante direttamente su Aliyun OSS, anziché inviare l’archivio attraverso il server principale dell’applicazione ZCode.
Il rapporto afferma che, dopo aver accettato l’oggetto, il servizio OSS invia una callback al backend di Zhipu. Durante i test, l’autore descrive anche connessioni persistenti dal client in esecuzione agli endpoint di ZCode e ai nodi di archiviazione Aliyun. Questi risultati mostrano l’esistenza di una procedura di caricamento sul cloud, ma non stabiliscono da soli per quanto tempo i dati vengano conservati, quali membri del personale possano accedervi o se ogni istantanea accettata venga poi indicizzata.
Il sistema di cifratura solleva un’altra questione. Il client genera una chiave simmetrica effimera per l’archivio e la protegge con una chiave pubblica RSA fornita dal server. Sul computer di test non è stata trovata la chiave privata corrispondente. Il rapporto conclude quindi che il client locale e l’utente non possono decifrare l’archivio conservato senza la chiave custodita nel cloud.
I metadati Git costituiscono la maggior parte dell’archivio esaminato
Il manifesto salvato localmente elencava 42.411 file. Nella ripartizione pubblicata dall’autore dell’indagine, .git/lfs occupava 196,1 MB, pari al 56,8% dell’istantanea; .git/objects occupava 102,2 MB, pari al 29,6%; e .git/logs aggiungeva 0,6 MB. Il codice sorgente e la documentazione ammontavano a circa 46,2 MB, pari al 13,4%.
In base a queste cifre, i dati Git rappresentavano l’86,6% del contenuto. Comprendevano l’archivio degli oggetti, che contiene commit, alberi e blob storici, oltre ai file LFS e ai record reflog. Il rapporto avverte che questo materiale può conservare credenziali eliminate, vecchi file di configurazione, nomi di branch non inviati, percorsi interni dei repository e altre informazioni assenti dall’albero di lavoro corrente.
L’autore dell’indagine ha trovato anche un manifesto separato chiamato repo_snapshot_extra_manifest. Questo calcola l’hash di file di configurazione globali di ZCode, come settings.behavior.json, e li associa alle istantanee degli spazi di lavoro. La segnalazione pubblica sostiene analogamente che potrebbero essere inclusi dati di configurazione a livello utente relativi a MCP, hook, competenze e agenti, anche se queste affermazioni più ampie derivano dall’ispezione locale dell’autore della segnalazione, non da una specifica di ZCode pubblicata.
Le impostazioni visibili non fermano l’acquisizione descritta
Il rapporto confronta due impostazioni con il comportamento riscontrato nel client. Secondo l’indagine, optimizeAgentExperienceEnabled determina se i dati raccolti possono essere usati per l’addestramento dei modelli, mentre repoSnapshotIndexingEnabled controlla l’indicizzazione lato server. Nella versione testata, nessuna delle due impostazioni ha impedito la raccolta locale e il caricamento.
Esaminando il codice dell’assembly host dell’applicazione, l’autore afferma che il componente di acquisizione e caricamento viene creato incondizionatamente all’avvio. Secondo quanto riportato, per attivare il processo è necessario un token di accesso valido. Gli eventi di acquisizione si verificano prima dei prompt e al termine delle attività contrassegnate con repo-wiki-update; il registro di una sessione conteneva fino a 62 eventi di acquisizione.
La segnalazione pubblica descrive la stessa apparente discrepanza: repoSnapshotIndexingEnabled era impostato su false, ma il computer aveva comunque generato un indicatore di istantanea accettata. L’autore chiede a ZCode di rendere facoltativa l’acquisizione dell’intero repository, chiarire se vengano inclusi i metadati Git e la configurazione globale, offrire un’opzione per disattivarla con un clic e spiegare come gli utenti possano eliminare i dati già caricati.
Non è stata trovata alcuna spiegazione pubblica dell’azienda
La documentazione pubblica di ZCode sul feedback indirizza gli utenti alle segnalazioni su GitHub, a Discord e all’assistenza in-app, mentre la pagina delle versioni dell’azienda indica che la versione 3.12.3 è stata rilasciata il 17 settembre. Né la segnalazione pubblica né le note di rilascio esaminate per questo articolo contengono una risposta di ZCode che spieghi il comportamento delle istantanee o le relative politiche di conservazione.
L’indagine principale afferma che l’informativa sulla privacy di ZCode fa riferimento alla raccolta di «testo, file e codice inviati durante le conversazioni», ma non descrive esplicitamente la raccolta silenziosa di interi spazi di lavoro o cronologie Git. È questa distinzione il fulcro della controversia: inviare file allegati volontariamente dall’utente è diverso dal creare ripetute istantanee in background dello stato storico di un repository.
La soluzione temporanea proposta dal rapporto agisce a livello di sistema operativo, non dall’app. Consiglia di eliminare la directory locale dei checkpoint, ricrearla e contrassegnarla come immutabile con chflags uchg su macOS o chattr +i su Linux. Questo blocca la scrittura locale, ma disattiva anche le funzioni di ripristino dei checkpoint e di cronologia di ZCode. Le prove pubbliche disponibili documentano al momento un caso di test e segnalazioni di più utenti, ma non il numero totale di account coinvolti, la sorte definitiva degli archivi caricati o se Z.ai abbia corretto il comportamento.