A Chinese developer using the pseudonym Ferstar discovered a large encrypted file in ZCode’s local directory on Friday, revealing that the platform had prepared a 313MB archive for upload to Alibaba’s cloud storage. The file had failed to upload 564 times, while a smaller version had already been successfully transmitted. The archive contained a snapshot of user workspace data, encrypted in such a way that only Z.ai could decrypt and access it. This encryption method means that even if the file were deleted from local systems, only Z.ai could verify whether the deletion actually occurred, raising concerns about transparency and user control over personal data.
The discovery highlights a technical design where user data is encrypted client-side before transmission, but with keys held exclusively by Z.ai. Ferstar’s investigation showed that the encryption prevented any third party, including the user, from verifying the contents or confirming deletion. Minxiao Chang and Wency Chen of the South China Morning Post reported on the findings, noting that the failed upload attempts suggested possible network or system issues, though the encrypted nature of the file made diagnostics difficult. The smaller file that succeeded in uploading may have contained partial or test data, but its contents remain inaccessible to anyone outside Z.ai’s infrastructure.
The encryption model used by Z.ai places full control of data access in the hands of the service provider. While client-side encryption can enhance security against external breaches, it also eliminates user ability to audit or confirm data handling practices. In this case, the inability to open the archive without Z.ai’s keys means users cannot independently verify what data was collected, how it was used, or whether deletion requests were honored. This creates a scenario where claims of data deletion can only be validated by the company itself, undermining trust and complicating regulatory compliance efforts, particularly under frameworks requiring verifiable data erasure.
The core issue lies in the asymmetry of information: Z.ai holds both the encrypted data and the means to decrypt it, while users are left with no tools to confirm compliance with privacy requests. This dynamic shifts the burden of proof entirely onto the platform, requiring users to take deletion assurances on faith. Experts warn that such architectures, while potentially secure from outside threats, may enable opaque data practices if not paired with independent auditing mechanisms or transparent key management policies. Without verifiable deletion, users remain uncertain about the true fate of their data even after requesting its removal.
Why was the file encrypted in a way that only Z.ai could open it? The encryption appears to be part of ZCode’s client-side security design, where data is encrypted before leaving the user’s device. However, the decryption keys are retained solely by Z.ai, preventing users or third parties from accessing the contents without platform cooperation.
What does the 564 failed upload attempts indicate? The repeated failures suggest technical issues during the upload process, possibly related to network stability, server availability, or file transfer protocols. Despite these failures, the system retained the encrypted file locally, ready for retry.
Is it possible for users to delete their data from Z.ai’s systems? Users can initiate deletion requests through the platform’s interface, but due to the encryption key architecture, they cannot independently verify whether the data was fully erased from backups, logs, or storage systems. Only Z.ai can confirm deletion completion.