要約:
Zhipu の AI プログラミング ツールである ZCode は、バックグラウンドでのパッケージ化とユーザー プロジェクトのアップロードに関して疑問視されています。
開発者は、現在のコードだけでなく、以前の変更を保存した Git 履歴もパッケージ化されていることを発見しました。 9 月 18 日、開発者の ferstar はトラブルシューティングの結果を明らかにしました。ZCode はこのマシン上でプロジェクトのコピーを生成し、それを繰り返しアップロードしようとしました。その後、他のユーザーからもレビュー記録が提供されました。プロジェクトのコピーがサーバーに受け入れられたことを発見した人もいれば、ウェアハウスのインデックスの切り替えによってアップロードが妨げられるのではないかと疑問を抱いた人もいました。そこでユーザーは、なぜこのソフトウェアがこのコンテンツを収集するのか、またそのアップロードを防ぐにはどうすればよいのか、と尋ねました。
ZCode は同日謝罪し、問題の原因は初期にデフォルトで有効になっていた「コード ベース インデックス」関連機能にあると述べました。同社は、クラウド上でウェアハウス百科事典を生成する際に、Repo Wiki がデータのアップロードをトリガーする可能性があり、関連データは生成直後に破棄されると述べた。また、クライアントをオープンソース化し、第三者によるレビューを導入することも約束した。
9 月 19 日、ZCode は 3.14.0 をリリースし、更新ログには「ウェアハウス エンサイクロペディアの異常なアップロードの問題を修正しました。」と記載されていました。 Ferstar はまた、関連するアップロード コードが新しいバージョンでは削除されたとレビュー結果を補足しました。
オープンソース化されると、部外者はソフトウェアがなぜアップロードされたのか、今回はどのような変更が加えられたのかを確認できるようになります。ただし、同社は、サーバーが以前にどのファイルを受信したか、約束どおりに削除されたかどうかの受信および処理記録を提供する必要があります。
サードパーティのレビューがクライアントのみを調査する場合、この一連の履歴データに関するユーザーの質問に答えることができません。
1.ディスクをクリーンアップすると、プロジェクトのコピーが見つかりました
ferstar は当初、アップロード動作をチェックしていませんでした。彼はコンピュータのディスクをクリーンアップしていたときに、ZCode のデータ ディレクトリが多くのスペースを占めていることに気付き、掘り下げたところ、313MB の暗号化されたファイルを発見しました。これは、プロジェクトのソフトウェアによって生成されるスナップショットであり、プロジェクト ファイルのバッチをコピーにパッケージ化することに相当します。
スナップショットとともに保存されたリストには、42411 個のファイルがリストされています。ファイル量で計算すると、その約 86.6% は、Git 履歴オブジェクト、操作ログ、LFS ラージ ファイル キャッシュなどのバージョン レコードを保存する .git ディレクトリからのものです。
これらの書類はどこに送られますか? ferstar は引き続きクライアント コードをチェックし、アップロード プロセスを発見しました。ソフトウェアはまず ZCode サーバーにアップロード証明書を申請し、次にファイルをパッケージ化して暗号化し、そのファイルを Alibaba Cloud の OSS クラウド ストレージ サービスに送信し、最後にクラウドが ZCode サーバーに登録して結果を受け取るように通知しました。
ただし、313MB ファイルのアップロードは 564 回試行されましたが、毎回失敗し、ローカル マシン上に残り再試行を待機しました。
Ferstar 氏は 9 月 19 日のアップデートでこれを明確にし、次のようにも付け加えました。彼の別の小さな公共倉庫のスナップショット、ステータスはサーバーがそれを受け入れたことを示しています。開発者の Vonng は、ZCode 3.12.3 の macOS バージョンでそれをレビューしました。彼は .git を含まない通常のワークスペースのスナップショットを見つけました。そのレコードは、それがサーバーによって受け入れられたことを示していました。他の 2 つのスナップショットでは、.git が合計ファイル ボリュームの 93.9% と 98.5% を占めていました。クライアントはアップロード資格情報を取得していましたが、公的記録ではアップロードを完了したかどうかを確認できませんでした。
ZCode は、GitHub のフィードバック エリアでも関連レポートを受け取りました。問題 #707 の提出者は、サーバーによって受け入れられたスナップショットのリストを見つけたと述べました。そこには 2,000 を超える .git パスが含まれていました。同氏はまた、スナップショットには接続情報、自動実行スクリプト、AIツール用にユーザーが設定したコマンドファイルなどのグローバル構成が付属することも述べた。彼の判断はローカルの記録に基づいており、検証するサーバー側の監査結果はありません。
2.削除されたコードも追跡できます
これらのリストに繰り返し現れる Git 履歴は、ユーザーを不安にさせます。
Git を使用すると、開発者はコードの古いバージョンを取得できます。これは、今日削除されたコンテンツがウェアハウスから消えていない可能性があることも意味します。
誤って送信されたキー、設定ファイル、または内部アドレスは、履歴オブジェクトに保持される可能性があります。
GitHub のセキュリティ ドキュメントでは、コードの最新バージョンの機密情報を削除するだけでは、Git 履歴のコピーは消去されないことも注意しています。
まだ Git にプッシュされていないローカル送信がまだある可能性があります。提出レコードには作成者の電子メール アドレスが含まれており、大きなファイル キャッシュにはプロジェクトで以前に使用されたマテリアルが保持されている可能性があります。 ZCode は、ユーザーが当面のタスクを完了できるようにするために、なぜこのコンテンツをアップロードする必要があるのかを説明する必要があります。
上記のサンプルでは、実際のキーが漏洩したことを証明することはできません。
ZCode で内部ウェアハウスを開いた人は、パッケージ化された可能性のある履歴コンテンツを遡って確認できるように、影響を受けたバージョンと期間を知る必要があります。ZCode のプライバシー ポリシーには、コンテンツ生成と AI 支援操作を提供するために、会話の中でユーザーによって「送信および指定された」ファイルとコードが収集されると記載されています。ただし、ソフトウェアがバックグラウンドで Git 履歴をパッケージ化する場合、既存の製品説明では、ユーザーが知っていて同意しているかどうかが明確になりません。
ファイルが暗号化されている場合でも、ユーザーには質問する理由があります。アップロードする前に、何がアップロードされるのかを明確に説明し、同意するかどうかを決定してもらいます。
ファイルがモデルのトレーニングに使用されるかどうかについては、同じポリシーで「最適化プラン」がデフォルトでオフになっており、ユーザーが積極的に参加するまで、入力、生成されたコンテンツ、または製品使用データは製品とモデルのトレーニングと最適化に使用されないことが記載されています。
既存の公開資料には、これらのウェアハウス データがトレーニング プロセスに入ったことは示されていません。
しかし、企業にとって、トレーニングにコードを使用しないと約束するだけでは、この課題に対処するには十分ではありません。アップロード後のファイルの保存、アクセス、破棄には、ユーザーが検証できる処理記録も必要です。
3.インデックス作成を閉じてください。アップロードをオフにしていただけますか
ユーザーがこれらのバックグラウンド スナップショットをコンピュータから残したくない場合は、「最適化プラン」がデフォルトでオフになっていることを知っているだけでは十分ではありません。アップロードを制御するオプションも必要です。
ZCode の紹介によると、アップロード動作は「コード ベース インデックス」に関連しています。この機能は、ウェアハウス インデックスをローカルで生成するために使用され、セッション チェックポイントの回復、履歴バージョンのロールバック、および Repo Wiki をサポートします。最初の 2 つの項目はユーザーがプロジェクトのステータスを復元するのに役立ちますが、Warehouse Encyclopedia はプロジェクト構造の分析とドキュメントの生成を担当します。
開発者の復元プロセスから判断すると、ZCode には元々ウェアハウスのアップロード機能がありました。 9月18日の説明では、初期段階でデフォルトでオンになっていた関連機能に問題があるとしているが、今回の修正がアップロード条件やファイルの収集範囲、設定スイッチの制御ロジックなどを調整したのかについては詳しく述べられていない。どのファイルがローカルリカバリのみに使用され、どのファイルがクラウドに転送されるのかなど、いくつかの機能にどのようなデータが必要なのかは明らかではありません。 Git 履歴、大容量ファイル キャッシュ、ユーザーによるグローバル設定が反映されるのはなぜですか?
ferstar 氏によると、彼がチェックしたバージョン 3.12.3 では、「エクスペリエンスの最適化」と「ウェアハウス スナップショット インデックス」をオフにした後でも、バックグラウンドがパッケージ化され、アップロードが試行されるとのことです。
問題 #707 の提出者は、ウェアハウス スナップショット インデックスを閉じた後、ローカル マシン上でスナップショットを受け入れているサーバーの記録を見つけたと述べました。アップロードがオフのスイッチの前に行われたか後に行われたかを確認する必要があります。
このオプションがローカル インデックス作成を制御するかクラウド アップロードを制御するかについては、ZCode の説明が必要です。
コミュニティ開発者もクライアントに制限を設けています。プロジェクト zcode-webui は、公式実行時に 4 つの保護層を追加します。各層は、スナップショット認証情報のアプリケーションをインターセプトし、ローカルでアップロード、読み取り、保存します。これらの傍受は、さらなるアップロードを防ぐためのものです。過去に送信された内容とサーバーが何を行ったかは、個別に調査する必要があります。
ferstar がバージョン 3.14.0 をレビューしたとき、アップロードを担当するコードとバックグラウンド コンポーネントは削除され、ローカル チェックポイントはまだ保持されていると述べました。アップロード資格情報を申請するためのインターフェースも 404 を返しました。
彼は上記のバージョンとインターフェースをチェックしました。他のプラットフォームも修復されたかどうか、古いクライアントが引き続きアップロードできるかどうか、サーバーの修復がいつ有効になるかについては、依然として公式の説明が必要です。
4.修理後に他に調査する必要があること
修復版の公開後、ユーザーが最も確認したいのは、プロジェクトが転送されているかどうかです。 ZCode のプライバシー ポリシーでは、個人情報を照会および削除するための電子メール アドレスが提供されています。同社は、この異常なアップロードに関する問い合わせにこのチャネルが対応できるかどうかを明らかにし、ユーザーが影響を受ける具体的な項目を確認できるようにすることを望んでいます。影響を受けるバージョンと期間も明記する必要があります。
同社は、アップロードされたデータは Wiki の生成後すぐに破棄されると述べています。しかし、ビルドが失敗したり、キャンセルされたり、タイムアウトになったりした場合、ファイルはどうなるでしょうか?アップロードされたファイルが復号化されたかどうか、誰がファイルにアクセスしたか、削除の対象がクラウドのスナップショットとバックアップに及ぶかどうかについては、さらなる説明が必要です。同社が影響を受けるユーザーに特定の処理記録を提供し、ユーザーが自分のファイルが約束通りに削除されたかどうかを確認できるようにすることが期待されている。
ZCode がオープンソースになると約束してから約 2 日後の 9 月 20 日の時点で、クライアントのソース コードは Z.ai の公開倉庫でまだ見つかっていません。
将来オープンソース化されると、外部の人々は問題のバージョンまたは対応する変更記録を確認する必要があります。
修復されたコードだけを見ると、なぜ以前にアップロードがトリガーされたのか、どのファイルが収集されたのかは明らかではありません。
ZCode は、第三者によるレビューを導入することも約束しています。検討団体、範囲、スケジュールについてはさらに説明が必要です。
このレビューでクライアント コードとサーバー ログの両方がチェックされることを願っています。関連する処理、アクセス、および削除の記録は、ユーザー コードを開示することなく検査のためにレビュー担当者に引き渡すことができます。レビューの結果は影響を受けるユーザーに通知される必要があります。
コメント