Android อาจจำกัด ADB ภายในอุปกรณ์ในเร็ว ๆ นี้

 (kitsumed.github.io)
2 คะแนน โดย GN⁺ 4 시간 전 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • ไม่ใช่ประกาศอย่างเป็นทางการจาก Google แต่ใน คำขอฟีเจอร์บน IssueTracker ที่กำลังอยู่ระหว่างการหารือ ผู้ดูแลหลักของ ADB กล่าวถึงแนวทางจำกัดการเชื่อมต่อแบบ local เพื่อป้องกันการใช้งานในทางที่ผิด และให้ bind เฉพาะกับ wlan0
  • หากอนุญาตเฉพาะ wlan0 อาจทำให้ ADB ภายในอุปกรณ์ ที่ใช้ที่อยู่ loopback 127.0.0.1 รวมถึง ADB ผ่าน VPN หรือ Ethernet และสภาพแวดล้อมการพัฒนาหลายรูปแบบใช้งานไม่ได้
  • การหารือเริ่มจาก CVE-2026-0073 ซึ่ง bypass การยืนยันตัวตนของ Wireless ADB ได้ทั้งหมด โดยคำขอเดิมคือให้เลือก interface ที่ ADBD รับฟังได้ เพื่อไม่ให้เปิดเผยต่อทุกเครือข่าย
  • โดยทั่วไป แอปอันตรายไม่สามารถเริ่ม ADBD โดยตรง หรือทำ pairing ของ Wireless ADB และอนุมัติ TCP/IP ให้เสร็จได้ด้วยตัวเอง จึงยากที่จะได้สิทธิ์ ADB หากไม่มี การดำเนินการด้วยตนเอง จากผู้ใช้
  • หากบล็อกการเชื่อมต่อ loopback อย่างถาวร เครื่องมือที่ใช้ Shizuku และ libadb-android จะได้รับผลกระทบ จึงจำเป็นต้องมี การตั้งค่าที่ผู้ใช้เลือกได้ เพื่อปิดการบล็อกแบบค่าเริ่มต้นได้แม้หลังรีบูต

การหารือช่วงต้นที่ไม่ใช่ประกาศทางการ

  • ประเด็นนี้ไม่ใช่นโยบายที่สรุปแล้วหรือประกาศอย่างเป็นทางการจาก Google แต่มีพื้นฐานจาก คำขอฟีเจอร์บน IssueTracker ที่กำลังดำเนินอยู่และคอมเมนต์ของผู้ดูแลหลักของ ADB
  • ผู้ดูแลกล่าวถึงกรณีที่แอปใช้ local socket ของ ADBD เพื่อยกระดับสิทธิ์ และเสนอแนวทางให้ bind ADBD เฉพาะกับ interface Wi-Fi อย่าง wlan0
  • ในการหารือสาธารณะควรหลีกเลี่ยงการประท้วงหรือดูหมิ่นแบบลอย ๆ และการโพสต์กรณีใช้งานเดิมซ้ำ ๆ
    • หากมีกรณีใช้งานเฉพาะตัว สามารถแสดงความคิดเห็นอย่างเป็นรูปธรรม โดยรวม workflow, ลิงก์ที่เกี่ยวข้อง และข้อแลกเปลี่ยนทางเทคนิค
    • หากมีกรณีเดียวกันลงไว้แล้ว แนะนำให้ใช้ +1 และฟีเจอร์แจ้งเตือน แทนการคอมเมนต์ซ้ำ
    • หากมีคอมเมนต์คุณภาพต่ำจำนวนมาก issue อาจถูกล็อก หรือทำให้ feedback ที่เป็นประโยชน์และการอัปเดตสาธารณะลดลง

วิธีเชื่อมต่อ ADB สามแบบ

  • ADB เป็นโปรโตคอลที่ให้การเข้าถึงคำสั่งด้วยสิทธิ์สูงแก่ developer และ power user สำหรับทดสอบและจัดการอุปกรณ์ Android
  • วิธีเชื่อมต่อหลักแบ่งเป็นสามแบบ
    • USB: วิธีดั้งเดิมที่เชื่อมต่อจากคอมพิวเตอร์แยกต่างหากไปยังอุปกรณ์โดยตรงผ่านสาย USB
    • ADB TCP/IP: โดยทั่วไปใช้พอร์ต 5555 ส่งทราฟฟิกแบบ plaintext และยืนยันตัวตนผ่านหน้าต่างอนุมัติ YES/NO ต้องมีการเชื่อมต่อ ADB เดิมอยู่ก่อนจึงจะเปิดใช้ได้
    • Wireless Debugging: เปิดตัวใน Android 11 โดย pairing คอมพิวเตอร์ด้วยโค้ดหรือ QR code แล้วสร้างการเชื่อมต่อที่ยืนยันตัวตนและเข้ารหัส ไม่จำเป็นต้องมีการเชื่อมต่อ ADB เดิมเพื่อเปิดใช้

อีโคซิสเต็มที่ ADB ภายในอุปกรณ์สร้างขึ้น

  • ADB ทั่วไปเชื่อมต่อระหว่าง ADBD ของอุปกรณ์ Android กับ ADB client บนคอมพิวเตอร์สำหรับพัฒนาแยกต่างหาก แต่ก็มี developer ที่ทำงานโดยตรงบนอุปกรณ์ Android โดยไม่ใช้คอมพิวเตอร์
  • ADB ภายในอุปกรณ์ (On-Device ADB) ไม่ใช่คำทางการ หมายถึงวิธีรัน ADB client ใน terminal emulator เช่น Termux เพื่อเชื่อมต่อกับ ADBD บนอุปกรณ์เดียวกัน
    • ใช้ ADB TCP/IP หรือ Wireless Debugging
    • เนื่องจาก client และ server อยู่บนอุปกรณ์เดียวกัน จึงผ่านที่อยู่ loopback 127.0.0.1
  • วิธีนี้กลายเป็นพื้นฐานของโปรเจกต์โอเพนซอร์สสำหรับ developer และ power user เช่น libadb-android, Shizuku
  • ShizuCallRecorder เป็นแอปที่ใช้ Shizuku เป็นพื้นฐาน สร้างขึ้นเพื่อลดความลำบากในชีวิตประจำวันจากความพิการ
    • ผู้ใช้รายหนึ่งใช้แอปนี้เพื่อเก็บรักษาข้อความเสียงของสมาชิกครอบครัวที่เสียชีวิต
    • การบันทึกสายบน Android เป็นสิ่งที่ผู้ใช้ร้องขอกันมาก และเคยมีการผลักดันให้เป็นฟีเจอร์ทางการใน Android 11 ก่อนจะถูกยกเลิก ปัจจุบันยังมีแอปทางอ้อมที่เป็นระบบปิดหรืออาจละเมิดความเป็นส่วนตัวอยู่
    • OEM บางรายบังคับให้มีเสียงแจ้งเตือนการบันทึกสาย แม้ในภูมิภาคที่กฎหมายไม่ได้กำหนด

คำขอเลือก interface และข้อจำกัด wlan0

  • จุดประสงค์เดิมของคำขอฟีเจอร์ใหม่นี้คือให้ developer สามารถ เลือก network interface ที่ ADBD จะรับฟังได้
  • เบื้องหลังคือ CVE-2026-0073 ซึ่งเคยทำให้ bypass กระบวนการยืนยันตัวตนของ Wireless ADB ได้ทั้งหมด
  • ปัจจุบัน ADBD เข้าถึงได้จากทุกเครือข่ายที่โทรศัพท์เชื่อมต่ออยู่ ดังนั้นฟีเจอร์เลือก interface เองสามารถลดขอบเขตการเปิดเผยได้
  • แต่หากอนุญาตเฉพาะ wlan0 การตั้งค่าต่อไปนี้อาจเสียหาย
    • ADB ภายในอุปกรณ์ที่ใช้ loopback
    • ADB ผ่าน VPN
    • ADB ผ่าน Ethernet
    • สภาพแวดล้อมการพัฒนาเฉพาะทางอื่น ๆ
  • นักพัฒนา Android ก็เคยมีกรณี ใช้ ADB ภายในอุปกรณ์ เมื่อไม่สามารถเข้าถึงคอมพิวเตอร์ได้

ข้อจำกัดที่แอปอันตรายต้องฝ่าข้าม

  • แม้ ADB ภายในอุปกรณ์อาจถูกใช้เพื่อยกระดับสิทธิ์ได้ แต่โดยทั่วไปแอปอันตราย ไม่สามารถสร้างการเชื่อมต่อได้ด้วยตัวเอง

  • ผู้ใช้ Android ทั่วไป

    • หาก ADB ถูกปิดใช้งาน ADBD จะไม่ทำงาน
    • แอปอันตรายไม่มีสิทธิ์ WRITE_SECURE_SETTINGS ซึ่งต้องมอบให้ด้วยตนเองผ่าน ADB จึงยากที่จะพยายามโจมตีผ่าน ADB

  • Developer ที่ใช้ Wireless ADB บน Android 11 ขึ้นไป

    • ผู้ใช้ต้องเปิด USB debugging และ Wireless ADB ด้วยตนเอง ADBD จึงจะรับฟังบน network interface
    • หากแอปต้องการเชื่อมต่อ ผู้ใช้ต้องนำ รหัส pairing แบบใช้ครั้งเดียว จากหน้าการตั้งค่ามาให้ ดังนั้นแอปเพียงอย่างเดียวจึงเชื่อมต่อไม่ได้

  • Developer ที่ใช้ ADB TCP/IP

    • ผู้ใช้ต้องเปิด USB debugging, เปิดใช้ TCP/IP ผ่าน USB ADB แล้วถอดสายออก
    • เมื่อแอปเริ่มการเชื่อมต่อ หน้าต่างอนุมัติจะแสดงบนหน้าจอ และหากผู้ใช้เลือก No ก็จะถูกปฏิเสธ
    • ในสถานะยืนยันตัวตนปกติ แอปไม่สามารถเชื่อมต่อและโจมตีโดยที่ผู้ใช้ไม่รู้ตัวได้

ความเสี่ยงจากช่องโหว่และขอบเขตการบล็อก

  • ในสถานการณ์ปกติ แอปอันตรายไม่สามารถเริ่ม ADBD โดยตรงได้ โอกาสเชื่อมต่อจึงเกิดขึ้นเฉพาะเมื่อ developer กำลังใช้ ADB บนอุปกรณ์
  • หากมีช่องโหว่ที่ bypass การยืนยันตัวตนได้ เช่น CVE-2026-0073 ก็อาจถูกใช้โจมตีในสภาพแวดล้อม Wireless ADB และ TCP/IP
    • ถึงอย่างนั้น ผู้ใช้ยังต้อง เปิด USB debugging ด้วยตนเอง ก่อน
    • วิธี TCP/IP ยังต้องให้ผู้ใช้เปิด ADB TCP/IP เองด้วย
  • ต้องแยกความแตกต่างระหว่างมาตรการบล็อกการเชื่อมต่อ loopback เป็นค่าเริ่มต้น กับการบล็อกถาวรที่ผู้ใช้ไม่สามารถปลดได้
  • การกำหนด device administrator หรือสิทธิ์ accessibility ก็อาจถูกมอบให้แอปอันตรายผ่านการดำเนินการของผู้ใช้ได้เช่นกัน แต่ไม่ได้ลบฟีเจอร์นั้นออกเพียงเพราะความเป็นไปได้นี้

ทางออกประนีประนอมที่ยังให้ผู้ใช้เลือกได้

  • การบล็อก loopback ควรเป็น การตั้งค่าแบบคงอยู่ ที่ผู้ใช้ปิดได้อย่างชัดเจน
    • ต้องคงอยู่หลังรีบูตเพื่อให้ใช้งานเครื่องมืออย่าง Shizuku ได้จริง
    • หากเป็นไปได้ แอป third-party ไม่ควรอ่านสถานะการตั้งค่าได้ เพื่อไม่ให้ต้องตั้งค่าซ้ำ ๆ เพื่อหลีกเลี่ยงการตรวจจับของแอปธนาคารหรือเกม
    • หากมอบสิทธิ์ WRITE_SECURE_SETTINGS ให้แอปด้วยตนเอง ก็สามารถเลี่ยงข้อจำกัดบางส่วนได้
  • โครงสร้างที่เหมาะสมคือให้ผู้ใช้ปิดฟีเจอร์ความปลอดภัยและอนุญาตการ debugging ภายในอุปกรณ์ได้ พร้อมยอมรับความเสี่ยงที่จะเปิดรับช่องโหว่ในอนาคต
  • หากบล็อก ADB ภายในอุปกรณ์อย่างถาวร อีโคซิสเต็มโอเพนซอร์สเฉพาะกลุ่มต่อไปนี้จะได้รับผลกระทบ

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

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

 
unsure4000 1 시간 전

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

  • โดยรวมเห็นด้วยกับการปรับปรุงความปลอดภัย แต่กรณีนี้ดูแทบไม่มีประโยชน์จริง การโจมตีนี้จะเกิดขึ้นได้ก็ต่อเมื่อผู้ใช้เปิดทั้ง การตั้งค่านักพัฒนาและ ADB ระยะไกล ดังนั้นสำหรับ 99.9% จึงไม่ใช่ช่องทางโจมตีที่เกิดขึ้นได้จริง และอีก 0.1% ที่เหลือก็มักรู้ว่าตัวเองกำลังทำอะไรอยู่
    การเปลี่ยนให้จำกัดการเข้าถึงตามอินเทอร์เฟซหรือ IP เป็นเรื่องดี แต่แค่ให้ฝั่งนักพัฒนาจำกัดไว้ที่ localhost ได้ก็พอ รู้สึกแรงมากว่ากำลังพยายามบล็อก Shizuku กับ Canta โดยทำเหมือนเป็นความเสียหายข้างเคียง

    • ตอนนี้ในโลกซอฟต์แวร์ ความปลอดภัยแทบเป็นหายนะ แล้ว ทุกเว็บเล็กๆ ก็ขอ 2FA บังคับ ออกจากระบบทุกไม่กี่ชั่วโมง และต่อให้พิมพ์ disable sandbox เพื่อจะรัน agent แบบไม่จำกัดโหมด บนมือถือก็ยังใช้ไม่ได้
      ใน Firefox ก็ลงส่วนขยายที่ไม่ได้เซ็นไม่ได้เลย ต้องใช้ Developer Edition เว็บไซต์ต่างๆ ก็ยัดเยียด passkey ให้ใช้ แม้แต่ S3 bucket เดียวก็มีทั้ง access control, service identity, IAM, OAuth ซ้อนกันเป็นสิบชั้น ยังมี OAuth ที่ใช้กับอุปกรณ์ headless ไม่ได้ ธนาคารที่บังคับใช้แอปเฉพาะแทน TOTP การบล็อก VPN การสอดส่องตัวตนจริงโดยอ้างคุ้มครองเด็ก และความพยายามจะแบนโมเดล open-weight เพราะกลัวว่าข้อมูลจะไหลไปจีน
      ความปลอดภัยกลายเป็นคุณค่าสัมบูรณ์ที่มาก่อน ความสะดวก การใช้งาน ความเป็นส่วนตัว ความสามารถในการดัดแปลง และความเปิดกว้าง เสมอ ซึ่งวงการ IT security ควรละอายใจกับเรื่องนี้
    • แค่การตั้งค่านักพัฒนาและ ADB ระยะไกลยังไม่พอด้วยซ้ำ Android build ทั่วไปจะให้ผู้ใช้ อนุมัติคีย์ของไคลเอนต์ อีกครั้งตอนเชื่อมต่อ
      การเปลี่ยนครั้งนี้ดูเหมือนทำเพื่อปกป้อง ผลประโยชน์ขององค์กร มากกว่าความปลอดภัยของผู้ใช้
    • หลังยุค iPhone การเปลี่ยนหลายอย่างที่ถูกห่อหุ้มว่าเป็นฟีเจอร์ความปลอดภัย แท้จริงแล้วคือ การตัดความสามารถของอุปกรณ์ทิ้ง
      ช่วงแรกๆ ยังถึงขั้นบอกให้ใช้แค่ Safari โดยไม่ต้องมี app store และผมมองว่าต้นตอคือความยึดติดแบบเฉพาะตัวของ Steve Jobs ที่ถึงขั้นไม่อยากให้อุปกรณ์การแพทย์ที่ดีไซน์ไม่สวยมาแตะตัว แม้ตอนรักษามะเร็ง ท่าทีที่ไม่อยากให้สิ่ง “สกปรก” มาแตะอุปกรณ์ที่ “สมบูรณ์แบบ” ถูกทำให้ชอบธรรมย้อนหลังด้วยภาษาด้านความปลอดภัย
      ตอนนั้นมีเหตุผลว่าต้องเลี่ยงสภาพแบบ Windows 98 ที่เต็มไปด้วยมัลแวร์ แต่ระบบปฏิบัติการสมัยใหม่ก็เลยระดับความปลอดภัยอ่อนแอแบบ Windows ยุคนั้นไปไกลมากแล้ว
    • ผมเคยเป็นนักพัฒนาที่แจกจ่ายแอป Android และตอนหน้าจอพังผมก็เคยเข้าเครื่องตัวเองไม่ได้ เพราะ สวิตช์ ADB ระยะไกล ที่ยุ่งยากดันปิดอยู่ กรณีที่ทั้งการตั้งค่านักพัฒนาและ ADB ระยะไกลเปิดพร้อมกันนั้นพบได้น้อยมากในสภาพใช้งานจริง จนแทบมองข้ามในฐานะช่องทางโจมตีได้เลย
    • คำว่า “ผู้ไม่หวังดีไม่สามารถได้การเชื่อมต่อ ADB ในสถานการณ์ปกติ” จะจริงหรือไม่ก็ขึ้นกับว่าคุณนิยามผู้ไม่หวังดีว่าอย่างไร
      เป้าหมายของการบล็อกเครื่องมือความเป็นส่วนตัวแบบไม่ต้องรูตที่อิง Shizuku ไม่ได้มีไว้เพื่อความปลอดภัยของเจ้าของเครื่อง แต่เพื่อ ความปลอดภัยของรัฐ แอป trusted execution environment อย่าง EU Digital Identity Wallet และฟีเจอร์ที่ในอนาคตจะถูกเรียกร้องโดยอ้างคุ้มครองเด็ก ต่างพึ่งพาสมมติฐานอย่างมากว่าผู้ใช้จะดัดแปลงอุปกรณ์หรือไม่สามารถติดตั้งซอฟต์แวร์ที่ไม่ได้รับอนุมัติได้ ทุกคนก็รู้กันอยู่แล้วว่า Intel SGX ลงเอยอย่างไร

  • การ จำกัด ADB เป็นก้าวถัดไปที่หลีกเลี่ยงไม่ได้ ต่อให้ข้อเสนอนี้ไม่ผ่านแบบเดิม Google ก็ทำให้แม้แต่งานคอมพิวเตอร์ส่วนบุคคลทั่วไปยังต้องพึ่งอินเทอร์เฟซนักพัฒนาภายในเครื่อง หรือผ่าน USB/ไร้สาย
    สักวันหนึ่งอาจต้องยืนยันตัวตน จ่ายค่าธรรมเนียมรายปี ไม่เช่นนั้นก็จะถูกจำกัดการใช้งาน Android อย่างหนัก Google ไม่ต้องการให้มีการพัฒนาแอป Android นอกช่องทางจัดจำหน่ายที่ควบคุมไว้ และเราก็แพ้ไปแล้วตั้งแต่ตอนที่มันไม่ยอมถอยจากการเปลี่ยนแปลงที่แบน sideloading แบบปกติและถูกกฎหมาย
    คำเตือนบันทึกเสียงสนทนาก็เป็นความรับผิดชอบของ Google พอผู้ผลิตหันมาใช้ Google Dialer แทน dialer ของตัวเองที่ดีกว่า มันก็ถูกบังคับใช้แบบเหมารวมแม้ในพื้นที่ที่ไม่มีกฎหมายบังคับ โดยเฉพาะบน MediaTek SoC ที่ไม่รองรับการบันทึกผ่านแอป third-party ที่เสถียรในระดับฮาร์ดแวร์ เรื่องนี้ยิ่งน่ารำคาญ
    สุดท้ายมันก็เป็นหลักฐานว่าคุณไม่ได้เป็นเจ้าของอุปกรณ์ “ของคุณ” จริงๆ และอีกไม่กี่ปี Gemini อาจจะมานั่งฟังสายแล้วสรุปให้ผ่านช่องทางสอดส่องที่ได้รับอนุมัติก็ได้

    • ของผมไม่เหมือนกัน โพสต์นี้ส่งมาจาก GNU/Linux smartphone Librem 5
    • ถ้าคุณติดตั้งระบบปฏิบัติการของตัวเองได้ ก็แปลว่าคุณเป็นเจ้าของอุปกรณ์นั้น Google อนุญาตเรื่องนี้มาโดยตลอด ดังนั้นความโกรธควรถูกส่งไปที่ผู้ผลิตรายอื่นที่ขัดขวางมัน

  • สงสัยว่ามี ทางเลือกอื่น สำหรับการใช้งานที่ชอบธรรมหรือไม่ ถ้าตัดฟังก์ชันออกโดยไม่ให้ทางเลือก นักพัฒนาก็จะถูกผลักไปใช้วิธีอ้อมที่เปราะบางกว่า หรือบางครั้งก็ผิดกฎด้วย

  • ปฏิกิริยาครั้งนี้ดูเหมือนเป็นการตอบสนองเกินเหตุครั้งใหญ่ที่เกิดจากความเข้าใจผิด ตอนนี้ผมใช้ remote ADB ติดตั้ง build ใหม่ของโปรเจกต์ Android ระหว่างพัฒนา ดึง log และเชื่อมต่อผ่าน Tailscale VPN
    แต่รูปแบบปัจจุบันอาจเปิดช่องให้ทุก public Wi‑Fi ที่เชื่อมต่ออยู่โจมตีได้แม้ก่อนการยืนยันตัวตน ถ้าจำกัดได้ เฉพาะอินเทอร์เฟซของ Tailscale กลับจะยิ่งดีขึ้น
    แกนของข้อเสนอคือ เวลาตั้งค่า remote ADB ให้ระบุอินเทอร์เฟซที่จะ bind แทนการเปิดทุกอินเทอร์เฟซ ไม่ได้มีอะไรบอกว่าจะปฏิเสธ localhost และข้อเสนอสั้นๆ ที่จะ bind แค่ wlan0 ก็ชัดเจนว่าไม่ถูกต้องเพราะน่าเชื่อถือน้อยกว่า VPN และคงไม่ใช่ทิศทางการติดตั้งใช้งานจริง

  • ต่อให้พวก spam thread จนวิศวกร Google ปิด issue และไม่สนใจ feedback ก็ไม่ได้ทำให้สถานการณ์ต่างจากตอนนี้อยู่ดี ถ้ารู้สึกว่าคำวิจารณ์น่ารำคาญจนถึงขั้น ปิดกั้น feedback ที่มีคุณค่าได้ด้วย ก็แสดงการเห็นด้วยกันไปได้เลย

    • ต้องแยกการวิจารณ์นโยบายออกจาก การถล่มแบบม็อบของชาว Reddit
    • สมมติฐานของโพสต์ที่เหมือนจะบอกว่าวิศวกร Google แค่พลาดหรือเข้าใจ use case สำคัญผิดไป และถ้ามีคนบอกก็จะกลับมาทบทวนนั้น พูดตรงๆ ว่าดูหมิ่นมาก
    • ทันทีที่โพสต์แบบนี้ไปโผล่บน HN หรือ Reddit โอกาสที่จะเปลี่ยนความคิดใครสักคนก็แทบหายไป และ GitHub issue ก็คงโดนถล่มตามมาในไม่ช้า
      Google อาจฟัง feedback จากนักพัฒนาแอปอยู่บ้าง แต่เป็นธรรมดาที่จะให้น้ำหนักกับการตัดสินใจของทีมภายในมากกว่านักพัฒนาโอเพนซอร์สที่พึ่งพาลูกเล่นแบบนี้
      ชัดเจนอยู่แล้วว่า ADB daemon ไม่ได้ถูกออกแบบมาเพื่อให้แอปเปิด ADB session ไปยัง loopback address เพื่อทำการบันทึกเสียงสนทนา https://xkcd.com/1172/ ผุดขึ้นมาในหัวอีกครั้ง
      ไม่ได้หมายความว่านักพัฒนาที่ไม่ชอบการเปลี่ยนแปลงนี้เป็นฝ่ายผิด Google เองก็เพิ่มการบันทึกเสียงสนทนาเข้าไปใน dialer แล้ว จึงสนับสนุนตัวฟีเจอร์นี้อยู่ แต่ก็ไม่ได้แปลว่าทีม ADB ไม่ควรทำ การเสริมความปลอดภัย เช่นกัน

  • ตอนที่ Google ประกาศจำกัดการ sideloading ครั้งแรก ก็มีคนบอกว่า “ยังมี ADB อยู่” และคนที่คัดค้านเรื่องนี้ก็ถูกวิจารณ์อย่างหนัก
    ตอนนี้ต้องรอแม้แต่ช่องทางอ้อมในการเปิดใช้ ADB และ Android ก็ไม่ได้เปิดกว้างกว่า iOS มานานแล้ว แนวโน้มนี้จะดำเนินต่อไป
    เพราะนี่เป็นปัญหาที่ไม่ใช่ด้านเทคนิคในวิธีคิดของ Google จึงแก้ด้วยวิธีทางเทคนิคไม่ได้

    • ทันทีที่นำhardware remote attestationมาใช้ Android ก็แทบหมดหวังไปแล้ว
      ถึงจะติดตั้งซอฟต์แวร์ของตัวเองได้ ก็ยังถูกมองว่าเป็นอุปกรณ์ที่ “ถูกดัดแปลง” หากไม่ผ่านการรับรอง ก็จะไม่ได้รับความเชื่อถือและกลายเป็นพลเมืองชั้นสองที่ถูกกันออกจากแทบทุกด้านของสังคมดิจิทัล เช่น การสื่อสาร ธนาคาร สตรีมมิง และเกม
      นี่คืออนาคตของ Android และเพราะบางบริษัทเริ่มเชื่อถือคีย์การรับรองของ GrapheneOS อย่างน่าอัศจรรย์ GrapheneOS จึงเป็นความหวังสุดท้าย หากความหวังนี้หายไป สู้ซื้อ iPhone เสียยังดีกว่า
    • เส้นที่ควบคุมวิธีคิดแบบนี้ทอดยาวไปไกลกว่าผู้บริหารและบอร์ดของ Google มาก จนนึกถึง OBEY ในงานคลาสสิกของ Carpenter

  • มันเป็นเรื่องที่ต้องเกิดขึ้นอยู่แล้ว คงถึงขั้นที่ถ้าต่อไปข้อจำกัด sideloading 24 ชั่วโมงถูกเปลี่ยนเป็นไม่มีกำหนด คนก็ยังจะตกใจ

    • ความเป็นไปได้ที่จะเปลี่ยนเป็นการจำกัดแบบไม่มีกำหนด ขึ้นอยู่กับว่าจะมีทางเลือกที่ใช้ได้จริงให้ย้ายไปก่อนหน้านั้นหรือไม่
      ไม่จำเป็นต้องยึดทั้งตลาด แค่พอให้ Google ลังเล หรือทำให้บังคับใช้ได้ยากในทางกฎหมายก็พอ คล้ายบทบาทในอุดมคติของ Firefox ต่อ Chrome

  • การที่ Android ถูกปิดตายถึงระดับนี้เป็นสัญญาณเตือนร้ายแรง กำลังค่อย ๆ เอาสิ่งที่ทำให้ Android ดีออกไปทีละอย่าง

  • กังวลว่าอีกไม่นานเว็บไซต์ก็อาจเจอแบบเดียวกัน หากจะให้เปิดเว็บบนอุปกรณ์ Apple อาจต้องจ่ายค่าธรรมเนียมรายเดือนให้ Apple และบนอุปกรณ์ Android ก็ต้องจ่ายให้ Google

    • reCAPTCHA แบบใหม่ที่บังคับใช้ remote attestation ก็ไปในทิศทางนั้นแล้ว
      https://www.eff.org/deeplinks/2026/07/googles-new-remote-att...
      แม้ตอนนี้จะยังไม่มีค่าธรรมเนียม แต่ Google ก็อาจตัดสินได้แล้วว่าอุปกรณ์แบบใดได้รับอนุญาตให้เข้าถึงเว็บไซต์จำนวนมาก
    • เว็บอาจแยกเป็นสองส่วน คือ เว็บใหม่ที่เว็บใหญ่ระดับบนจ่ายเงินเพื่อใช้งาน และ เว็บเก่าที่เข้าถึงได้เฉพาะคนที่มีพีซีส่วนตัวพร้อมเบราว์เซอร์ที่ไม่ถูกจำกัดติดตั้งอยู่
      คอนเทนต์ของเว็บเก่าก็มีแนวโน้มสูงที่จะถูกบริษัท AI ดูดไปจำนวนมาก แล้วนำไปผลิตซ้ำให้คนทั่วไปผ่านเว็บใหม่
    • ในบริการสตรีมวิดีโออย่าง Netflix ก็คล้ายกันอยู่แล้ว แม้ไม่ต้องจ่ายค่าธรรมเนียมโดยตรง แต่ก็ใช้เบราว์เซอร์โอเพนซอร์สไม่ได้

  • เราต้องการLinux สำหรับสมาร์ตโฟน หากทำธุรกรรมธนาคารผ่านเบราว์เซอร์ได้ ก็ไม่จำเป็นต้องมีแอป แต่ฟังก์ชันสำคัญอย่างอุปกรณ์สื่อสารไร้สายและแอปหลักอย่าง Sonos กับ Spotify ต้องใช้งานได้

    • ตอนนี้ธนาคารหลายแห่งในสหราชอาณาจักรไม่มีทั้งเว็บพอร์ทัลและสาขาออฟไลน์แล้ว
      จำเป็นต้องมีกฎหมายบังคับให้บริการจำเป็นอย่างธนาคารและสาธารณูปโภคมีสภาพแวดล้อมเว็บที่ใช้งานได้จริงตามปกติ ไม่เช่นนั้นโครงสร้างผูกขาดสองขั้วในปัจจุบันก็จะยิ่งฝังแน่น
      ตัวฉันเองก็ควรเลือกและสนับสนุนผู้ให้บริการที่มีบริการผ่านเว็บให้มากกว่านี้
    • การแนะนำ Android, LineageOS หรือ GrapheneOS ไม่เหมาะสม และ Sailfish ก็มีองค์ประกอบปิดจำนวนมากจนควรข้ามไป ตัวเลือกที่ดีที่สุดคือ postmarketOS และ Mobian ฯลฯ ก็พอน่าพิจารณา ส่วน Ubuntu Touch กับ UBports น่าผิดหวัง
      ตรวจดูอุปกรณ์ที่รองรับในวิกิของ postmarketOS ว่ารองรับเครื่องที่มีอยู่แล้วหรือไม่ และถ้าเป็นไปได้ก็ช่วยพัฒนาการรองรับให้ดีขึ้นได้ หากไม่รองรับ ก็หาเครื่องมือสองที่มีสถานะการรองรับดีได้จาก eBay
      Librem 5 กับ PinePhone ถือว่ารองรับได้ดี แต่เครื่อง Android รุ่นเก่าอย่าง OnePlus 6T อาจคุ้มค่ากว่าต่อราคา ควรตรวจสอบก่อนซื้อว่าฟังก์ชันหลักใช้งานได้หรือไม่
      แอป Android ยอดนิยมสามารถรันผ่าน Waydroid ได้
    • ควรเรียกร้องให้เว็บไซต์ธนาคารและแอปเนทีฟมีความเท่าเทียมกันด้านฟังก์ชัน ธนาคารของฉันรองรับการฝากเช็คทางไกลผ่านแอปเท่านั้น และบนอุปกรณ์เก่าแอปก็ใช้ไม่ได้ จนต้องใช้ PayPal
    • สมาร์ตโฟนทุกเครื่องควรมีbootloader ที่ปลดล็อกได้ แบบนั้นถึงจะมีระบบปฏิบัติการเพิ่มขึ้นได้
    • ทุกวันนี้ธนาคารบังคับใช้แอปโดยอ้างเรื่อง “ความปลอดภัย” จนแทบทำธุรกรรมอะไรไม่ได้เลยหากไม่มีแอป
      ทางเลือกอย่างการยืนยันตัวตนผ่าน SMS ก็ไม่ปลอดภัยและกำลังหายไป ซึ่งถูกต้องในแง่ความปลอดภัย แต่ก็ยังขาดวิธีอื่นที่ใช้งานได้