Abstract:
ZCode, Zhipu’s AI programming tool, has been questioned for its background packaging and uploading of user projects.
Developers discovered that not only the current code was packaged, but also the Git history that saved previous modifications. On September 18, developer ferstar disclosed his troubleshooting results: ZCode generated a copy of the project on this machine and repeatedly tried to upload it. Subsequently, other users also provided review records. Some found that the copy of the project had been accepted by the server, and some questioned whether the warehouse index switch could prevent the upload. Users therefore asked: Why does the software collect this content, and how to prevent it from uploading?
ZCode apologized that day and attributed the problem to the "code base index" related functions that were turned on by default in the early days. The company said that Repo Wiki may trigger data upload when generating a warehouse encyclopedia in the cloud, and the relevant data will be destroyed immediately after generation. It also promised to open source the client and introduce third-party review.
On September 19, ZCode released 3.14.0, and the update log stated: "Fixed the problem of abnormal upload of warehouse encyclopedia." Ferstar also supplemented the review results, saying that the relevant upload code has been removed in the new version.
After it is open sourced, outsiders can check why the software was uploaded and what changes were made this time. However, the company still needs to provide receipt and processing records of which files the server has previously received and whether they have been deleted as promised.
If the third-party review only looks at the client, it will not be able to answer users’ questions about this batch of historical data.
1. Clean the disk and found a copy of the project
ferstar was not initially checking upload behavior. When he was cleaning up his computer disk, he found that ZCode's data directory took up a lot of space, and after digging down, he found a 313MB encrypted file. It is a snapshot generated by the software for the project, which is equivalent to packaging a batch of project files into a copy.
The list saved with the snapshot lists 42411 files. Calculated by file volume, approximately 86.6% of them come from the .git directory that saves version records, including Git historical objects, operation logs, and LFS large file cache.
Where are these documents going to be sent? ferstar continued to check the client code and found an upload process: the software first applied for an upload certificate to the ZCode server, then packaged and encrypted the file, sent the file to Alibaba Cloud's OSS cloud storage service, and finally the cloud notified the ZCode server to register and receive the result.
However, the 313MB file was attempted to be uploaded 564 times, but failed each time and remained on the local machine waiting for retry.
Ferstar specifically clarified this in the update on September 19, and also added: His other smaller public warehouse snapshot, the status has shown that the server has accepted it.Developer Vonng then reviewed it on the macOS version of ZCode 3.12.3. He found a snapshot of the ordinary workspace that did not contain .git, and the record showed that it had been accepted by the server; in the other two snapshots, .git accounted for 93.9% and 98.5% of the total file volume. The client had obtained the upload credentials, but public records could not confirm whether they had completed the upload.
ZCode has also received relevant reports in the feedback area on GitHub. The submitter of Issue #707 said that he found a list of snapshots accepted by the server, which contained more than two thousand .git paths. He also reflected that the snapshot will come with global configurations such as connection information, automatic execution scripts and command files set by the user for the AI tool. His judgment is based on local records, and there are no server-side audit results to verify.
2. Deleted code may also be followed
The recurring Git history in these lists is what worries users.
Git allows developers to retrieve old versions of code, which also means that content deleted today may not have disappeared from the warehouse.
Keys, configuration files or internal addresses that have been submitted by mistake may be retained in historical objects.
GitHub's security documentation also reminds that only deleting sensitive information in the latest version of the code will not clear the copy in Git history.
There may still be local submissions that have not yet been pushed in Git. The submission record contains the author's email address, and the large file cache may retain materials that have been used in the project before. ZCode needs to explain why it needs to upload this content to help users complete the task at hand.
The above samples cannot prove that the real key has been leaked.
For those who have opened the internal warehouse in ZCode, they need to know which versions and periods of time were affected so that they can go back and check the historical content that may have been packaged.ZCode’s privacy policy states that in order to provide content generation and AI-assisted operations, files and codes “submitted and specified” by users in conversations will be collected. However, when the software packages Git history in the background, the existing product description does not make it clear whether the user knows and agrees.
Even if the file is encrypted, users have reasons to ask: before uploading, clearly explain what will be uploaded, and then let them decide whether to agree.
As for whether the files are used to train models, the same policy states that the "Optimization Plan" is turned off by default, and input, generated content or product usage data will not be used for product and model training and optimization until users actively join.
Existing public materials do not show that these warehouse data entered the training process.
But for companies, merely promising not to use code for training is not enough to respond to this challenge. The storage, access and destruction of files after they are uploaded also require processing records that can be verified by users.
3. Close indexing, can you turn off uploading
If the user does not want these background snapshots to leave the computer, it is not enough to know that the "Optimization Plan" is turned off by default. They also need an option to control the upload.
According to ZCode's introduction, the upload behavior is related to the "code base index". This feature is used to locally generate warehouse indexes and supports session checkpoint recovery, historical version rollback and Repo Wiki. The first two items help users restore project status, while Warehouse Encyclopedia is responsible for analyzing the project structure and generating documentation.
Judging from the developer restoration process, ZCode originally had a warehouse upload function. The description on September 18 attributed the problem to related functions that were turned on by default in the early stage, but did not elaborate on whether this fix adjusted the upload conditions, file collection range, or the control logic of setting switches. It is not clear what data are required for several functions: which files are only used for local recovery and which ones are transferred to the cloud. Why are Git history, large file cache and global configuration reflected by users included?
ferstar said that in the 3.12.3 version he checked, after turning off "Optimize Experience" and "Warehouse Snapshot Index", the background will still package and try to upload.
The submitter of Issue #707 said that after closing the warehouse snapshot index, he found a record of the server accepting snapshots on his local machine. It needs to be checked whether the upload occurs before or after the off switch.
Whether this option controls local indexing or cloud upload requires ZCode's explanation.
Community developers have also placed restrictions on the client. The project zcode-webui adds four layers of protection during official runtime, which respectively intercept snapshot credential application, upload, read and save locally. These interceptions are to prevent further uploads. What has been transmitted in the past and what the server has done still needs to be investigated separately.
When ferstar reviewed version 3.14.0, it said that the code and background components responsible for uploading had been removed, and local checkpoints were still retained; the interface for applying for upload credentials also returned 404.
He checked the above version and interface. Whether other platforms have also been repaired, whether old clients can continue to upload, and when the repair on the server will take effect still requires official explanation.
4. What else needs to be investigated after repair
After the repair version is launched, what users want to confirm most is whether their projects have been transferred. ZCode's privacy policy has provided an email address for querying and deleting personal information. We hope the company will clarify whether this channel can handle inquiries about this abnormal upload, so that users can find out the specific affected items. Which versions and time periods are affected should also be stated.
The company has stated that uploaded data will be destroyed immediately after the Wiki is generated. But what happens to the file if the build fails, is canceled, or times out? Whether the uploaded files have been decrypted, who has accessed them, and whether the deletion will cover the cloud snapshots and backups need further explanation. It is hoped that the company can provide specific processing records to affected users so that users can check whether their files have been deleted as promised.
As of September 20, about two days after ZCode promised to be open source, the client source code has not yet been found in Z.ai’s public warehouse.
When it is open sourced in the future, the outside world needs to see the version in question or the corresponding modification records.
Only looking at the repaired code, it is not clear why the upload was triggered before and what files were collected.
ZCode also promises to introduce third-party review. The review party, scope and time schedule need further explanation.
Hopefully this review will check both client code and server logging. Relevant processing, access and deletion records can be handed over to the reviewer for inspection without disclosing the user code; the results of the review should be notified to the affected users.
Comments