ข้อมูลที่ xAI Grok Build CLI ส่งไปยัง xAI: การวิเคราะห์ระดับ wire

 (gist.github.com/cereblab)
1 คะแนน โดย GN⁺ 4 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • จากการดักจับทราฟฟิกเครือข่ายของ grok 0.2.93 โดยตรง พบว่า Grok Build ส่งไฟล์ที่อ่านไปแบบ ไม่มาสก์ข้อมูล และบันทึกเป็น session_state โดยค่าลับใน .env สำหรับทดสอบก็ถูกรวมไว้ตามเดิมในทั้งสองเส้นทาง
  • นอกเหนือจากคำขอไปยังโมเดลที่ส่งไฟล์ที่เอเจนต์อ่านไปแล้ว ยังมีการอัปโหลดทั้ง repository ในรูปแบบ git bundle ซึ่งมี ไฟล์ trace ทั้งหมดและประวัติ Git และไฟล์ที่ระบุว่าไม่ให้เปิดก็สามารถกู้คืนเป็นต้นฉบับได้ครบถ้วน
  • ใน repository ที่มีไฟล์สุ่มขนาด 12GB คำขอ /v1/responses มีขนาดรวม 192KB แต่ปริมาณการส่งไปยัง /v1/storage สูงถึง 5.10GiB ณ เวลาที่หยุดดักจับ ต่างกันประมาณ 27,800 เท่า และคำขอ storage ทั้งหมดตอบกลับ HTTP 200
  • ปลายทางอัปโหลดคือบัคเก็ต grok-code-session-traces บน Google Cloud Storage และแม้ปิด “Improve the model” แล้ว trace_upload_enabled: true กับ upload_enabled: true ก็ยังคงอยู่ ทำให้การอัปโหลดทั้ง repository ดำเนินต่อไป
  • การทดลองพิสูจน์ได้ว่ามีการส่ง การยอมรับ และการจัดเก็บข้อมูล แต่ ไม่สามารถยืนยันได้ว่าถูกใช้ฝึกโมเดลหรือไม่ และไม่ได้ทดสอบไฟล์ใน .gitignore รวมถึงบัญชีและการตั้งค่าทุกแบบ ดังนั้นผลลัพธ์จำกัดอยู่ที่เวอร์ชันเฉพาะในเดือนกรกฎาคม 2026

เป้าหมายการทดสอบและขอบเขตการวิเคราะห์

  • เป้าหมายคือ Grok Build CLI อย่างเป็นทางการของ xAI ที่ล็อกอินด้วยบัญชีผู้ใช้ทั่วไป
    • พาธติดตั้งคือ ~/.grok/bin/grok
    • ยืนยันตัวตนผ่านเบราว์เซอร์ด้วยบัญชี X หรือ SuperGrok และไม่ได้ใช้ API key
    • ไบนารีที่ทดสอบคือ grok 0.2.93 (f00f96316d4b) สำหรับ Apple Silicon
    • SHA-256 คือ 2a97ba675bd992aa9b981e2e83776460d94f469b510c0b8efe28b50d236d767c
  • จากสตริงในไบนารี พบ คอมโพเนนต์อัปโหลด Rust ภายใน และค่าคงที่เกี่ยวกับ repository
    • 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
  • การดักจับทั้งหมดทำเฉพาะกับคอมพิวเตอร์และทราฟฟิกของผู้ทดสอบ และใน repository ใส่ สตริง canary ที่ไม่ซ้ำกัน แทนข้อมูลรับรองจริง

วิธีทำซ้ำและดักจับทราฟฟิก

  • บน macOS Apple Silicon เพิ่ม CA ของ mitmproxy เป็นใบรับรองที่เชื่อถือใน login keychain แล้วตั้งค่า HTTPS_PROXY และ SSL_CERT_FILE เพื่อดักจับคำขอ HTTPS ของ Grok
  • ในการตั้งค่านี้ Grok ไม่ได้บล็อกการดักจับด้วย certificate pinning
  • ใช้แอดออน mitmdump บันทึกเมธอด โฮสต์ พาธ สถานะการตอบกลับ และขนาดไบต์ของคำขอแต่ละรายการ พร้อมบันทึก body ของคำขอที่ส่งไปยังโฮสต์ของ xAI
  • คัดลอก ~/.grok/upload_queue/* ระหว่างรัน แล้วแตกด้วย gzip และ tar เพื่อตรวจสอบ staging artifact ที่รอส่ง
  • แต่ละไฟล์ใส่ marker ที่ไม่ซ้ำกันเพื่อแยกที่มา และไฟล์ลับใช้ค่าปลอมดังนี้
    • API_KEY=CANARY7F3A9-SECRET-should-not-leave
    • DB_PASSWORD=CANARY7F3A9-DBPASS

ช่องทาง A: การส่งไฟล์ที่อ่านและ .env ในคำขอโมเดล

  • เนื้อหาไฟล์ที่ Grok อ่านถูก serialize อยู่ใน body ของ model turn ของ POST cli-chat-proxy.grok.com/v1/responses
    • คำขอขนาด 48,070 ไบต์ที่ดักจับได้มี "model":"grok-4.5" และอาร์เรย์ข้อความ
    • พบ canary ของ API_KEY และ DB_PASSWORD ใน .env ตามต้นฉบับรวมถึง newline
    • สามารถกู้คืน marker 6 รายการจาก body ของคำขอได้ รวมถึงซอร์ส โค้ด logic, README, ไฟล์ JavaScript ที่ซ้อนอยู่ และค่าลับสองค่า
  • เนื้อหาเดียวกันยังถูกใส่ไว้ใน archive ของ session_state และอัปโหลดด้วย POST /v1/storage โดยคำขอจัดเก็บนั้นถูกยอมรับด้วย HTTP 200
    • เมื่อแตก archive ที่บีบอัดออกมาตรวจสอบ พบทั้งค่าลับสองค่าและ marker จากไฟล์อื่นทั้งหมด
    • ค่าลับไม่ได้ถูกประมวลผลชั่วคราวโดยโมเดลเท่านั้น แต่ยังถูกบันทึกไว้ใน archive สำหรับจัดเก็บด้วย
  • ในพรอมป์ควบคุม Reply exactly OK, do not read any files marker ของ untouched_secret.txt ที่ไม่ได้เปิดไม่ปรากฏใน body ของ /v1/responses
    • สิ่งนี้พิสูจน์ได้เพียงขอบเขตว่า channel คำขอโมเดลถูกประกอบขึ้นโดยอิงกับ ไฟล์ที่เอเจนต์อ่านจริง
    • เนื่องจาก channel สแนปช็อตทั้ง repository แยกต่างหากมีไฟล์ที่ไม่ได้อ่านรวมอยู่ด้วย ผลควบคุมนี้จึงไม่ได้หักล้างการอัปโหลดทั้ง repository
  • ค่าลับอยู่ใน .env หรือ secrets.env และเป็นไฟล์ที่ Git ติดตาม
    • ไม่ได้ทดสอบแยกต่างหากว่าไฟล์ที่อยู่ใน .gitignore ถูกอัปโหลดหรือไม่
    • canary ไม่ได้อยู่ในรูปแบบโทเค็น entropy สูงจริง ดังนั้นจึงยังพิสูจน์ไม่ได้ว่าไม่มีระบบมาสก์เฉพาะสำหรับรูปแบบอย่าง sk-… เลย
    • ขอบเขตที่ยืนยันได้คือเนื้อหา .env ที่ทดสอบถูก ส่งออกไปโดยไม่ถูกมาสก์

ช่องทาง B: การอัปโหลดทั้ง repository รวมถึงไฟล์ที่ไม่ได้อ่าน

  • /v1/storage อัปโหลด สแนปช็อตของ workspace ทั้งหมด แยกจาก /v1/responses ที่ส่งไฟล์ที่โมเดลอ่าน
  • รันกับ repository จริง cereblab_api หลังสั่งว่า Reply with exactly: OK. Do not read or open any files.
    • Grok ส่ง git bundle ขนาด 152,102 ไบต์ด้วย POST /v1/storage และเซิร์ฟเวอร์ตอบกลับ HTTP 200
    • เมื่อ git clone ไฟล์ uploaded_repo.bundle ที่ดักจับได้ ไฟล์ src/_probe/never_read_canary.txt ที่ระบุว่าไม่ให้อ่านถูกกู้คืนมาได้
    • marker CANARY-XR47P2-NEVERREAD-UNIQUE ภายในไฟล์ยังคงอยู่ตามต้นฉบับ
    • bundle มี 4 คอมมิต, 47 ไฟล์ และประวัติ Git ทั้งหมด
  • ผลลัพธ์เดียวกันทำซ้ำได้ใน repository อิสระชุดที่สอง cereblab_auth
    • มีการอัปโหลด git bundle ขนาด 31,743 ไบต์ด้วย POST /v1/storage และตอบกลับ HTTP 200
    • ใน repository ที่กู้คืน พบ marker CANARY-AUTH-4T8K2-NEVERREAD ของไฟล์ที่ไม่ได้อ่านตามเดิม
  • ในการรัน cereblab_api อีกชุดหนึ่งที่มี 298 ไฟล์ manifest ที่ถูก staging ระบุรายชื่อไฟล์ที่ไม่ได้อ่านด้วย
    • มีทั้ง src/_probe/never_read_canary.txt และซอร์สจริงอย่าง src/apns.ts, src/index.ts
    • fileId รายไฟล์ใน metadata.json อยู่ในรูปแบบ gs://grok-code-session-traces/repo_changes_dedup/v2/supplemental/sha256_…
    • การรันนี้ติดโควตาก่อนส่ง content blob เสร็จ แต่การอัปโหลดจริงถูกยืนยันจากการทดลอง git bundle แยกต่างหากและการทดลอง 12GB
  • ไบนารียังมีสตริงอย่าง after_codebase.tar.gz, repo_state.upload, collecting workspace files, spawning background coordinator ซึ่งสอดคล้องกับ กลไกเก็บรวบรวม workspace

การส่งข้อมูลหลาย GiB ที่ยืนยันใน repository ขนาด 12GB

  • สังเกตพฤติกรรมอัปโหลดโดยเพิ่มขนาด repository ด้วยไฟล์สุ่มที่แทบไม่สามารถบีบอัดได้
    • ที่ 64MB มี POST /v1/storage เดี่ยวขนาดประมาณ 48MB ตอบกลับ HTTP 200 แต่ไม่ได้เก็บ log ไว้
    • ที่ประมาณ 600MB มี chunk ขนาดประมาณ 7.5MB หลายสิบรายการตอบกลับ HTTP 200 ทั้งหมด แต่ไม่มี log เหลืออยู่
    • ที่ประมาณ 3GB หลังเริ่ม multipart พบการ PUT ไปยัง storage.googleapis.com เป็นช่วงละ 50MB แต่ไม่ได้เก็บ log ของ PUT โดยตรงไว้
    • ที่ประมาณ 12GB มีการส่ง chunk ขนาดประมาณ 75MB ไปยัง /v1/storage ต่อเนื่อง และ หยุดดักจับที่ 5.10GiB
  • wire_12gb.log ที่เก็บไว้มีการตอบกลับ HTTP 200 ของ /v1/storage* รวม 83 รายการ
    • POST /v1/storage สำหรับอัปโหลดคอนเทนต์ 82 รายการ
    • ในจำนวนนี้เป็น chunk ขนาดประมาณ 75MB จำนวน 73 รายการ
    • ผลรวมของ 73 chunk คือ 5,476,083,317B หรือ 5.10GiB / 5.48GB
    • ยังมี POST ขนาดเล็ก 9 รายการ และการตรวจซ้ำ /v1/storage/batch_exists 1 รายการ
    • ไบต์คำขอรวมของ /v1/storage* คือ 5,476,228,005B และไม่มีคำขอ storage ที่ล้มเหลว
  • การดักจับถูกหยุดระหว่างที่การอัปโหลดยังดำเนินอยู่ จึง ไม่ได้พิสูจน์ว่าอัปโหลดครบทั้ง 12GB
    • รายการสุดท้ายที่บันทึกไว้ก็เป็น HTTP 200 สำหรับ chunk ประมาณ 75MB
    • ขอบเขตที่พิสูจน์ได้คือมีการส่งอย่างน้อย 5.10GiB โดยไม่ล้มเหลว และยังเพิ่มขึ้นต่อเนื่อง ณ เวลาที่หยุด
  • ระหว่างสอง channel ใน session เดียวกันมีความต่างของปริมาณข้อมูลมาก
    • /v1/responses มีคำขอ 5 รายการรวม 196,705B หรือประมาณ 192KB และคำขอที่ใหญ่ที่สุดคือ 60,394B
    • /v1/storage มี 5.10GiB
    • เกิดความต่างประมาณ 27,800 เท่า แสดงว่าข้อมูล repository ปริมาณมากที่ไม่ได้อยู่ในคำขอโมเดลถูกย้ายผ่าน channel จัดเก็บแยกต่างหาก
  • ข้อผิดพลาดโควตาโมเดลและการอัปโหลด storage เกิดขึ้นอย่างเป็นอิสระ
    • /v1/responses เกิด HTTP 402 1 ครั้ง และ 429 3 ครั้ง
    • คำขอ bookkeeping ของ session มี 404 ที่ไม่เกี่ยวข้อง 1 ครั้ง
    • หลัง 429 ครั้งแรก ยังมี /v1/storage HTTP 200 ต่อเนื่องอีก 76 ครั้ง
    • คำขอ storage 82 รายการสำเร็จทั้งหมด และในขอบเขตการทดสอบ ไม่พบข้อผิดพลาดเรื่องขีดจำกัดพื้นที่จัดเก็บ
  • ผลลัพธ์นี้ไม่ได้พึ่งพาปรากฏการณ์ที่ upload_queue ภายในเครื่องถูกล้าง
    • queue อาจถูกล้างได้ทั้งเมื่ออัปโหลดสำเร็จและเมื่อถูกทิ้ง จึงไม่ได้ใช้เป็นหลักฐาน
    • หลักฐานคือการดักจับว่า body ของคำขอออกไปบนเครือข่ายจริงและได้รับ HTTP 200 รวมถึงผลการกู้คืนไฟล์จาก git bundle ที่ถูกอัปโหลด

ตำแหน่งจัดเก็บและ telemetry

  • ยืนยันว่าปลายทางจัดเก็บไม่ใช่ AWS S3 แต่เป็นบัคเก็ต grok-code-session-traces บน Google Cloud Storage
    • ไบนารีมี grok-code-session-traces, storage.googleapis.com, Uploading bytes to GCS via proxy
    • ปลายทางไฟล์ใน metadata.json ที่เก็บไว้ถูกบันทึกเป็น gs://grok-code-session-traces/…
    • ในการทดลองประมาณ 3GB ยังพบ multipart PUT โดยตรงไปยังโฮสต์ GCS ดังกล่าว แต่ไม่ได้เก็บ log ไว้
    • แม้ในไบนารีจะมี aws-sdk-s3 แต่ปลายทางที่ยืนยันในการทดสอบคือ GCS
  • ยังพบ คำขอ telemetry ทั้งไปยังบุคคลที่สามและของตัวเอง
    • api.mixpanel.com/track และ /engage ของ Mixpanel
    • grok.com/_data/v1/events
    • คำขอเหล่านี้ทั้งหมดตอบกลับ HTTP 200
  • จากสคริปต์ติดตั้ง CLI และเอกสาร quickstart ที่ตรวจสอบ ไม่พบการอัปโหลด repo_state, session_state, ~/.grok/upload_queue, grok-code-session-traces
    • ไม่ได้ตรวจสอบเอกสารและ help ของ xAI ทั้งหมด จึงไม่อาจสรุปว่าไม่มีการบันทึกไว้ที่ใดเลย
    • ขอบเขตที่ยืนยันได้คือ ไม่ปรากฏในเอกสารตั้งค่าของ CLI เองที่ตรวจสอบได้
  • ~/.grok/upload_queue สามารถ stage สแนปช็อตประมาณ 3GB ได้ในหนึ่ง turn และเมื่อโหลดสูงอาจเพิ่มเป็นหลายสิบ GB จนทำให้ดิสก์เต็มได้
    • นี่เป็น ปัญหาความน่าเชื่อถือ แยกจากปัญหาความเป็นส่วนตัวของการอัปโหลด

การตั้งค่า “Improve the model” และขอบเขตนโยบาย

  • การที่ cloud coding agent ส่งบริบทโค้ดที่จำเป็นสำหรับงานไปยังเซิร์ฟเวอร์นั้นเป็นพฤติกรรมที่จำเป็นในตัวเอง
  • พฤติกรรมที่พบในการทดสอบแยกได้เป็นสามข้อ
    • ส่ง ไฟล์ลับอย่าง .env โดยไม่มาสก์
    • บันทึกเนื้อหาดังกล่าวไว้ในบัคเก็ต GCS ที่ระบุ
    • การอัปโหลดทั้ง repository เปิดใช้งานเป็นค่าเริ่มต้นโดยไม่ปรากฏในเอกสารตั้งค่า CLI ที่ตรวจสอบ
  • นโยบายผู้บริโภคของ xAI กล่าวอย่างกว้างถึงการใช้ข้อมูลเพื่อปรับปรุงโมเดลและการ opt-out โดย Private Chat จะ opt-out อัตโนมัติ และ opt-out ไม่มีผลย้อนหลัง
    • เอกสารที่เกี่ยวข้องคือ xAI Privacy Policy และ Consumer ToS
    • นโยบายการฝึกทั่วไปเหล่านี้ไม่เหมือนกับการจัดทำเอกสาร pipeline อัปโหลด repo_state และ GCS แบบเฉพาะเจาะจง

  • แม้ปิด “Improve the model” การอัปโหลดก็ไม่หยุด

    • เมื่อปิดการตั้งค่าแล้ว ทั้ง repository ยังถูกอัปโหลดเป็น git bundle ไปยัง /v1/storage และตอบกลับ HTTP 200
    • สามารถใช้ git clone กู้คืนไฟล์ที่ไม่ได้อ่านและประวัติ Git ได้
    • /v1/settings ที่ CLI ได้รับยังคงมี "trace_upload_enabled": true, "upload_enabled": true, "session_registry_enabled": true
    • ยังคืนค่า "max_upload_file_bytes": 1073741824 เป็นขีดจำกัด 1GiB ต่อไฟล์
    • จากผลทดสอบ opt-out ควบคุมเรื่องการฝึกหรือไม่ แต่ไม่ได้บล็อกพฤติกรรมที่ repository ออกจากคอมพิวเตอร์ไปถูกอัปโหลดและจัดเก็บ

สิ่งที่ไม่ได้พิสูจน์และข้อจำกัดของหลักฐาน

  • การดักจับเครือข่ายเพียงอย่างเดียว ไม่สามารถพิสูจน์ได้ว่า xAI ใช้ข้อมูลฝึกโมเดล
    • ขอบเขตที่ยืนยันได้คือการส่ง การยอมรับ HTTP 200, archive สำหรับจัดเก็บ และปลายทาง GCS
  • log ของ direct PUT ที่พบใน storage.googleapis.com/grok-code-session-traces ระหว่างการรัน 3GB ถูกเขียนทับและไม่ได้เก็บไว้
    • หลักฐานสำหรับการอัปโหลดหลาย GiB คือ log /v1/storage จากการรัน 12GB ที่เก็บไว้ รวมถึงไบนารีและ metadata ที่ระบุบัคเก็ต
  • ระหว่างทดสอบตามขนาด ไม่มี log ของ 64MB, 600MB, 3GB เหลืออยู่ และ เก็บไว้เฉพาะ log 12GB
  • การรัน 12GB ถูกหยุดที่ประมาณ 5.10GiB จึงสรุปไม่ได้ว่า 12GB ทั้งหมดจะถูกอัปโหลดจนเสร็จ
  • ไม่ได้ทดสอบบัญชีทุกระดับและชุดการตั้งค่าทุกแบบ
    • การอัปโหลดหลาย GiB สำเร็จบน tier ฟรี
    • ใน SuperGrok การอัปโหลด git bundle สำเร็จแม้ปิด “Improve the model”
    • แม้ไม่พบการตั้งค่าปิดอัปโหลดในการทดสอบ แต่ไม่ได้สรุปว่าไม่สามารถปิดได้เลยในทุกสภาพแวดล้อม
  • ช่วงแรกเคยตัดสินผิดจากผล nettop ราย PID ว่าไม่มีการอัปโหลด blob ขนาดใหญ่ และได้ถอนข้อสรุปนั้นแล้ว
    • กระบวนการประสานงานอัปโหลดแยกต่างหากและ presigned PUT ที่มุ่งตรงไปยัง IP ของ Google อาจหลุดจากการวัดตาม API host หรือ PID เดียว
    • หลังจากนั้น การดักจับระดับ proxy wire เข้ามาแทนที่ข้อสรุปเดิม
  • ผลลัพธ์จำกัดอยู่ที่ grok 0.2.93, macOS Apple Silicon และสภาพแวดล้อมเดือนกรกฎาคม 2026 โดย xAI อาจเปลี่ยนพฤติกรรมภายหลังได้

หลักฐานสำคัญที่เก็บไว้

  • secrets_responses_body.bin: แสดงว่า .env ต้นฉบับถูกรวมอยู่ใน body ของ /v1/responses
  • secrets_session_state.tar.gz: แสดงว่าค่าลับเดียวกันอยู่ใน archive สำหรับ /v1/storage
  • wire_12gb.log: บันทึกการอัปโหลด storage 5.10GiB, HTTP 200 จำนวน 83 รายการของ /v1/storage*, storage failure 0 ครั้ง และความต่างปริมาณข้อมูลประมาณ 27,800 เท่าระหว่างสอง channel
  • model_limit.txt: บันทึก 402 จำนวน 1 ครั้ง และ 429 จำนวน 3 ครั้งที่เกิดกับคำขอโมเดล
  • crate_strings.txt: เก็บสตริง xai-data-collector, grok-code-session-traces, storage.googleapis.com
  • uploaded_repo.bundle: หลักฐาน repository แรกที่กู้คืนไฟล์ที่ไม่ได้อ่านและประวัติ Git ทั้งหมดจาก git bundle ที่ถูกอัปโหลด
  • uploaded_repo_auth.bundle: หลักฐานที่ทำซ้ำผลเดียวกันใน repository อิสระชุดที่สอง
  • staged_base_tree_manifest.json: แสดงว่าไฟล์ที่ไม่ได้อ่านถูกระบุใน manifest ของสแนปช็อต repository
  • staged_metadata.json: แสดงว่าปลายทางไฟล์คือ gs://grok-code-session-traces/…
  • gcs_puts.txt เป็น placeholder ว่างเพราะไม่สามารถเก็บ direct GCS PUT ไว้ได้ จึงใช้เป็นหลักฐานของ PUT ดังกล่าวไม่ได้

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 4 시간 전
ความเห็นจาก Hacker News

  • แยกเครื่องมือเขียนโค้ดออกจากผู้ให้บริการ LLM เสมอ และจำกัดสิทธิ์ของเครื่องมือเขียนโค้ดด้วย แซนด์บ็อกซ์ bubblewrap
    เครื่องมือจะอ่านได้เฉพาะไดเรกทอรีโปรเจ็กต์ที่กำลังทำงานอยู่, .git เป็นแบบอ่านอย่างเดียว และเมานต์ไดเรกทอรีที่มีข้อมูลอ่อนไหวเป็นไดเรกทอรีว่าง
    ยังแยก network namespace เพื่อให้เข้าถึงอินเทอร์เน็ตได้ผ่าน HTTP proxy บน Unix socket เท่านั้น และอนุญาตเฉพาะโฮสต์ของผู้ให้บริการ LLM ที่กำหนดไว้ พร้อมบล็อกโฮสต์ของตัวเครื่องมือเอง
    ตัวอย่างเช่น สำหรับ Crush จะอนุญาตให้เข้าถึง *.openrouter.ai แต่บล็อก *.charm.land ที่ใช้สำหรับอัปเดตรายการ LLM อัตโนมัติ ทำให้รู้สึกสบายใจกว่ามากที่จะมอบทุกอย่างให้โหมด yolo ทำ

    • ใน bubblewrap ทางที่ดีคือดึง rootfs อย่าง debian:unstable จาก Docker Hub มาสร้างเป็นสภาพแวดล้อมดิสโทรเต็มรูปแบบในโฟลเดอร์แยก
      จากนั้นติดตั้ง AI agent ไว้ข้างใน แล้วเขียนสคริปต์เพื่อรัน bwrap โดยตั้งให้ rootfs ของดิสโทรเป็นแบบอ่านอย่างเดียว และ /home/user ที่ปรับแต่งเองเป็นแบบอ่าน-เขียน แบบนี้ไฟล์สำคัญนอกไดเรกทอรีที่กำหนดจะมองไม่เห็น และยังรันหลายเอเจนต์โดยไม่ให้มองเห็นกันเองได้ด้วย
      หากอยากเพิ่มความแข็งแกร่งอีก ก็สามารถเรียก runsc ... do ... ของ gVisor จากข้างใน หรือใช้ virtual machine monitor อย่าง muvm ได้ bwrap ทำหน้าที่จัดสภาพแวดล้อม และค่อยล็อกด้วยเครื่องมือแซนด์บ็อกซ์แยกอีกชั้น จึงเชื่อถือได้
      ถ้าตั้งค่าถูกต้อง แค่ bwrap ก็เพียงพอจะกันผู้โจมตีส่วนใหญ่ได้ และการยกระดับสิทธิ์ก็น่าจะต้องพึ่ง ช่องโหว่ zero-day ของ Linux kernel แทบจะอย่างเดียว
    • อยากรู้ว่าใช้วิธีไหนในการทำสิ่งนี้
    • อยากรู้ว่าการเสริมความปลอดภัยเพิ่มเติมแบบนี้เป็นแค่เรื่องช่วยให้อุ่นใจ หรือเคยจับพฤติกรรมเสี่ยงจริง ๆ ได้บ้าง
      ถ้าโมเดลทำเรื่องโง่ ๆ จนต้องใช้ข้อจำกัดมาหยุด ผมก็มองว่าตั้งแต่แรกมันอาจไม่คุ้มจะใช้ ผมเองก็กำลังเสริมความแข็งแกร่งให้สภาพแวดล้อมของตัวเองอยู่ ไม่ได้ตั้งใจจะวิจารณ์แนวปฏิบัตินี้

  • ตัวรัน native coding agent แบบปิดซอร์ส อย่าง claude-code, Codex, grok-build มีความเสี่ยงด้านความเป็นส่วนตัว เพราะไม่รู้ว่าในการอัปเดตครั้งถัดไปจะมีฟีเจอร์ลับอะไรเพิ่มเข้ามา
    การใช้โมเดลผ่าน API ใน opencode ปลอดภัยกว่ามาก แต่ก็ต้องแลกกับการที่ทำผลงานได้ยากจะดีเท่าตัวรันแบบ native

    • ถ้ามีสิทธิ์ใช้งานมากพอ แค่การเรียกเครื่องมือฝั่งเซิร์ฟเวอร์ก็สามารถ สร้างโค้ดเบสทั้งชุดขึ้นใหม่ ได้ และกระบวนการนี้ก็แทบตรวจจับทั้งหมดไม่ได้
      วิธีของ Grok แค่ทำแบบโจ่งแจ้งกว่าเท่านั้น แต่ opencode เองก็ไม่ได้สร้างขอบเขตความปลอดภัยที่แท้จริง คล้ายมีมที่เอา Cheetos มาทำเป็นแม่กุญแจ
    • Codex เป็น โอเพนซอร์ส
    • การอัปเดตอัตโนมัติ เองก็เป็นปัญหาใหญ่
      แน่นอนว่าการไม่แพตช์ช่องโหว่ remote code execution อย่างใน Windows XP SP1 ทันทีนั้นก็เสี่ยง แต่ตลอดหลายสิบปีที่ผ่านมา ผมเห็นความเสียหายจากการอัปเดตอัตโนมัติมากกว่าความเสียหายที่น่าจะเกิดจากการไม่อัปเดตเสียอีก
    • ผมใช้เอเจนต์ที่ทำเอง แต่ถึงอย่างนั้นก็รับความเสี่ยงที่บัญชีบริษัทจะถูกแบนเพราะเรื่องนี้ไม่ได้

  • ข้อความที่ว่า “อัปโหลด ทั้งรีโพซิทอรี รวมถึงเนื้อหาไฟล์ทั้งหมดที่ติดตามอยู่และประวัติ Git ทั้งหมด โดยไม่เกี่ยวว่าเอเจนต์จะอ่านไฟล์นั้นหรือไม่” นั้นช็อกมาก
    ผมพอเดาได้อยู่บ้างว่า Elon อาจทำอะไรแบบนี้เพื่อไล่ตามให้ทัน แต่ก็ยังน่ากังวลอย่างหนัก ถึงจะตั้งราคาได้แข่งขันได้และ grok-4.5 ก็มีประสิทธิภาพดีพอ แต่ก็เพราะเหตุผลแบบนี้แหละที่ผมไม่เลือกใช้

    • นี่คือ ข้อมูลรั่วไหล อย่างชัดเจน และควรผิดกฎหมาย
    • สงสัยว่าเพราะความร่วมมือกับ Microsoft ทำให้ OpenAI เข้าถึงรีโพซิทอรี GitHub ทั้งหมดได้ด้วยหรือเปล่า
    • สุดท้ายมันก็เป็น การแข่งขันสู่ก้นเหว
    • ผมหาข้อมูลไม่ได้เลยว่าต้องแชร์ข้อมูลอะไรบ้าง เลยลังเลแม้แต่จะลองใช้ฟรี
    • CLI แบบนี้ควรรันอยู่ในแซนด์บ็อกซ์ที่จำกัดไดเรกทอรีที่เข้าถึงได้เสมอ
      CLI อาจดึง SSH key หรือข้อมูลอ่อนไหวอื่นออกไปโดยไม่ได้ตั้งใจ และโปรแกรมเมอร์ก็พลาดแบบนี้กันบ่อยจริง ๆ ผมไม่อยากฝากความปลอดภัยไว้กับคำถามว่า “การอัปโหลดทุกไฟล์ที่เข้าถึงได้” เป็นความตั้งใจหรือเป็นความผิดพลาด

  • ประเด็นแรกที่ว่า “โมเดลอ่านไฟล์ลับในรีโพซิทอรี” นั้นจริง ๆ แล้วแทบจะเป็น พฤติกรรมที่ตั้งใจไว้
    LLM ไม่มีทางรู้ก่อนอ่านไฟล์ว่าข้างในมีข้อมูลลับหรือไม่ การให้ LLM เข้าถึงไฟล์ที่มีความลับแบบ plaintext แล้วค่อยตกใจเมื่อมันอ่าน นั่นต่างหากคือปัญหาพื้นฐาน
    แต่การอัปโหลดทั้งรีโพซิทอรีแบบอัตโนมัตินั้นไร้เหตุผลมาก ถ้ารีโพซิทอรีมีขนาดหลาย GB บางเครือข่ายอาจใช้เวลานานมาก และถ้าไม่มีเป้าหมายอื่นอย่างการรวบรวมข้อมูลทั้งหมด มันก็ดูแทบไม่มีประโยชน์

  • ผมถือมาโดยตลอดว่าอย่างน้อย workspace ปัจจุบันที่รันเอเจนต์อยู่ก็ควรถูกสมมติว่าเอเจนต์จัดการได้อย่างอิสระอยู่แล้ว เลยดูเป็นพฤติกรรมที่คาดไว้
    เอเจนต์ส่วนใหญ่ก็อ่านข้อความแรกพร้อมอ่านโค้ดและข้อมูลลับในนั้นอยู่แล้ว ถ้าฝั่งเซิร์ฟเวอร์เอาสิ่งนี้ไปใช้เพื่อลด เวลาวนรอบของพรอมป์ต์และการเรียกเครื่องมือ มันอาจเป็นประโยชน์กับผู้ใช้ด้วยซ้ำหรือเปล่า

    • เวลาจะอ่านไฟล์และส่งคำตอบกลับ ก็ใช้ message API ปกติ
      แต่ในกรณีนี้มีการพบ endpoint แยกต่างหากที่ดูดทั้งโฟลเดอร์โปรเจ็กต์ออกไปยัง GCP storage bucket ใครก็ตามที่เคยออกแบบระบบกระจายขนาดใหญ่จะดูออกว่านี่คือโครงสร้างสำหรับกวาดเก็บข้อมูลฝึกโมเดล
    • เท่าที่ผมรู้ Cursor ทำ งานทำดัชนี บางอย่างในเครื่อง
      จึงไม่จำเป็นต้องอัปโหลดทุกไฟล์ แต่ค้นหาเฉพาะส่วนที่เกี่ยวข้องแล้วส่งให้โมเดลใช้งานได้

  • ถ้ามีคนเขียนสรุปเองก็คงดีกว่านี้ แต่ตัวเนื้อหาก็น่ากังวลอยู่ดี

    • บทความนี้ใช้แค่โค้ดบล็อกไม่กี่อันที่แสดงสิ่งที่ถูกอัปโหลด กับ ย่อหน้า 2–3 ย่อหน้า ก็พอแล้ว
      รายงานที่ AI เขียนอ่านทรมานเกินไป ผมกวาดตาอยู่ราว 10 วินาทีก็หมดความสนใจ
    • อย่างน้อยก็น่าจะให้มนุษย์ช่วยขัดเกลาร่วมกับ LLM อีกสักสองสามรอบเพื่อปรับสำนวน

  • ชวนสงสัยว่าเนื้อหาที่ขโมยไปจะถูกเอาไปใส่ใน โปรเจ็กต์ Macrohard ที่จะ “ทำให้ทุกธุรกิจเป็นอัตโนมัติ” หรือใน “everything app” หรือไม่
    มันดูเป็นแนวคิดแบบว่าไม่จำเป็นต้องสร้างทุกอย่างเอง แค่ขโมยมาก็พอ

    • จุดพีคคือผู้ใช้ยังยอมจ่ายเงินเพื่อรับสิทธิพิเศษแบบนี้
      ถ้าบริหารบริษัทแบบไร้ศีลธรรม ขนาดของการหลอกลวงก็จะยิ่งชัด และคุณก็คงพยายามขโมยให้ได้มากที่สุดก่อนที่กฎระเบียบจะเข้ามาหยุด ผมไม่ได้บอกว่าพวกเขากำลังทำแบบนั้นจริง ๆ แต่ แรงจูงใจทางเศรษฐกิจ มันจัดวางไปในทิศทางนั้นอย่างชัดเจน

  • ควรมองว่า AI เอเจนต์สามารถอ่านไฟล์ในไดเรกทอรีที่ตัวรันเริ่มทำงานได้
    โดยมากมันจะอ่านโค้ดตั้งแต่พรอมป์ต์แรก รวมถึงข้อมูลลับในนั้นด้วย และ .env มีไว้สำหรับสภาพแวดล้อมโลคัล จึงไม่ควรใส่ข้อมูลลับจริงไว้ในนั้น เนื่องจากไม่อาจเชื่อถือคำสั่งของ AI เอเจนต์ได้ จึงต้อง แยกกักกัน ออกจากข้อมูลลับจริง
    หากยอมรับสมมติฐานนี้ การอัปขึ้นเซิร์ฟเวอร์ไว้ล่วงหน้าอาจดีกว่าการส่งโค้ดเป็นคอนเท็กซ์ทุกครั้ง

    • ด้วยลักษณะการทำงานของ LLM สุดท้ายแล้วโค้ดก็ต้องถูก ส่งต่ออีกครั้งผ่านคอนเท็กซ์
      ดังนั้นเหตุผลของการอัปโหลดแยกแบบนี้จึงน่าจะมีแค่ว่า Musk ต้องการข้อมูลฝึกที่สะอาด เช่น โครงสร้างโปรเจ็กต์ ไลบรารียอดนิยม และเวิร์กโฟลว์ CI สำหรับโมเดลถัดไป
    • ต่อให้อัปโหลดครั้งเดียว มันก็ยังคงถูกใช้ในกระบวนการอนุมานอยู่ดี และสิ่งที่ประหยัดได้มีเพียงทราฟฟิก HTTP เล็กน้อย
    • แก่นของเรื่องอาจไม่ได้ใหญ่โตนัก อาจเป็นแค่ว่า Grok ดุดันกว่าเจ้ารายอื่นราว 10% ในการประกอบคอนเท็กซ์ หรือไม่ก็เป็นเพียงวิธีที่ทำให้ออกได้เร็วกว่า
      ผู้ให้บริการทุกรายต่างมีทั้งความสามารถและแรงจูงใจที่จะทำแบบเดียวกัน หากมันช่วยให้ผลลัพธ์ดีขึ้น
      ความต่างที่แท้จริงคือมันส่งไฟล์ข้อมูลลับอย่าง .env ไปโดยไม่ปิดบัง และไม่ได้แค่ประมวลผลชั่วคราว แต่ยัง เก็บไว้ใน GCS bucket ที่มีการระบุชื่อ อีกทั้งยังเปิดใช้เป็นค่าเริ่มต้นโดยไม่แจ้งวิธีอัปโหลดไว้ในเอกสารการตั้งค่า CLI
      ไม่ควรวาง .env ที่ไม่ได้เข้ารหัสไว้ในพาธที่เข้าถึงได้ แม้จะดีกว่าหาก Grok ระบุข้อมูลลับและเพิกเฉยมันได้ แต่ผู้ใช้ก็ไม่ควรพึ่งพาพฤติกรรมแบบนั้น

  • การที่ทั้งรีโพสิตอรีถูกอัปโหลดเหมือนกันไม่ว่าจะเปิดหรือปิดการตั้งค่า “Improve the model” ถือว่าร้ายแรงมาก
    บริษัท AI ส่วนใหญ่ก็น่าจะทำคล้ายกันในตัวรันของตัวเองหากผู้ใช้ยินยอมให้เก็บข้อมูล แต่การอัปโหลดแม้ผู้ใช้ปิดไว้อย่างชัดเจนแล้วถือว่าเจตนาไม่ดี

  • เมื่ออัปโหลดโค้ดเบสทั้งหมด โมเดลก็สามารถดูโค้ดได้ระหว่างที่มัน “คิด” โดยไม่ต้องขอให้ไคลเอนต์เรียกใช้เครื่องมือจริง
    ยังไม่ชัดว่าข้อเสียของการขอกลับไปที่ไคลเอนต์คืออะไร จึงไม่ใช่เหตุผลที่ดีนัก แต่ก็เป็นข้ออ้างที่ดีที่สุดเท่าที่พอจะนึกออก

    • จุดประสงค์ที่แท้จริงดูใกล้เคียงกับการขโมย ความลับทางการค้า การออกแบบแอป และความรู้ในการทำงานภายในองค์กร หรือการคัดลอกโค้ด แอป เครื่องมือ และกระบวนการมากกว่า
      โค้ดที่เดิมเป็นของส่วนตัว ตอนนี้กลายเป็นโค้ดของพวกเขาแล้ว
    • อาจใช้เพื่อ ควบคุมจากระยะไกล ผ่านคอนเทนเนอร์ที่ไหนสักแห่งจากโทรศัพท์มือถือ แม้คอมพิวเตอร์จะออฟไลน์ และค่อยกลับมาพัฒนาแบบโลคัลภายหลังพร้อมซิงก์การเปลี่ยนแปลงจาก GCP bucket
      มันค่อนข้างมีประโยชน์ แต่ไม่ถึงกับมีประโยชน์พอให้ยกทั้งรีโพสิตอรีให้ Elon การที่ทำให้ปฏิเสธไม่ได้และไม่เปิดเผยเลย ยิ่งตอกย้ำว่าข้อมูลนี้ไม่ควรถูกฝากไว้กับพวกเขา