Zusammenfassung:
ZCode, das KI-Programmiertool von Zhipu, wurde wegen seines Hintergrundpakets und Hochladens von Benutzerprojekten in Frage gestellt.
Entwickler stellten fest, dass nicht nur der aktuelle Code gepackt wurde, sondern auch der Git-Verlauf, der frühere Änderungen speicherte. Am 18. September gab Entwickler Ferstar seine Ergebnisse zur Fehlerbehebung bekannt: ZCode generierte eine Kopie des Projekts auf diesem Computer und versuchte wiederholt, es hochzuladen. Anschließend stellten auch andere Benutzer Bewertungsunterlagen zur Verfügung. Einige stellten fest, dass die Kopie des Projekts vom Server akzeptiert wurde, und andere fragten sich, ob der Warehouse-Indexwechsel das Hochladen verhindern könnte. Benutzer fragten daher: Warum sammelt die Software diese Inhalte und wie kann verhindert werden, dass sie hochgeladen werden?
ZCode entschuldigte sich an diesem Tag und führte das Problem auf die Funktionen im Zusammenhang mit dem „Code-Basisindex“ zurück, die in der Anfangszeit standardmäßig aktiviert waren. Das Unternehmen sagte, dass Repo Wiki beim Generieren einer Warehouse-Enzyklopädie in der Cloud möglicherweise einen Daten-Upload auslöst und die relevanten Daten sofort nach der Generierung vernichtet werden. Es versprach außerdem, den Client als Open Source bereitzustellen und eine Überprüfung durch Dritte einzuführen.
Am 19. September veröffentlichte ZCode 3.14.0 und im Update-Protokoll hieß es: „Das Problem des abnormalen Uploads der Warehouse-Enzyklopädie wurde behoben.“ Ferstar ergänzte die Überprüfungsergebnisse auch und sagte, dass der entsprechende Upload-Code in der neuen Version entfernt wurde.
Nachdem die Software als Open Source verfügbar ist, können Außenstehende überprüfen, warum die Software hochgeladen wurde und welche Änderungen dieses Mal vorgenommen wurden. Allerdings muss das Unternehmen weiterhin Empfangs- und Verarbeitungsaufzeichnungen darüber vorlegen, welche Dateien der Server zuvor empfangen hat und ob diese wie versprochen gelöscht wurden.
Wenn sich die Überprüfung durch Dritte nur auf den Kunden konzentriert, kann sie die Fragen der Benutzer zu diesem Stapel historischer Daten nicht beantworten.
1. Bereinigen Sie die Festplatte und finden Sie eine Kopie des Projekts
ferstar hat das Upload-Verhalten zunächst nicht überprüft. Als er die Festplatte seines Computers aufräumte, stellte er fest, dass das Datenverzeichnis von ZCode viel Platz beanspruchte, und beim Durchsuchen fand er eine 313 MB große verschlüsselte Datei. Dabei handelt es sich um einen von der Software für das Projekt generierten Snapshot, der dem Packen eines Stapels von Projektdateien in eine Kopie entspricht.
Die mit dem Snapshot gespeicherte Liste listet 42411 Dateien auf. Berechnet nach Dateivolumen stammen etwa 86,6 % davon aus dem .git-Verzeichnis, in dem Versionsdatensätze gespeichert sind, einschließlich Git-Verlaufsobjekten, Betriebsprotokollen und dem LFS-Cache für große Dateien.
Wohin werden diese Dokumente geschickt? ferstar überprüfte weiterhin den Client-Code und fand einen Upload-Prozess: Die Software beantragte zunächst ein Upload-Zertifikat beim ZCode-Server, packte und verschlüsselte dann die Datei, sendete die Datei an den OSS-Cloud-Speicherdienst von Alibaba Cloud und schließlich benachrichtigte die Cloud den ZCode-Server, sich zu registrieren und das Ergebnis zu empfangen.
Es wurde jedoch 564 Mal versucht, die 313 MB große Datei hochzuladen, scheiterte jedoch jedes Mal und blieb auf dem lokalen Computer und wartete auf einen erneuten Versuch.
Ferstar hat dies im Update vom 19. September ausdrücklich klargestellt und außerdem hinzugefügt: Sein anderer kleinerer öffentlicher Lagerhaus-Snapshot, der Status, hat gezeigt, dass der Server ihn akzeptiert hat.Entwickler Vonng hat es dann auf der macOS-Version von ZCode 3.12.3 überprüft. Er fand einen Snapshot des normalen Arbeitsbereichs, der keine .git-Datei enthielt, und der Datensatz zeigte, dass er vom Server akzeptiert wurde; In den anderen beiden Snapshots machte .git 93,9 % bzw. 98,5 % des gesamten Dateivolumens aus. Der Kunde hatte die Upload-Anmeldeinformationen erhalten, öffentliche Aufzeichnungen konnten jedoch nicht bestätigen, ob er den Upload abgeschlossen hatte.
ZCode hat auch relevante Berichte im Feedback-Bereich auf GitHub erhalten. Der Einsender von Problem Nr. 707 sagte, er habe eine Liste der vom Server akzeptierten Snapshots gefunden, die mehr als zweitausend .git-Pfade enthielten. Er wies auch darauf hin, dass der Snapshot globale Konfigurationen wie Verbindungsinformationen, automatische Ausführungsskripte und vom Benutzer festgelegte Befehlsdateien für das KI-Tool enthalten wird. Sein Urteil basiert auf lokalen Aufzeichnungen und es gibt keine serverseitigen Prüfergebnisse, die überprüft werden könnten.
2. Auch gelöschter Code kann verfolgt werden
Der wiederkehrende Git-Verlauf in diesen Listen bereitet den Benutzern Sorgen.
Git ermöglicht es Entwicklern, alte Codeversionen abzurufen, was auch bedeutet, dass heute gelöschte Inhalte möglicherweise nicht aus dem Warehouse verschwunden sind.
Versehentlich übermittelte Schlüssel, Konfigurationsdateien oder interne Adressen können in historischen Objekten erhalten bleiben.
Die Sicherheitsdokumentation von GitHub erinnert außerdem daran, dass nur das Löschen vertraulicher Informationen in der neuesten Version des Codes nicht dazu führt, dass die Kopie im Git-Verlauf gelöscht wird.
Möglicherweise gibt es noch lokale Einreichungen, die noch nicht in Git gepusht wurden. Der Einreichungsdatensatz enthält die E-Mail-Adresse des Autors und der große Dateicache enthält möglicherweise Materialien, die zuvor im Projekt verwendet wurden. ZCode muss erklären, warum es diesen Inhalt hochladen muss, um Benutzern bei der Erledigung der anstehenden Aufgabe zu helfen.
Die obigen Beispiele können nicht beweisen, dass der echte Schlüssel durchgesickert ist.
Diejenigen, die das interne Lager in ZCode geöffnet haben, müssen wissen, welche Versionen und Zeiträume betroffen waren, damit sie zurückgehen und den möglicherweise verpackten historischen Inhalt überprüfen können.Die Datenschutzrichtlinie von ZCode besagt, dass zur Bereitstellung von Inhalten und KI-gestützten Vorgängen Dateien und Codes gesammelt werden, die von Benutzern in Gesprächen „übermittelt und angegeben“ werden. Wenn die Software jedoch den Git-Verlauf im Hintergrund verpackt, lässt sich aus der vorhandenen Produktbeschreibung nicht erkennen, ob der Benutzer davon Kenntnis hat und damit einverstanden ist.
Auch wenn die Datei verschlüsselt ist, haben Benutzer Grund zu fragen: Erklären Sie vor dem Hochladen klar, was hochgeladen wird, und lassen Sie sie dann entscheiden, ob sie zustimmen möchten.
Was die Frage betrifft, ob die Dateien zum Trainieren von Modellen verwendet werden, besagt dieselbe Richtlinie, dass der „Optimierungsplan“ standardmäßig deaktiviert ist und Eingaben, generierte Inhalte oder Produktnutzungsdaten nicht für Produkt- und Modelltraining und -optimierung verwendet werden, bis Benutzer aktiv beitreten.
Vorhandene öffentliche Materialien zeigen nicht, dass diese Lagerdaten in den Trainingsprozess eingeflossen sind.
Aber für Unternehmen reicht das bloße Versprechen, keinen Code für Schulungen zu verwenden, nicht aus, um dieser Herausforderung zu begegnen. Auch die Speicherung, der Zugriff und die Vernichtung von Dateien nach dem Hochladen erfordern Verarbeitungsaufzeichnungen, die von Benutzern überprüft werden können.
3. Schließen Sie die Indizierung. Können Sie das Hochladen deaktivieren
?Wenn der Benutzer nicht möchte, dass diese Hintergrund-Snapshots den Computer verlassen, reicht es nicht aus zu wissen, dass der „Optimierungsplan“ standardmäßig deaktiviert ist. Sie benötigen außerdem eine Option zur Steuerung des Uploads.
Laut der Einführung von ZCode hängt das Upload-Verhalten mit dem „Code-Basisindex“ zusammen. Diese Funktion wird zum lokalen Generieren von Warehouse-Indizes verwendet und unterstützt die Wiederherstellung von Sitzungsprüfpunkten, das Rollback historischer Versionen und das Repo-Wiki. Die ersten beiden Elemente helfen Benutzern bei der Wiederherstellung des Projektstatus, während Warehouse Encyclopedia für die Analyse der Projektstruktur und die Erstellung der Dokumentation verantwortlich ist.
Dem Entwicklerwiederherstellungsprozess nach zu urteilen, verfügte ZCode ursprünglich über eine Warehouse-Upload-Funktion. In der Beschreibung vom 18. September wurde das Problem auf verwandte Funktionen zurückgeführt, die in der Anfangsphase standardmäßig aktiviert waren. Es wurde jedoch nicht näher darauf eingegangen, ob dieser Fix die Upload-Bedingungen, den Dateisammlungsbereich oder die Steuerlogik zum Setzen von Schaltern angepasst hat. Es ist nicht klar, welche Daten für mehrere Funktionen benötigt werden: Welche Dateien werden nur für die lokale Wiederherstellung verwendet und welche werden in die Cloud übertragen. Warum werden der Git-Verlauf, der Cache für große Dateien und die globale Konfiguration von Benutzern berücksichtigt?
ferstar sagte, dass in der von ihm überprüften Version 3.12.3 nach dem Deaktivieren von „Erfahrung optimieren“ und „Warehouse Snapshot Index“ der Hintergrund immer noch paketiert und versucht, hochzuladen.
Der Einsender von Problem Nr. 707 sagte, dass er nach dem Schließen des Warehouse-Snapshot-Index einen Eintrag darüber gefunden habe, dass der Server Snapshots auf seinem lokalen Computer akzeptiert. Es muss geprüft werden, ob der Upload vor oder nach dem Ausschalten erfolgt.
Ob diese Option die lokale Indizierung oder den Cloud-Upload steuert, muss von ZCode erklärt werden.
Community-Entwickler haben dem Client auch Einschränkungen auferlegt. Das Projekt zcode-webui fügt während der offiziellen Laufzeit vier Schutzebenen hinzu, die jeweils Snapshot-Anmeldeinformationen abfangen, hochladen, lesen und lokal speichern. Durch diese Abhörvorgänge sollen weitere Uploads verhindert werden. Was in der Vergangenheit übermittelt wurde und was der Server getan hat, muss noch gesondert untersucht werden.
Als ferstar Version 3.14.0 überprüfte, hieß es, dass der für das Hochladen verantwortliche Code und die Hintergrundkomponenten entfernt worden seien und lokale Prüfpunkte weiterhin beibehalten würden; Die Schnittstelle zur Beantragung von Upload-Anmeldeinformationen hat ebenfalls 404 zurückgegeben.
Er hat die obige Version und Schnittstelle überprüft. Ob auch andere Plattformen repariert wurden, ob alte Clients weiterhin hochladen können und wann die Reparatur auf dem Server wirksam wird, bedarf noch einer offiziellen Erklärung.
4. Was muss nach der Reparatur noch untersucht werden?
Nach dem Start der Reparaturversion möchten Benutzer vor allem bestätigen, ob ihre Projekte übertragen wurden. In den Datenschutzbestimmungen von ZCode ist eine E-Mail-Adresse für die Abfrage und Löschung personenbezogener Daten angegeben. Wir hoffen, dass das Unternehmen klarstellt, ob dieser Kanal Anfragen zu diesem ungewöhnlichen Upload bearbeiten kann, damit Benutzer herausfinden können, welche Artikel konkret betroffen sind. Es sollte auch angegeben werden, welche Versionen und Zeiträume betroffen sind.
Das Unternehmen hat erklärt, dass hochgeladene Daten sofort nach der Erstellung des Wikis vernichtet werden. Aber was passiert mit der Datei, wenn der Build fehlschlägt, abgebrochen wird oder eine Zeitüberschreitung auftritt? Ob die hochgeladenen Dateien entschlüsselt wurden, wer darauf zugegriffen hat und ob die Löschung auch die Cloud-Snapshots und Backups betrifft, bedarf weiterer Erläuterungen. Es besteht die Hoffnung, dass das Unternehmen betroffenen Benutzern spezifische Verarbeitungsaufzeichnungen zur Verfügung stellen kann, damit Benutzer überprüfen können, ob ihre Dateien wie versprochen gelöscht wurden.
Am 20. September, etwa zwei Tage nachdem ZCode versprochen hatte, Open Source zu sein, wurde der Client-Quellcode noch nicht im öffentlichen Lager von Z.ai gefunden.
Wenn es in Zukunft als Open Source verfügbar ist, muss die Außenwelt die betreffende Version oder die entsprechenden Änderungsdatensätze sehen.
Wenn man sich nur den reparierten Code ansieht, ist nicht klar, warum der Upload zuvor ausgelöst wurde und welche Dateien gesammelt wurden.
ZCode verspricht außerdem die Einführung einer Überprüfung durch Dritte. Die Überprüfungspartei, der Umfang und der Zeitplan bedürfen weiterer Erläuterungen.
Hoffentlich überprüft diese Überprüfung sowohl den Client-Code als auch die Serverprotokollierung. Relevante Bearbeitungs-, Zugriffs- und Löschprotokolle können dem Prüfer ohne Offenlegung des Benutzercodes zur Einsicht übergeben werden; Die Ergebnisse der Überprüfung sollten den betroffenen Benutzern mitgeteilt werden.
Kommentare