Data yang Dikirim xAI Grok Build CLI ke xAI: Analisis Tingkat Wire

 (gist.github.com/cereblab)
1 poin oleh GN⁺ 4 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Hasil penangkapan langsung trafik jaringan grok 0.2.93 menunjukkan bahwa Grok Build mengirim file yang dibacanya tanpa masking dan menyimpannya sebagai session_state, serta menyertakan nilai rahasia .env untuk pengujian apa adanya di dua jalur
  • Terpisah dari permintaan model yang mengirim file yang dibaca agen, seluruh repositori yang berisi semua file yang dilacak dan riwayat Git diunggah sebagai git bundle, dan file yang telah ditentukan untuk tidak dibuka pun dipulihkan kembali dalam bentuk aslinya
  • Pada repositori berisi file acak 12GB, total permintaan /v1/responses hanya 192KB, tetapi volume transfer /v1/storage mencapai 5.10GiB hingga penangkapan dihentikan, selisih sekitar 27.800 kali, dan semua permintaan penyimpanan mengembalikan HTTP 200
  • Tujuan unggahan adalah bucket Google Cloud Storage grok-code-session-traces, dan meskipun “Improve the model” dimatikan, trace_upload_enabled: true dan upload_enabled: true tetap dipertahankan sehingga unggahan seluruh repositori terus berlangsung
  • Eksperimen ini membuktikan transmisi, penerimaan, dan penyimpanan data, tetapi tidak dapat memastikan apakah data tersebut digunakan untuk pelatihan model, dan karena file .gitignore serta semua kombinasi akun dan pengaturan tidak diuji, hasilnya terbatas pada versi tertentu pada Juli 2026

Objek uji dan cakupan analisis

  • Targetnya adalah Grok Build CLI resmi xAI yang login dengan akun konsumen biasa
    • Jalur instalasinya adalah ~/.grok/bin/grok
    • Autentikasi dilakukan di browser dengan akun X atau SuperGrok, tanpa menggunakan API key
    • Biner yang diuji adalah grok 0.2.93 (f00f96316d4b) untuk Apple Silicon
    • SHA-256-nya adalah 2a97ba675bd992aa9b981e2e83776460d94f469b510c0b8efe28b50d236d767c
  • Dari string biner, terkonfirmasi adanya komponen unggahan Rust internal dan konstanta terkait penyimpanan
    • crates/codegen/xai-data-collector/src/gcs.rs
    • storage_client.rs, queue.rs, file_access_tracker.rs, circuit_breaker_observer.rs
    • xai-grok-shell/src/upload/{gcs,turn,trace,manifest}.rs
    • grok-code-session-traces, storage.googleapis.com, Uploading bytes to GCS via proxy
  • Semua penangkapan hanya menargetkan komputer dan trafik milik penguji, dan repositori diisi string canary unik alih-alih kredensial sungguhan

Cara reproduksi dan penangkapan trafik

  • Di macOS Apple Silicon, CA mitmproxy ditambahkan ke keychain login sebagai sertifikat tepercaya, lalu HTTPS_PROXY dan SSL_CERT_FILE disetel untuk menangkap permintaan HTTPS Grok
  • Dalam konfigurasi ini, Grok tidak memblokir penangkapan dengan certificate pinning
  • Dengan add-on mitmdump, dicatat metode, host, path, status respons, dan ukuran byte permintaan per request, lalu body permintaan yang menuju host xAI disimpan
  • ~/.grok/upload_queue/* disalin saat proses berjalan, lalu dibuka dengan gzip dan tar untuk memeriksa artefak staging yang menunggu dikirim
  • Setiap file diberi marker unik agar asalnya bisa dibedakan, dan file rahasia menggunakan nilai palsu seperti berikut
    • API_KEY=CANARY7F3A9-SECRET-should-not-leave
    • DB_PASSWORD=CANARY7F3A9-DBPASS

Kanal A: pengiriman file yang dibaca dan .env dalam permintaan model

  • Isi file yang dibaca Grok diserialisasikan ke dalam body giliran model pada POST cli-chat-proxy.grok.com/v1/responses
    • Permintaan yang ditangkap berukuran 48.070 byte berisi "model":"grok-4.5" dan array pesan
    • Canary API_KEY dan DB_PASSWORD dari .env ditemukan apa adanya, termasuk newline
    • Enam marker, termasuk source, logic, README, file JavaScript bertingkat, dan dua nilai rahasia, bisa dipulihkan dari body permintaan
  • Isi yang sama juga masuk ke arsip session_state dan diunggah ke POST /v1/storage, dan permintaan penyimpanan tersebut diterima dengan HTTP 200
    • Setelah arsip terkompresi dibuka dan diperiksa, kedua nilai rahasia dan marker file lain semuanya ditemukan
    • Nilai rahasia bukan hanya diproses sementara oleh model, tetapi juga dicatat dalam arsip untuk penyimpanan
  • Pada prompt kontrol Reply exactly OK, do not read any files, marker dari untouched_secret.txt yang tidak dibuka tidak muncul di body /v1/responses
    • Ini hanya membuktikan bahwa kanal permintaan model berpusat pada file yang benar-benar dibaca agen
    • Karena kanal snapshot seluruh repositori yang terpisah juga mencakup file yang tidak dibaca, hasil kontrol ini tidak menafikan unggahan seluruh repositori
  • Nilai rahasia berada di .env atau secrets.env dan merupakan file yang dilacak Git
    • Apakah file yang masuk .gitignore juga diunggah tidak diuji secara terpisah
    • Karena canary bukan format token berentropi tinggi yang nyata, ini tidak membuktikan sampai pada tingkat bahwa tidak ada mekanisme masking khusus sama sekali untuk pola tertentu seperti sk-…
    • Yang terkonfirmasi adalah bahwa isi .env yang diuji ditransmisikan tanpa masking

Kanal B: unggahan seluruh repositori, termasuk file yang tidak dibaca

  • Terpisah dari /v1/responses yang mengirim file yang dibaca model, /v1/storage mengunggah snapshot seluruh workspace
  • Pada repositori nyata cereblab_api, eksekusi dilakukan setelah instruksi Reply with exactly: OK. Do not read or open any files.
    • Grok mengirim git bundle 152.102 byte ke POST /v1/storage dan server mengembalikan HTTP 200
    • Ketika uploaded_repo.bundle hasil tangkapan di-git clone, src/_probe/never_read_canary.txt yang telah ditentukan agar tidak dibuka berhasil dipulihkan
    • Marker CANARY-XR47P2-NEVERREAD-UNIQUE di dalam file juga tetap utuh
    • Bundle itu berisi 4 commit, 47 file, dan seluruh riwayat Git
  • Hasil yang sama direproduksi pada repositori independen kedua, cereblab_auth
    • Git bundle 31.743 byte diunggah melalui POST /v1/storage dan mengembalikan HTTP 200
    • Pada repositori yang dipulihkan, marker CANARY-AUTH-4T8K2-NEVERREAD dari file yang tidak dibaca terkonfirmasi apa adanya
  • Pada eksekusi cereblab_api terpisah dengan 298 file, manifest yang di-staging juga mencantumkan file yang tidak dibaca
    • src/_probe/never_read_canary.txt tercatat bersama source nyata seperti src/apns.ts dan src/index.ts
    • fileId per file di metadata.json berbentuk gs://grok-code-session-traces/repo_changes_dedup/v2/supplemental/sha256_…
    • Eksekusi ini tidak sampai menyelesaikan pengiriman content blob karena terhalang kuota, tetapi unggahan nyata telah terkonfirmasi dalam eksperimen git bundle terpisah dan eksperimen 12GB
  • String seperti after_codebase.tar.gz, repo_state.upload, collecting workspace files, dan spawning background coordinator juga terdapat di biner, selaras dengan mekanisme pengumpulan workspace

Transfer multi-GiB yang terkonfirmasi pada repositori 12GB

  • Perilaku unggahan diamati sambil memperbesar ukuran repositori dengan file acak yang hampir tidak bisa dikompresi
    • Pada 64MB, satu POST /v1/storage sekitar 48MB mengembalikan HTTP 200, tetapi log tidak berhasil disimpan
    • Pada sekitar 600MB, puluhan chunk sekitar 7,5MB semuanya mengembalikan HTTP 200, tetapi log tidak tersisa
    • Pada sekitar 3GB, setelah inisialisasi multipart, teramati PUT 50MB ke storage.googleapis.com, tetapi log PUT langsung tidak tersimpan
    • Pada sekitar 12GB, chunk sekitar 75MB terus dikirim ke /v1/storage, dan penangkapan dihentikan pada titik 5.10GiB
  • wire_12gb.log yang dipertahankan berisi total 83 respons HTTP 200 untuk /v1/storage*
    • 82 POST /v1/storage untuk unggahan konten
    • Di antaranya 73 chunk sekitar 75MB
    • Total 73 chunk itu adalah 5,476,083,317B, yaitu 5.10GiB atau 5.48GB
    • Termasuk juga 9 POST kecil dan 1 pemeriksaan duplikasi /v1/storage/batch_exists
    • Total byte permintaan /v1/storage* adalah 5,476,228,005B, dan tidak ada permintaan penyimpanan yang gagal
  • Karena penangkapan dihentikan saat unggahan masih berlangsung, ini tidak membuktikan bahwa unggahan penuh 12GB selesai
    • Catatan terakhir juga merupakan HTTP 200 untuk chunk sekitar 75MB
    • Yang terbukti adalah bahwa lebih dari 5.10GiB telah ditransmisikan tanpa gagal dan volumenya masih terus bertambah saat dihentikan
  • Terdapat perbedaan kapasitas besar antara dua kanal dalam sesi yang sama
    • /v1/responses dari 5 permintaan total berukuran 196,705B, sekitar 192KB, dan permintaan terbesarnya pun hanya 60.394B
    • /v1/storage mencapai 5.10GiB
    • Terjadi selisih sekitar 27.800 kali, menunjukkan bahwa data repositori dalam jumlah besar yang tidak masuk ke permintaan model dipindahkan melalui kanal penyimpanan terpisah
  • Error kuota model dan unggahan penyimpanan terjadi secara independen
    • Pada /v1/responses, terjadi HTTP 402 satu kali dan 429 tiga kali
    • Pada permintaan bookkeeping sesi, terjadi 404 sekali yang tidak terkait
    • Bahkan setelah 429 pertama, /v1/storage HTTP 200 masih berlanjut 76 kali
    • Semua 82 permintaan penyimpanan berhasil, dan dalam cakupan pengujian tidak terjadi error batas kapasitas penyimpanan
  • Hasil ini tidak bergantung pada fenomena upload_queue lokal yang menjadi kosong
    • Queue bisa kosong baik setelah unggahan sukses maupun setelah dibuang, sehingga tidak digunakan sebagai bukti
    • Dasarnya adalah body permintaan yang benar-benar keluar ke jaringan, menerima HTTP 200, serta hasil pemulihan file dari git bundle yang diunggah

Lokasi penyimpanan dan telemetri

  • Tujuan penyimpanan terkonfirmasi sebagai bucket Google Cloud Storage grok-code-session-traces, bukan AWS S3
    • Biner memuat grok-code-session-traces, storage.googleapis.com, dan Uploading bytes to GCS via proxy
    • Tujuan file di metadata.json yang dipertahankan tercatat sebagai gs://grok-code-session-traces/…
    • Pada eksperimen sekitar 3GB, multipart PUT langsung ke host GCS tersebut juga diamati, meski lognya tidak tersimpan
    • Meskipun aws-sdk-s3 ada di biner, tujuan yang terkonfirmasi dalam pengujian adalah GCS
  • Permintaan telemetri pihak ketiga maupun milik sendiri juga terkonfirmasi
    • api.mixpanel.com/track dan /engage milik Mixpanel
    • grok.com/_data/v1/events
    • Semua permintaan tersebut mengembalikan HTTP 200
  • Pada skrip instalasi CLI dan materi quickstart yang ditinjau, tidak ditemukan unggahan repo_state, session_state, ~/.grok/upload_queue, atau grok-code-session-traces
    • Karena tidak semua dokumen dan bantuan xAI diselidiki, tidak bisa dipastikan bahwa hal itu tidak didokumentasikan di mana pun
    • Yang bisa dipastikan hanya bahwa hal tersebut tidak tampak dalam materi pengaturan CLI itu sendiri
  • ~/.grok/upload_queue dapat men-stage snapshot sekitar 3GB dalam satu turn, dan saat beban tinggi bisa bertambah hingga puluhan GB sampai menghabiskan disk
    • Ini adalah masalah reliabilitas yang terpisah dari persoalan privasi unggahan

Pengaturan “Improve the model” dan cakupan kebijakan

  • Bagi coding agent berbasis cloud, mengirim konteks kode yang diperlukan untuk pekerjaan ke server itu sendiri merupakan perilaku yang diperlukan
  • Perilaku yang terkonfirmasi dalam pengujian dapat dibagi menjadi tiga poin berikut
    • Mengirim file rahasia seperti .env tanpa masking
    • Menyimpan isi tersebut di bucket GCS yang disebutkan
    • Unggahan seluruh repositori aktif secara default tanpa terlihat pada materi pengaturan CLI yang ditinjau
  • Kebijakan konsumen xAI membahas secara luas penggunaan data untuk peningkatan model dan opt-out, dengan Private Chat otomatis opt-out dan opt-out tidak berlaku surut
    • Dokumen terkait adalah xAI Privacy Policy dan Consumer ToS
    • Kebijakan pelatihan umum seperti ini tidak sama dengan mendokumentasikan pipeline unggahan repo_state dan GCS tertentu

  • Unggahan tidak berhenti meski “Improve the model” dimatikan

    • Bahkan ketika pengaturan dimatikan, seluruh repositori tetap diunggah sebagai git bundle ke /v1/storage dan mengembalikan HTTP 200
    • File yang tidak dibaca dan riwayat Git dapat dipulihkan dengan git clone
    • Pada /v1/settings yang diterima CLI, "trace_upload_enabled": true, "upload_enabled": true, dan "session_registry_enabled": true tetap dipertahankan
    • Batas 1GiB per file juga dikembalikan sebagai "max_upload_file_bytes": 1073741824
    • Dalam hasil pengujian, opt-out mengontrol apakah dipakai untuk pelatihan tetapi tidak memblokir perilaku repositori meninggalkan komputer lalu diunggah dan disimpan

Hal yang tidak dibuktikan dan keterbatasan bukti

  • Penangkapan jaringan saja tidak dapat membuktikan bahwa xAI menggunakan data tersebut untuk pelatihan model
    • Yang terkonfirmasi adalah transmisi, penerimaan HTTP 200, arsip untuk penyimpanan, dan tujuan GCS
  • Log PUT langsung storage.googleapis.com/grok-code-session-traces yang diamati pada eksekusi 3GB tertimpa sehingga tidak tersimpan
    • Dasar untuk unggahan multi-GiB adalah log /v1/storage dari eksekusi 12GB yang dipertahankan, serta biner dan metadata yang menyebut bucket tersebut
  • Dari pengujian berdasarkan ukuran, log 64MB, 600MB, dan 3GB tidak tersisa, dan hanya log 12GB yang dipertahankan
  • Karena eksekusi 12GB dihentikan pada sekitar 5.10GiB, tidak dapat dipastikan bahwa seluruh 12GB akan diunggah sampai selesai
  • Tidak semua tier akun dan kombinasi konfigurasi diuji
    • Pada tier gratis, unggahan multi-GiB berhasil
    • Pada SuperGrok, unggahan git bundle juga berhasil meski “Improve the model” dimatikan
    • Dalam pengujian tidak ditemukan pengaturan untuk mematikan unggahan, tetapi tidak diklaim bahwa unggahan pasti tidak bisa dinonaktifkan dalam lingkungan apa pun
  • Pada awalnya sempat disimpulkan keliru, berdasarkan hasil nettop per PID, bahwa blob besar tidak diunggah, namun kesimpulan itu dicabut
    • Proses koordinator unggahan terpisah dan pre-signed PUT yang langsung menuju IP Google bisa luput dari pengukuran berbasis host API atau PID tunggal
    • Penangkapan wire berbasis proxy selanjutnya menggantikan penilaian awal tersebut
  • Hasil ini terbatas pada grok 0.2.93, macOS Apple Silicon, dan lingkungan Juli 2026, dan xAI dapat mengubah perilaku tersebut setelahnya

Bukti utama yang dipertahankan

  • secrets_responses_body.bin: menunjukkan bahwa isi .env disertakan dalam body /v1/responses
  • secrets_session_state.tar.gz: menunjukkan bahwa nilai rahasia yang sama masuk ke arsip untuk /v1/storage
  • wire_12gb.log: mencatat unggahan penyimpanan 5.10GiB, 83 /v1/storage* HTTP 200, 0 kegagalan penyimpanan, dan selisih kapasitas sekitar 27.800 kali antara dua kanal
  • model_limit.txt: mencatat 1 kali 402 dan 3 kali 429 yang terjadi pada permintaan model
  • crate_strings.txt: menyimpan string xai-data-collector, grok-code-session-traces, dan storage.googleapis.com
  • uploaded_repo.bundle: bukti repositori pertama bahwa file yang tidak dibaca dan seluruh riwayat Git dapat dipulihkan dari git bundle yang diunggah
  • uploaded_repo_auth.bundle: bukti bahwa hasil yang sama direproduksi pada repositori independen kedua
  • staged_base_tree_manifest.json: menunjukkan bahwa file yang tidak dibaca dicantumkan dalam manifest snapshot repositori
  • staged_metadata.json: menunjukkan bahwa tujuan file adalah gs://grok-code-session-traces/…
  • gcs_puts.txt adalah placeholder kosong karena gagal mempertahankan PUT GCS langsung, sehingga tidak dapat digunakan sebagai bukti PUT tersebut

Bacaan terkait

1 komentar

 
GN⁺ 4 jam lalu
Komentar Hacker News

  • Selalu pisahkan alat coding dan penyedia LLM, serta batasi izin alat coding dengan sandbox bubblewrap
    Alat hanya bisa membaca direktori proyek yang sedang dikerjakan, .git hanya baca, dan direktori sensitif di-mount sebagai direktori kosong
    Namespace jaringan juga diisolasi sehingga akses internet hanya melalui proxy HTTP pada Unix socket; hanya host penyedia LLM tertentu yang diizinkan, sementara host milik alat itu sendiri diblokir
    Misalnya, untuk Crush akses ke *.openrouter.ai diizinkan, tetapi *.charm.land yang dipakai untuk pembaruan otomatis daftar LLM diblokir. Berkat ini, jauh lebih nyaman menyerahkan semua pekerjaan dalam mode yolo

    • Di bubblewrap, lebih baik mengambil rootfs seperti debian:unstable dari Docker Hub dan menyusunnya sebagai lingkungan distro lengkap di folder terpisah
      Setelah memasang agen AI di dalamnya, buat skrip untuk menjalankan bwrap dengan rootfs distro dibuat hanya-baca, dan /home/user kustom dibuat baca-tulis. File penting di luar direktori yang ditentukan tidak terlihat, dan beberapa agen juga bisa dijalankan tanpa saling melihat
      Untuk memperkuat lebih jauh, bisa memanggil runsc ... do ... milik gVisor dari dalamnya, atau memakai monitor mesin virtual seperti muvm. bwrap bisa dipercaya karena berperan menyusun lingkungan, lalu dikunci dengan alat sandbox terpisah
      Jika konfigurasinya benar, bwrap saja sudah cukup untuk menahan sebagian besar penyerang, dan untuk eskalasi hak akses kemungkinan besar praktis harus memakai zero-day kernel Linux
    • Penasaran pendekatan apa yang dipakai saat mengimplementasikan ini
    • Penasaran apakah penguatan keamanan tambahan seperti ini hanya memberi rasa tenang, atau pernah benar-benar menangkap perilaku berbahaya
      Menurut saya, jika model melakukan tindakan sebodoh itu sampai harus dicegah dengan pembatasan, sejak awal model itu tidak layak dipakai. Saya juga sedang memperkuat lingkungan sendiri, dan tidak bermaksud mengkritik praktiknya itu sendiri

  • Runner agen coding native proprietary seperti claude-code, Codex, dan grok-build berisiko dari sisi privasi karena kita tidak tahu fitur tertutup apa yang akan ditambahkan pada pembaruan berikutnya
    Menggunakan model lewat API di opencode jauh lebih aman, tetapi ada kompromi bahwa sulit mencapai performa sebagus runner native

    • Jika penggunaannya cukup banyak, hanya dengan pemanggilan alat di sisi server pun seluruh codebase bisa direkonstruksi, dan proses ini sulit dideteksi sepenuhnya
      Cara Grok hanya lebih terang-terangan; opencode pun tidak membuat batas keamanan yang nyata, mirip meme memakai Cheetos sebagai gembok
    • Codex bersifat open source
    • Pembaruan otomatis itu sendiri juga masalah besar
      Tidak segera menambal kerentanan eksekusi kode jarak jauh seperti di Windows XP SP1 memang berbahaya, tetapi selama beberapa dekade terakhir saya melihat lebih banyak kerugian akibat pembaruan otomatis daripada kerugian yang mungkin terjadi karena tidak memperbarui
    • Saya memakai agen sendiri, tetapi tidak bisa menanggung risiko akun perusahaan diblokir karena itu

  • Pernyataan bahwa “terlepas dari file yang dibaca agen, ia mengunggah seluruh repositori termasuk isi semua file yang dilacak dan riwayat Git” sangat mengejutkan
    Saya memang sempat menduga Elon mungkin melakukan hal seperti ini demi mengejar ketertinggalan, tetapi ini sangat mengkhawatirkan. Harganya kompetitif dan performa grok-4.5 juga cukup bagus, tetapi justru karena alasan seperti ini saya tidak memilihnya

    • Ini jelas kebocoran data dan seharusnya ilegal
    • Karena hubungan kerja sama dengan Microsoft, saya penasaran apakah OpenAI juga bisa mengakses semua repositori GitHub
    • Pada akhirnya ini adalah perlombaan menuju dasar
    • Saya bahkan ragu mencoba uji coba gratis karena tidak menemukan informasi tentang data apa yang harus dibagikan
    • CLI seperti ini selalu saya jalankan di dalam sandbox yang membatasi direktori yang bisa diakses
      CLI bisa saja tanpa sengaja mengambil kunci SSH atau informasi sensitif lain, dan programmer memang sering melakukan kesalahan semacam ini. Saya tidak ingin menyerahkan keamanan pada apakah “mengunggah semua file yang bisa diakses” itu disengaja atau tidak disengaja

  • Butir pertama, bahwa “model membaca file berisi rahasia di dalam repositori”, pada dasarnya adalah perilaku yang dimaksudkan
    LLM tidak bisa menilai apakah sebuah file berisi rahasia sebelum membacanya. Masalah mendasarnya adalah memberi LLM akses ke file berisi rahasia dalam teks polos, lalu terkejut karena file itu dibaca
    Namun mengunggah seluruh repositori secara otomatis itu konyol. Untuk repositori berukuran beberapa GB, ini akan memakan waktu sangat lama di sebagian koneksi, dan jika tidak ada tujuan lain untuk mengumpulkan semua data, secara umum terlihat tidak masuk akal

  • Karena saya selalu berasumsi bahwa workspace saat ini tempat agen dijalankan setidaknya bisa dikelola bebas oleh agen, perilaku ini tampak seperti sesuatu yang sudah diperkirakan
    Sebagian besar agen membaca kode dan bahkan rahasia di dalamnya pada prompt pertama. Jika server memanfaatkannya untuk mengurangi waktu bolak-balik prompt dan pemanggilan alat, saya bertanya-tanya bukankah itu justru menguntungkan pengguna

    • Saat membaca file dan menyampaikan respons, API pesan biasa digunakan
      Namun di sini ditemukan endpoint terpisah yang mengekstrak seluruh folder proyek ke bucket penyimpanan GCP. Siapa pun yang pernah merancang sistem terdistribusi skala besar akan tahu bahwa ini adalah struktur untuk mengumpulkan data pelatihan
    • Setahu saya Cursor melakukan semacam pengindeksan secara lokal
      Tanpa mengunggah semua file, ia bisa memakai pencarian untuk menemukan bagian yang relevan dan mengirimkannya agar dapat digunakan model

  • Akan lebih baik jika ringkasannya ditulis manusia, tetapi isinya sendiri meresahkan

    • Artikel ini sebenarnya cukup dengan beberapa blok kode yang menunjukkan apa yang diunggah dan 2–3 paragraf
      Laporan yang ditulis AI terlalu berat dibaca, jadi setelah memindainya sekitar 10 detik saya kehilangan minat
    • Setidaknya manusia bisa mengolahnya beberapa kali lagi bersama LLM untuk memperbaiki gaya penulisan

  • Penasaran apakah konten yang dicuri akan masuk ke proyek Macrohard yang “mengotomatiskan semua bisnis” atau ke “everything app”
    Tampaknya seperti gagasan bahwa tidak perlu membuat semuanya sendiri kalau bisa mencurinya

    • Puncaknya adalah pengguna bahkan membayar untuk menikmati privilese seperti ini
      Jika menjalankan perusahaan seperti ini tanpa moralitas, mereka akan berusaha mencuri sebanyak mungkin sebelum skala penipuannya terungkap dan regulasi menghentikannya. Bukan berarti mereka benar-benar melakukannya, tetapi insentif ekonominya memang sejajar persis ke arah itu

  • Agen AI harus dianggap dapat membaca file di direktori tempat runner dijalankan
    Dalam kebanyakan kasus, pada prompt pertama ia akan membaca kode beserta informasi rahasia di dalamnya, dan karena .env ditujukan untuk lingkungan lokal, file itu tidak boleh berisi rahasia sungguhan. Instruksi kepada agen AI tidak bisa dipercaya, jadi rahasia yang sebenarnya harus diisolasi darinya
    Jika menerima asumsi ini, menyimpan kode di server mungkin lebih baik daripada mengirimkannya sebagai konteks setiap kali

    • Karena cara kerja LLM, pada akhirnya kode tetap harus dikirim ulang melalui konteks
      Menurut saya satu-satunya alasan untuk melakukan unggahan terpisah seperti ini adalah agar Musk bisa memperoleh data pelatihan yang bersih untuk model berikutnya, seperti struktur proyek, pustaka populer, dan alur kerja CI
    • Sekalipun diunggah sekali, kode itu tetap masuk ke proses inferensi; yang dihemat hanya sedikit trafik HTTP
    • Inti persoalannya tidak terlalu besar. Mungkin Grok sekitar 10% lebih agresif dalam menyusun konteks dibanding penyedia lain, atau mungkin cara ini sekadar memungkinkan mereka merilis lebih cepat
      Semua penyedia punya kemampuan dan insentif untuk melakukan hal yang sama jika itu membantu meningkatkan hasil
      Perbedaan sebenarnya adalah mereka mengirim file rahasia seperti .env tanpa menyaringnya, tidak hanya memprosesnya sementara tetapi menyimpannya di bucket GCS bernama tertentu, serta mengaktifkannya secara default tanpa memberi tahu mekanisme unggahnya di dokumentasi konfigurasi CLI
      Jangan menaruh .env yang tidak terenkripsi di path yang dapat diakses. Akan lebih baik jika Grok mengenali dan mengabaikan informasi rahasia, tetapi pengguna tidak boleh bergantung pada perilaku seperti itu

  • Fakta bahwa seluruh repositori diunggah dengan cara yang sama terlepas dari apakah pengaturan “Improve the model” dinyalakan atau dimatikan sangat serius
    Sebagian besar perusahaan AI mungkin juga melakukan hal serupa di runner mereka sendiri jika pengguna menyetujui pengumpulan data, tetapi tetap mengunggah meski sudah dinonaktifkan secara eksplisit adalah tindakan jahat

  • Dengan mengunggah seluruh codebase, model bisa menelusuri kode saat sedang “berpikir” tanpa perlu meminta pemanggilan alat nyata ke klien
    Tidak jelas apa kerugian dari meminta kembali ke klien, jadi ini bukan alasan yang sangat kuat, tetapi ini pembenaran terbaik yang bisa dibayangkan

    • Tujuan sebenarnya tampaknya lebih dekat pada mencuri rahasia dagang, desain aplikasi, dan pengetahuan kerja internal, atau menyalin kode, aplikasi, alat, dan prosedur
      Kode yang tadinya privat kini menjadi kode mereka
    • Bisa jadi ini dimaksudkan agar saat komputer sedang offline, pengguna tetap bisa mengendalikan dari jarak jauh melalui kontainer di suatu tempat lewat ponsel, lalu nanti kembali ke pengembangan lokal dan menyinkronkan perubahan dari bucket GCP
      Itu cukup berguna, tetapi tidak cukup berguna sampai harus menyerahkan seluruh repositori kepada Elon. Fakta bahwa mereka membuatnya tidak bisa ditolak dan sama sekali tidak mengungkapkannya semakin menguatkan penilaian bahwa data ini tidak layak dipercayakan kepada mereka