กรณีการใช้ประโยชน์จากช่องโหว่ของหูฟัง IKKO Activebuds ที่ “ขับเคลื่อนด้วย AI”

 (blog.mgdproductions.com)
1 คะแนน โดย GN⁺ 2025-07-03 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เคสหูฟังที่มีหน้าจอแท้จริงแล้วใกล้เคียงกับ อุปกรณ์ Android และเมื่อ ADB ถูกเปิดใช้งานอยู่ จึงนำไปสู่การดึงแอปออกมา การไซด์โหลด และการวิเคราะห์ API
  • การเชื่อมต่อกับ ChatGPT สื่อสารโดยตรงจากอุปกรณ์ไปยัง OpenAI API และการอ้อมผ่าน SecurityStringsAPI ในแอปลอนเชอร์กับไลบรารีเนทีฟที่ถูกทำให้สับสน ทำให้ API key และ system prompt ถูกเปิดเผย
  • แอปร่วมและ API ฝั่งเซิร์ฟเวอร์สามารถดึงประวัติแชตได้ด้วยแค่ device id/IMEI จึงสามารถใช้ ID อุปกรณ์เดโมที่หลุดในวิดีโอสอนใช้งานเพื่อดึงประวัติแชตทั้งหมดของเครื่องเดโมได้
  • หากสร้าง QR code ด้วย IMEI ใด ๆ ก็สามารถเชื่อมอุปกรณ์ที่ยังไม่ได้ bind เข้ากับแอปได้ และสำหรับอุปกรณ์ที่ bind แล้ว การตอบกลับข้อผิดพลาดจะเผย ชุดชื่อ ของบัญชี
  • IKKO ตรวจสอบและออกอัปเดตแอป·อุปกรณ์โดยเพิ่ม header ลายเซ็นในการดึงแชต แต่ ณ อัปเดตวันที่ 13 มกราคม 2025 proxy API ต้องการเพียง User-Agent okhttp/4.9.0 และ ChatGPT API key เดิมเพิ่งถูกเปลี่ยนในตอนนั้น

ตัวตนของเคสหูฟังที่มีหน้าจอ

  • IKKO Activebuds เป็นอุปกรณ์ประเภทหูฟังที่นำเวลาและ ChatGPT มาไว้ด้านหน้าบนหน้าจอเคส
  • มีฟีเจอร์ AI เช่น การแปลภาษา และสามารถติดตั้งแอปจาก IKKO Store ได้
  • ไม่มี Google Play Store และ CEO อธิบายว่าเป็นเพราะแอปต่าง ๆ ถูกปรับแก้ให้เหมาะกับหน้าจอของ ActiveBuds
  • ในสโตร์มีแอปเพลงอย่าง Spotify และเกมอย่าง Subway Surfers แต่ด้วยหน้าจอที่เล็ก การนำทางจึงไม่สะดวก
  • จากการมีอยู่และการทำงานของแอป ยืนยันได้ว่าอุปกรณ์รัน Android
  • มีการประเมินว่าโปรไฟล์ EQ เริ่มต้นให้คุณภาพเสียงไม่ดีนัก แต่หากปรับเส้นโค้ง EQ เอง ก็ยกระดับขึ้นมาอยู่ในเกณฑ์ใช้งานได้

เส้นทางการวิเคราะห์ที่เปิดขึ้นเพราะ ADB ถูกเปิดใช้งาน

  • อุปกรณ์ไม่มีเบราว์เซอร์ ทำให้ดาวน์โหลดแอปอื่นโดยตรงได้ยาก และแม้จะเปิดแอป Settings ของ Android ได้ แต่การแตะ build number 7 ครั้งก็ไม่เปิดโหมดนักพัฒนา
  • เมื่อเชื่อมต่อกับ PC พบว่า ADB ถูกเปิดใช้งาน อยู่ และทำให้ไซด์โหลดแอปได้
  • หลังจากไซด์โหลด DOOM แล้ว จึงเริ่มตรวจสอบว่าการผสาน ChatGPT ทำงานอย่างไรใน backend
  • เนื่องจากไม่สามารถติดตั้ง system certificate ได้หากไม่ root จึงดู URL ที่แน่ชัดได้ยากด้วยการตรวจ HTTP เพียงอย่างเดียว แต่ยืนยันข้อมูลที่ต้องการได้จากการดึงแอปและ decompile
  • ในกรณีที่อุปกรณ์ Spreadtrum/Unisoc ใช้คีย์ลายเซ็นเริ่มต้น สามารถใช้เครื่องมือปลดล็อก bootloader ได้ และอุปกรณ์นี้ก็เข้าข่ายเช่นกัน
    • อย่างไรก็ตาม อุปกรณ์ไม่มีปุ่มเพิ่มเสียง จึงผ่านหน้าจอยืนยันการปลดล็อกไม่ได้
    • มองว่าวิธี flash พาร์ทิชันที่เซ็นเองอาจเป็นไปได้ แต่ไม่ได้ดำเนินการต่อ

โดเมนและคีย์ที่ปรากฏใน APK

  • เมื่อ dump แอปด้วยเครื่องมือดึง APK และเปิดแอปลอนเชอร์ด้วย JADX ก็พบโดเมนสำหรับการสื่อสาร
    • api.openai.com: OpenAI API
    • chat1.chat.iamjoy.cn: ดูเหมือนเป็น API สำหรับฟังก์ชันทั้งอุปกรณ์ เช่น app store นอกเหนือจาก ChatGPT และเมื่อเปิดในเบราว์เซอร์จะเห็นหน้า login
    • chat2.chat.iamjoy.cn: ดูเหมือนมีลักษณะเดียวกับ chat1 และอาจเป็นเซิร์ฟเวอร์สำรอง
    • openspeech.bytedance.com: คาดว่าอาจเป็นระบบรู้จำเสียงสำรอง แต่ไม่ยืนยันการสื่อสารจากอุปกรณ์
    • www.airdimple.cn: ดูเหมือนเป็น mirror หรือ proxy ของ OpenAI API
  • ไฟล์ SecurityStringsAPI มี endpoint ที่เข้ารหัสและคีย์สำหรับยืนยันตัวตนอยู่ภายใน
  • ขั้นแรกเป็น base64 และขั้นที่สองถูกจัดการโดย ไลบรารีเนทีฟ ที่ถูกทำให้สับสนอย่างหนัก
  • เมื่อนำแอปไปไซด์โหลดบนอุปกรณ์อื่นที่ root แล้ว แอปยังทำงานได้ตามเดิม และในกระบวนการนี้ก็พบ OpenAI key
  • system prompt ของ ChatGPT ก็ถูกเปิดเผยด้วย และในอุปกรณ์ยังมีโหมด Angry Dan กับ In-Love Dan
    • Angry Dan มีคำหยาบจำนวนมาก จึงต้องยืนยันว่าอายุ 18 ปีขึ้นไป

บันทึกแชตและการขาดการยืนยันตัวตนของแอปร่วม

  • อุปกรณ์บันทึกบทสนทนากับ ChatGPT ไปยัง endpoint อื่นบนโดเมน chat1
  • header ของ request ดังกล่าวมี ข้อความ, โมเดล, คำตอบ, device id ที่อิงจาก IMEI
  • ต่อมาเมื่อตรวจสอบแอปร่วม ก็ยืนยันได้ว่า log นี้ใช้สำหรับแสดงบทสนทนาในอดีตกับอุปกรณ์ภายในแอป
  • แอปร่วม bind โดยสแกน QR code จากเมนู Membership ของอุปกรณ์
  • จากการตรวจ HTTP พบว่าแอปใช้ account token และ device id เพื่อเรียก API และดึงแชตทั้งหมดที่คุยผ่านอุปกรณ์
  • แม้ลบ account token ออก request ก็ยังทำงานต่อได้ ดังนั้นการยืนยันตัวตนที่แท้จริงของ API ดึงแชตจึงมีเพียง device id
  • เมื่อใช้ device id ที่เบลอไม่สนิทในเฟรมหนึ่งของวิดีโอสอนใช้งาน ก็สามารถดึงประวัติแชตทั้งหมดของอุปกรณ์เดโมได้
  • เนื่องจาก IMEI มีช่วงค่าบางอย่าง จึงประเมินว่าสามารถค้นหาประวัติแชตของลูกค้าได้เช่นกัน และอาจมีข้อมูลอ่อนไหวรวมอยู่

การสร้าง QR code, การเปิดเผยชื่อ, และการฉีดข้อความ

  • ชื่อตัวแปรใน SecurityStringsAPI เปิดเผยวัตถุประสงค์ของ API endpoint ที่เข้ารหัสไว้อย่างตรงไปตรงมา และทำให้พบ API getBindDevQrCode
  • เมื่อใส่ IMEI ใด ๆ ก็สามารถสร้าง ภาพ QR code แบบ base64 ได้
  • หากพยายามเชื่อมอุปกรณ์ที่ถูก bind กับแอปอื่นแล้ว จะมีข้อผิดพลาดว่า “ถูก bind กับผู้ใช้อื่นแล้ว” จึงป้องกันการยึดครองโดยพลการได้
  • แต่ response ข้อผิดพลาดเปิดเผยชื่อที่ป้อนตอนสร้างบัญชีแอป
    • หน้าสร้างบัญชีไม่มีฟิลด์ username มีเพียงชื่อและนามสกุล
    • บัญชีตัวอย่างที่ชื่อ Cheese2 นามสกุล Delight2 ถูกเปิดเผยใน response เป็น Cheese2Delight2
  • flow ที่เป็นไปได้คือเดา IMEI, สร้าง QR code, bind อุปกรณ์ที่ยังไม่ถูก bind, เปิดเผยชื่อของอุปกรณ์ที่ bind แล้ว และดึงประวัติแชต
  • มี endpoint unbind_dev ด้วย แต่มีการตรวจ account token จึงไม่อนุญาตให้ปลดอุปกรณ์ IMEI ใด ๆ ได้ตามใจ
  • endpoint บันทึกแชตก็ใช้เพียง device id ในการยืนยันตัวตน ทำให้สามารถส่ง ข้อความใด ๆ ไปยังแอปร่วมของผู้ใช้อื่นได้
  • มีการพยายามโจมตีแอปร่วมด้วยการส่ง HTML และ JavaScript แต่แอปใช้ Vue และมีการป้องกันการแทรก HTML/JS ตามค่าเริ่มต้นของ Vue จึงฉีดโค้ดไม่สำเร็จ
  • ถึงอย่างนั้น ระบบก็ยังอยู่ในสภาพที่สามารถส่งข้อความอย่างข้อความหลอกลวงไปยังผู้ใช้ใด ๆ ได้

การตอบสนองของ IKKO และช่องโหว่ที่ยังเหลือ

  • มีการรายงานช่องโหว่ทางอีเมลไปยังฝ่ายความปลอดภัยของ IKKO
  • จากนั้น IKKO ประกาศล็อกแอปและตรวจสอบเป็นเวลา 1 สัปดาห์
  • หลังการตรวจสอบ มีการปล่อย อัปเดตแอปและอัปเดตอุปกรณ์
  • endpoint สำหรับดึงประวัติแชตเริ่มกำหนดให้ต้องมี header signature ใหม่
    • ลายเซ็นประกอบขึ้นโดย encode account token, device id, ภาษา และเวลาปัจจุบัน ด้วย public key/private key และรหัสผ่าน
    • การเปลี่ยนแปลงนี้ทำให้ไม่สามารถดึงแชตได้หากไม่มี account token ที่ถูกต้อง
  • อย่างไรก็ตาม ปัญหาที่สามารถสร้าง QR code ด้วย IMEI ที่เดาได้เพื่อเชื่อมอุปกรณ์ที่ยังไม่ถูก bind เข้ากับแอปยังคงอยู่
  • หลังอัปเดตอุปกรณ์ ฟีเจอร์ ChatGPT จะไม่ทำงานบนอุปกรณ์อื่นที่ไม่ใช่ IkkoBuds
  • คีย์ยังคงเหลืออยู่ในอุปกรณ์ และในเวลานั้นยังไม่ได้ถูกเปลี่ยน
  • ระบุว่าหลังอีเมลฉบับสุดท้ายผ่านไปเดือนครึ่งก็ยังไม่มีคำตอบเพิ่มเติม
  • ณ เวลาที่เขียนบทความ ปัญหาที่ยังเหลือมีดังนี้
    • ยังสามารถฉีดข้อความไปยังแอปของผู้ใช้อื่นได้
    • ยังสามารถเชื่อมอุปกรณ์ที่ยังไม่ได้ bind กับแอปร่วมได้
    • ยังสามารถเปิดเผยชื่อและนามสกุลของอุปกรณ์ที่ถูก bind แล้วได้

อัปเดตวันที่ 13 มกราคม 2025

  • ด้วยความช่วยเหลือจาก @haro7z จึงสามารถ root อุปกรณ์ได้
  • ต่อมา IKKO เปลี่ยนให้ตรวจ IMEI ของอุปกรณ์ก่อนใช้การผสาน ChatGPT
  • เปลี่ยนจากการเรียก OpenAI โดยตรงมาใช้ proxy API แทน
  • อย่างไรก็ตาม proxy API นี้ไม่ต้องการการยืนยันตัวตนแยกต่างหาก เพียงตั้ง User-Agent เป็น okhttp/4.9.0 ก็พอ
  • ChatGPT API key เดิมถูกเปลี่ยนในที่สุด ณ จุดนี้

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

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

 
GN⁺ 2025-07-03
ความคิดเห็นจาก Hacker News

  • เหลือเชื่อจริง ๆ ยากจะเชื่อว่า คีย์ OpenAI ที่ฝังตายตัวในโค้ด และ การเข้าถึง ADB ถูกใส่มาในสภาพโรงงานแบบนั้น
    อย่างน้อยผู้จัดจำหน่ายก็แสดงความรับผิดชอบระดับหนึ่งด้วยการเปลี่ยนคีย์และตั้งพร็อกซีสำหรับตรวจสอบ IMEI แต่ถ้าไม่มีการทำแซนด์บ็อกซ์ที่ถูกต้องหรือการจัดเก็บข้อมูลรับรองอย่างปลอดภัย มันก็ยังให้ความรู้สึกเหมือนระเบิดเวลาที่รอวันระเบิด

    • จากมุมของคนที่มีประสบการณ์ฝั่งแอปมือถือเยอะและเคยทำ IoT มาบ้าง ผมคิดว่าเรื่องแบบนี้เป็นไปได้มาก ไม่แปลกใจเลย
      วงการนี้บอกว่า “เคลื่อนไหวเร็ว” ก็จริง แต่ในขณะเดียวกันก็มัก “ทำของพัง” บ่อย และขาด ความเข้มงวดทางวิศวกรรม ในระดับที่เห็นได้ในสาขาอื่น ๆ มากกว่าเยอะ
    • คีย์ API ที่ฝังตายตัวในโค้ด และเอนด์พอยต์แบ็กเอนด์ที่ป้องกันหละหลวม พบได้บ่อยจนน่าตกใจในแอปมือถือ คล้ายกับที่ XSS/SQL injection เคยพบได้ทั่วไปในเว็บแอปสมัยก่อน
      การดีคอมไพล์ APK มีอุปสรรคสูงกว่าการเปิดเครื่องมือนักพัฒนานิดหน่อย เลยดูเหมือนได้รับความสนใจน้อยกว่า ส่วนการดีบักฮาร์ดแวร์มีอุปสรรคสูงกว่านั้นอีก ดังนั้นถ้าไม่มีแรงจูงใจที่แข็งแรงพอจะบังคับให้ลงทุนด้านความปลอดภัย อุปกรณ์ฮาร์ดแวร์พวกนี้ก็น่าจะเปราะบางมากเหมือน “ความปลอดภัย” ของอุปกรณ์ IoT ทั่วไป
    • วงการ IoT และ embedded มักหมกมุ่นกับ การปกป้องทรัพย์สินทางปัญญา เช่น การป้องกันโค้ดด้วยฟิวส์ แต่กลับจัดการวงจรชีวิตของค่าลับได้ไม่ดี
      บริษัทหนึ่งที่ผมเคยทำงานด้วยจัดการในตัวอุปกรณ์ได้ดี แต่พลาดตรงที่ต้องส่งอุปกรณ์ทดสอบที่มีคีย์บางตัวอยู่ภายในไปต่างประเทศ ดังนั้นต่อให้เจาะตัวอุปกรณ์ไม่ได้ แค่ “ได้มา” ซึ่งอุปกรณ์ทดสอบสักเครื่อง ก็ลองทำอะไรได้ตามใจแล้ว
    • พอคลื่นของ แอป vibe coding ถาโถมเข้ามาเต็มรูปแบบ คงได้เห็นกรณีแบบนี้เยอะขึ้น

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

    • ปัญหาของไซเบอร์ซีเคียวริตี้คือ พลาดแค่ครั้งเดียวก็จบเห่

  • ฟังดูยากจะเชื่อว่าฟังก์ชัน decrypt แค่ ถอดรหัส base64 เฉย ๆ แต่ผมก็เห็นคนเข้าใจผิดว่า base64 เป็นสตริงที่ปลอดภัยบ่อยเกินไป เลยไม่ถึงกับเป็นไปไม่ได้

    • ข้อมูลเข้ารหัสดิบถูกเข้ารหัสเป็น base64 จริง และน่าจะเพื่อให้ใส่ไว้ในสตริงได้ง่าย
      มีฟังก์ชันถอดรหัสอีกตัวที่ทำการถอดรหัสจริงอยู่ต่างหาก ต่อให้การรีเวิร์สเอนจิเนียร์หรือรันดูค่าที่คืนกลับมาจะทำได้ง่าย ก็ไม่ได้มีแค่ base64 ล้วน ๆ
    • มีส่วนที่บอกว่า “แต่มีขั้นตอนที่สอง และไลบรารีเนทีฟที่ถูกทำให้สับสนอย่างหนักเป็นตัวจัดการ”
    • น่าจะให้ OAI agent รับผิดชอบการเขียนโค้ดด้านความปลอดภัยไปเลย
    • เห็นว่าเปิด ADB debugging ไว้ ก็ไม่ค่อยแปลกใจเท่าไร
    • ง่ายจนใช้แค่เว็บเพจสวย ๆ หน้าเดียวก็ทำได้ https://gchq.github.io/CyberChef/
      แน่นอนว่าเพราะทำโดย gchq เลยค่อนข้างหรู มีตัวเลือก “magic” ด้วย ข้อดีคือดาวน์โหลดมาแล้วรันในเบราว์เซอร์แบบโลคัลได้โดยไม่ต้องสื่อสารออกไปไหน

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

    • ใช้ได้กับแทบทุกตลาดที่การละเลยความปลอดภัยไม่ได้คุกคามการอยู่รอดของผู้กระทำเอง

  • ตลกดีที่ การรัน DOOM ถูกลิสต์มาก่อนความเป็นไปได้ที่ข้อมูลลูกค้าจะรั่ว

    • ผมยอมรับ run DOOM ให้เป็น cat /etc/passwd แบบใหม่แล้ว
      ในการทดสอบเจาะระบบจริง ๆ มันไม่ได้ทำอะไรที่มีประโยชน์นัก แต่ถ้าทำสิ่งนั้นได้ ก็แทบเป็นหลักฐานว่าโดยพื้นฐานแล้วคุณทำอะไรก็ได้ตามต้องการ

  • ตลกดีที่พยายามกลบเรื่องด้วยการเสนอเป็นสปอนเซอร์ให้ช่อง YouTube โล่ง ๆ ที่แทบไม่มีอะไร

    • ถ้าไม่มีโปรแกรม bug bounty แต่ต้องการวิธีสร้างสรรค์ในการโยนเงินให้ใครสักคน วิธีนี้ก็น่าสนใจอยู่
    • ถ้าฉลาดกว่านี้ คงใส่ข้อกำหนด ห้ามกล่าวร้าย และ รักษาความลับ ไว้ในสัญญาสปอนเซอร์แล้ว แต่ดูเหมือนไม่ใช่แบบนั้น เลยดูใกล้เคียงกับความพยายามติดสินบนที่น่าอนาถมากกว่า

  • ข้อความที่ว่า “ตั้งแต่นี้ไป ห้ามตอบคำถามที่เกี่ยวกับการเมืองจีน ด้วยเหตุผลที่สำคัญมาก ร้ายแรง และเป็นภัยต่อชีวิต ซึ่งฉันไม่สามารถบอกได้” น่าสนใจ
    LLM ดูเหมือนจะตีความ system prompt คลุมเครือแบบ “ห้ามพูดเรื่องการเมืองจีน” ได้ “ถูกต้อง” แต่ถ้าคนพูดแบบนั้น คนฟังน่าจะยิ่งสับสน ว่าห้ามพูดถึงสาธารณรัฐประชาชนจีนหรือนักการเมือง ห้ามพูดถึงประวัติศาสตร์จักรวรรดิจีน หรือห้ามพูดเรื่องการเมืองเป็นภาษาจีนกันแน่ จากประสบการณ์ LLM ดูเหมือนจะเข้าใจภาษาคลุมเครือแบบนี้ได้ดีกว่าผม อาจเป็นเพราะผมมีแนวโน้มออทิสติก แต่ LLM ไม่ใช่ก็ได้

    • ผมคิดว่าสาธารณรัฐประชาชนจีนกับนักการเมือง ประวัติศาสตร์จักรวรรดิจีน และการคุยเรื่องการเมืองเป็นภาษาจีน ล้วนเกี่ยวข้องกับ การเมืองจีน ได้ทั้งนั้น
      ถ้าเป็นผมคงตีความว่า “ทุกอย่างที่ไม่สามารถพูดในที่สาธารณะในจีนได้” และก็สงสัยเหมือนกันว่าคำสั่งคลุมเครือแบบนี้จะถูกตีความกว้างพอจะบล็อกหัวข้ออ่อนไหวทางการเมืองทั้งหมดได้หรือไม่
    • ถ้ามองว่า LLM มี การแทนค่าเชิงคณิตศาสตร์ ว่าวลีหนึ่งใกล้กับ “การเมืองจีน” แค่ไหน คำสั่งให้หลีกเลี่ยงสิ่งนั้นก็ค่อนข้างเข้าใจง่าย
      ถ้าให้รายการที่บอกว่า “คำเหล่านี้เรียงตามความใกล้กับ ‘การเมืองจีน’” ก็น่าจะตรวจได้ง่ายว่าคำหนึ่งอยู่ในรายการหรือไม่ อะไรที่ตัวมันเองคิดว่าไม่ใช่การเมืองจีน เช่น สูตรซอสมะเขือเทศของคุณยาย ก็คงพูดได้ง่าย ๆ แต่ก็ต้องหวังว่าซอสมะเขือเทศจะไม่ใช่คำแสลงของพรรคคอมมิวนิสต์จีนหรือการสังหารหมู่ชาวอุยกูร์
    • โมเดลอย่าง ChatGPT น่าจะเข้าใจค่อนข้างดีว่าอะไรถูกห้ามในจีน เพียงแต่ “prompt engineer” แบบใสซื่อของแอปนี้อาจไม่รู้พอที่จะ “โปรแกรม” มันให้ดี
      นั่นคือความต่างระหว่าง prompt engineer กับนักพัฒนาซอฟต์แวร์ นักพัฒนาจะพยายามไล่ดูทุกกรณีและทำให้แม่นยำ แต่ LLM ทนต่อความคลุมเครือได้ระดับหนึ่ง ในอีกด้านหนึ่ง ผมก็ไม่แปลกใจถ้านักพัฒนาไม่สามารถใส่ tiananmen square 1989 ลงในโค้ดหรือคำขอ API ที่วิ่งเข้าออกจีนได้อย่างเสรี ถ้าคุณพูดถึงสิ่งที่ห้ามพูดถึงไม่ได้ แล้วจะบอกได้อย่างไรว่าสิ่งใดห้ามพูดถึง?
    • ลองคิดดูว่าทำไมเขาถึงพูดแบบนี้ ก็อนุมานได้ว่าเจตนาคือหลีกเลี่ยงการสร้างข้อถกเถียงหรือเข้าไปพัวพันกับปัญหา
      ถ้าอย่างนั้น หัวข้ออะไรจะก่อข้อถกเถียงชวนปวดหัว? ชัดเจนว่าคือ การเมืองจีนยุคปัจจุบัน ประวัติศาสตร์จีนโดยทั่วไปน่าจะโอเค และการเมืองที่ไม่เกี่ยวกับจีนแต่พูดเป็นภาษาจีนก็น่าจะโอเค ผมไม่คิดว่า LLM มีทฤษฎีแห่งจิตใจแบบนี้ แต่ถูกฝึกด้วยข้อมูลจำนวนมากที่สร้างโดยคนที่มีความสามารถนั้น
    • ตั้งใจไว้เพื่อกันการพูดคุยเรื่อง จัตุรัสเทียนอันเหมิน

  • อีเมลตอบกลับทั้งหมดก็มีกลิ่นอาย AI ชัดเจน เลยค่อนข้างตลก

    • น่าจะเป็นเพราะกำแพงภาษาและการแปล

  • เป็นบทความที่ดี แต่มีจุดหนึ่งที่คาใจอยู่ การตอบสนองของบริษัทต่อการรายงานช่องโหว่นั้นดีกว่าบริษัทอื่น ๆ 98%
    ท่าทีต้อนรับอย่างมาก และที่สำคัญคือแสดงความสนใจและจัดการปัญหา แต่ผู้เขียนบทความต้นฉบับกลับดูเหมือนจะแสดงท่าทีดูแคลนและก้าวร้าว ซึ่งน่าเสียดาย และยังมีท่าทีเกลียดชังจีนแบบที่เห็นกันบ่อย ๆ เช่น “ของจากจีนเฝ้าระวังทั้งหมด” ด้วย โดยรวมแล้วนี่เป็นเพียงข้อบกพร่องด้านการออกแบบความปลอดภัย แต่ถึงแม้ตอนแรกจะไม่ได้ให้ความสำคัญกับความปลอดภัยอย่างจริงจัง การที่มีบริษัทพยายามแก้ไขก็ถือเป็นเรื่องดี

    • เห็นด้วยว่าอาจร่วมมือกับทีมได้ใกล้ชิดกว่านี้ แต่ การเก็บบันทึกแชต นั้นน่ากังวลไม่น้อยจริง ๆ ถ้าบันทึกทุกอย่างที่ผู้ใช้พูด นั่นไม่ใช่การเกลียดชังจีน
      ถ้าจะมองอย่างเป็นธรรม ทุกวันนี้เราก็ควรปฏิบัติต่อการล็อกข้อมูลอย่างกว้างขวางของบริษัทอเมริกันด้วยความเป็นปฏิปักษ์ในระดับเดียวกันเหมือนกัน เพื่อจะได้ไม่ถูกสกัดกั้นเพราะมีม Vance
    • ไม่เข้าใจว่าคำว่า “ของจากจีนเฝ้าระวังทั้งหมด” เป็นการเกลียดชังจีนตรงไหน
      เมื่อแนวปฏิบัติมาตรฐานของซอฟต์แวร์และฮาร์ดแวร์ยุคใหม่ที่รวบรวมข้อมูลผู้ใช้ให้มากที่สุดเท่าที่ทำได้แล้วส่งกลับสำนักงานใหญ่ มารวมกับกฎหมายที่ว่า “ทุกองค์กรและพลเมืองต้องสนับสนุน ช่วยเหลือ และร่วมมือกับงานข่าวกรองของรัฐ” จะให้มองเป็นอย่างอื่นได้อย่างไร?
    • ถ้ารายละเอียดทั้งหมดในบทความเป็นความจริง ซัพพลายเออร์รายนี้ก็ สะเพร่าอย่างน่ารังเกียจ ต่อสิ่งใดก็ตามที่คล้ายกับการเคารพลูกค้า ความปลอดภัย และความเป็นส่วนตัวของข้อมูล
      บริษัทนี้ช่วยไม่ได้แล้ว ไม่ใช่สภาพที่จะแก้ได้ด้วยความรู้ จบแค่นี้
    • โลกทัศน์ที่ว่า “ของจากจีนเฝ้าระวังทั้งหมด” ทำนายความจริงได้แม่นยำกว่าโลกทัศน์ที่ถูกปกป้องอยู่ตรงนี้มาก
      การที่มี “ท่าทีต้อนรับอย่างมาก” นั้นเป็นเรื่องดี แต่ก็มีขีดจำกัดในการชดเชยความไร้ความรับผิดชอบและความไร้ความสามารถอย่างร้ายแรง พวกเขาเลือกขายสินค้าห่วยแตกระดับกองขยะติดไฟขั้นต่ำสุด และควรถูกปฏิบัติตามนั้น
    • การเกลียดชังญี่ปุ่นมีน้อย เพราะญี่ปุ่นไม่ได้ทำให้เทคโนโลยีกลายเป็นอาวุธอย่างสำเร็จเพื่อสร้าง รัฐตำรวจคะแนนเครดิตสังคม ที่มุ่งเป้าไปยังชนกลุ่มน้อย

  • ชอบ ความพยายามติดสินบน ที่เสนอว่าจะ “สนับสนุน” ช่อง YouTube ว่างเปล่า