การรับรองฮาร์ดแวร์ในฐานะผู้ช่วยผูกขาด

 (grapheneos.social)
2 คะแนน โดย GN⁺ 9 시간 전 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • Apple และ Google กำลังขยายการใช้ การรับรองที่อิงฮาร์ดแวร์ เพื่อผลักดันให้บริการต่าง ๆ นำไปใช้มากขึ้น และในระยะยาวก็ยิ่งเสริมโครงสร้างที่กีดกันฮาร์ดแวร์และระบบปฏิบัติการที่ไม่ได้รับการอนุมัติออกจากการแข่งขัน
  • Google Play Integrity API และ Apple App Attest API ทำงานในลักษณะคล้ายกัน โดย Play Integrity ต้องการการรับรองฮาร์ดแวร์ในระดับ strong integrity และกำลังมุ่งไปสู่การค่อย ๆ บังคับใช้กับ device integrity ด้วย
  • Apple Privacy Pass, Web Environment Integrity ที่ Google ยกเลิกไปแล้ว และ reCAPTCHA Mobile Verification กำลังดึงข้อกำหนดด้านการรับรองเข้าสู่เว็บ ซึ่งอาจทำให้การเข้าถึงบริการเว็บถูกบล็อกได้หากไม่มีอุปกรณ์ iOS หรือ Android ที่ผ่านการรับรอง
  • Play Integrity API แบน GrapheneOS แม้ว่าจะปลอดภัยกว่าระบบที่ได้รับอนุญาตเสียอีก และยังอนุญาตให้อุปกรณ์ที่ไม่ได้รับแพตช์ความปลอดภัยมา 10 ปีใช้งานได้ ทำให้เห็นชัดว่าจุดประสงค์เด่นกว่าด้านความปลอดภัยคือการออกใบอนุญาต Google Mobile Services และการกีดกันการแข่งขัน
  • เมื่อบริการภาครัฐและธนาคารต้องการใช้ App Attest และ Play Integrity มากขึ้นเรื่อย ๆ ก็เท่ากับบังคับใช้อุปกรณ์ Apple หรือ Android ที่ได้รับการรับรองจาก Google โดยพฤตินัย และอาจกระทบแม้แต่การเข้าถึงเว็บจากสภาพแวดล้อมอย่าง Windows, เดสก์ท็อป Linux และ FreeBSD

ข้อกำหนดด้านการรับรองที่กำลังขยายไปสู่เว็บ

  • Privacy Pass ของ Apple นำการรับรองฮาร์ดแวร์เข้าสู่เว็บเพื่อช่วยให้อุปกรณ์ของตนผ่าน CAPTCHA ได้
  • ในเวลานั้นมีคนจำนวนมากมองว่าไม่เป็นอันตราย เพราะเชื่อว่าไม่น่าจะมีเว็บไซต์จำนวนมากที่บล็อกผู้ใช้ที่ไม่ได้ใช้อุปกรณ์ Apple
  • ทั้ง Apple และ Google มีแนวโน้มสูงที่จะนำการรับรองฮาร์ดแวร์ในวงกว้างกว่านี้เข้าสู่เว็บ
  • บริการธนาคารและภาครัฐกำลังบังคับให้ใช้แอปมือถือมากขึ้นเรื่อย ๆ และสามารถใช้การรับรองภายในแอปเพื่อบังคับใช้อุปกรณ์และระบบปฏิบัติการที่ Apple หรือ Google อนุมัติ
  • Privacy Pass ของ Apple, Web Environment Integrity ที่ Google ยกเลิกไปแล้ว และ reCAPTCHA Mobile Verification กำลังนำแนวโน้มนี้มาสู่เว็บ
  • รายงานปัจจุบันเกี่ยวกับ reCAPTCHA Mobile Verification ยังไม่สะท้อนผลกระทบและนัยสำคัญของมันอย่างเหมาะสม
  • วิธีนี้กำหนดให้ต้องสแกน QR ด้วยสมาร์ตโฟนที่ผ่านการรับรองเพื่อผ่าน reCAPTCHA ในบางสถานการณ์ ทำให้ ข้อกำหนดด้านการรับรองฮาร์ดแวร์ ถูกนำมาสู่ Windows, เดสก์ท็อป Linux, OpenBSD และระบบอื่น ๆ ด้วย
  • ด้วยการควบคุม reCAPTCHA ของ Google บริษัทจึงอยู่ในตำแหน่งที่จะทำให้ผู้ใช้ต้องมีอุปกรณ์ iOS หรือ Android ที่ผ่านการรับรองจึงจะใช้งานเว็บส่วนมหาศาลได้
  • Google เป็นผู้กำหนดข้อกำหนดการรับรอง Android ซึ่งรวมถึงการบังคับพ่วง Google Chrome ด้วย
  • ขณะนี้ reCAPTCHA Mobile Verification ใช้งานร่วมกับ Google Play แบบแซนด์บ็อกซ์ของ GrapheneOS ได้ แต่มีอยู่เพื่อเป็นช่องทางในการเริ่มนำสิ่งนี้ไปใช้กับระบบที่ไม่มีการรับรองฮาร์ดแวร์ด้วย
  • เมื่อข้อกำหนดนี้ถูกนำมาใช้ ผู้ที่ไม่มีอุปกรณ์ iOS หรือ Android ก็อาจถูกบล็อกได้แม้ไม่มีเงื่อนไขเพิ่มเติมใด ๆ

Play Integrity และการกีดกัน GrapheneOS

  • Play Integrity API ของ Google ห้ามการใช้งาน GrapheneOS แม้ว่าจะปลอดภัยกว่าทุกระบบที่ได้รับอนุญาตก็ตาม
  • Play Integrity API ยังห้ามทางเลือกอื่นด้วย และนี่ไม่ใช่ปัญหาที่จำกัดอยู่แค่ระบบปฏิบัติการที่อิง AOSP
  • แม้จะใช้ระบบปฏิบัติการมือถือที่อิง FreeBSD ก็หลีกเลี่ยงปัญหานี้ไม่ได้ และจะยิ่งถูกกีดกันมากขึ้นเท่านั้น
  • Play Integrity API อนุญาตให้อุปกรณ์ที่ไม่ได้รับแพตช์ความปลอดภัยมา 10 ปีใช้งานได้
  • ระดับ device integrity สามารถเลี่ยงได้ด้วยการปลอมแปลง แต่ Google สามารถตรวจจับและบล็อกได้ค่อนข้างมีประสิทธิภาพหากมีการใช้งานในวงกว้าง
  • การเลี่ยงระดับ strong integrity ต้องใช้กุญแจที่รั่วไหลจาก TEE หรือ SE
  • Play Integrity API ไม่ได้ปลอดภัยมากนัก และก็ไม่ได้ยากเป็นพิเศษที่จะเลี่ยงได้ชั่วคราว
  • มีเฟรมเวิร์กสำหรับปลอมผลการตรวจสอบซอฟต์แวร์ และยังสามารถซื้อกุญแจที่รั่วไหลเพื่อหลบเลี่ยงการรับรองฮาร์ดแวร์ได้
  • อย่างไรก็ตาม การหลบเลี่ยงกำลังยากขึ้นเรื่อย ๆ และระยะเวลาที่ใช้ได้ผลก็กำลังสั้นลงเรื่อย ๆ
  • Play Integrity ไม่ได้มอบคุณสมบัติด้านความปลอดภัยที่มีประโยชน์ แต่กลับทำงานได้ดีมากในการกีดกันการแข่งขัน
  • บริการที่บังคับใช้ Apple App Attest หรือ Google Play Integrity โดยหลักแล้วกำลังช่วยให้ Apple และ Google รักษา การครองตลาดแบบสองราย บนอุปกรณ์มือถือไว้
  • เหตุผลที่ Play Integrity สำคัญกว่าคือ AOSP เป็นโอเพนซอร์ส
  • GrapheneOS สามารถตรวจสอบได้ผ่านการรับรองฮาร์ดแวร์ และเหตุผลที่ Google แบน GrapheneOS ใน Play Integrity ก็เพราะ GrapheneOS ไม่ได้ขอใบอนุญาต Google Mobile Services และไม่ทำตามกฎต่อต้านการแข่งขัน
  • กฎดังกล่าวเคยถูกตัดสินว่าผิดกฎหมายแล้วในบางประเทศรวมถึงเกาหลีใต้
  • บริการไม่ควรห้ามการใช้ฮาร์ดแวร์และระบบปฏิบัติการตามอำเภอใจ
  • เมื่อ Google อนุญาตให้อุปกรณ์ที่ไม่ได้รับแพตช์มา 10 ปีใช้งานได้ แต่ไม่อนุญาตระบบปฏิบัติการที่ปลอดภัยกว่ามาก ก็ยากจะอ้างเหตุผลด้านความปลอดภัยได้
  • นี่คือการใช้การออกใบอนุญาต GMS เพื่อบังคับใช้การผูกขาด

บริการภาครัฐ·ธนาคาร และบทบาทของกฎระเบียบ

  • ภาครัฐกำลังกำหนดให้ใช้ Apple App Attest และ Google Play Integrity มากขึ้นเรื่อย ๆ ไม่เพียงกับบริการของตนเอง แต่รวมถึงบริการเชิงพาณิชย์ด้วย
  • สหภาพยุโรปกำลังเป็นผู้นำแนวโน้มในการนำข้อกำหนดเหล่านี้ไปใช้กับการชำระเงินดิจิทัล การยืนยันตัวตน และการยืนยันอายุ
  • แอปของรัฐบาลหลายแห่งในสหภาพยุโรปมีข้อกำหนดเหล่านี้อยู่แล้ว
  • แทนที่รัฐบาลจะหยุดยั้งพฤติกรรมต่อต้านการแข่งขันอย่างรุนแรงของ Apple และ Google กลับมีส่วนร่วมโดยตรงในการกีดกันการแข่งขันผ่านบริการของตนเอง
  • การบังคับให้ผู้คนต้องมีอุปกรณ์ Apple หรือ Android ที่ผ่านการรับรองจาก Google ไม่ใช่เรื่องความปลอดภัย แต่เป็น การจำกัดการแข่งขัน
  • ปัญหาที่การเข้าถึงบริการธนาคาร บริการภาครัฐ หรือแม้แต่การผ่าน reCAPTCHA บางแบบ ต้องใช้อุปกรณ์ iOS ที่ไม่ถูกดัดแปลง หรือ Android ที่มี Google Mobile Services ไม่ได้เป็นปัญหาเฉพาะของ GrapheneOS
  • สิ่งนี้ส่งผลเหมือนกันต่อ Windows, เดสก์ท็อป Linux, FreeBSD และแพลตฟอร์มอื่น ๆ
  • นี่ไม่ใช่ปัญหาเฉพาะของ Pixel, อุปกรณ์ Android หรือระบบปฏิบัติการที่อิง AOSP และยังอาจกระทบต่อการเข้าถึงเว็บบนเดสก์ท็อปด้วย

Android Attestation API และ Unified Attestation

  • Android มีระบบการรับรองฮาร์ดแวร์มาตรฐานที่รองรับระบบปฏิบัติการทางเลือก โดยอนุญาตให้ใช้ลายนิ้วมือกุญแจบูตที่ผ่านการตรวจสอบแล้ว
  • การรับรองฮาร์ดแวร์ของ Android ใช้ root of trust ของ Google และบริการ remote key provisioning เป็นหลัก แต่ตัว API เองรองรับ root of trust ทางเลือก
  • การรับรองฮาร์ดแวร์ของ Android ไม่ควรถูกใช้เพื่อกีดกันผู้ใช้ที่ไม่ได้ใช้ฮาร์ดแวร์หรือระบบปฏิบัติการแบบใดแบบหนึ่ง
  • อย่างไรก็ตาม ความสามารถในการอนุญาต root of trust และระบบปฏิบัติการตามอำเภอใจ ก็เปิดช่องให้บริการสามารถอนุญาตกลุ่มเป้าหมายได้กว้างขึ้น
  • หาก Google ทำไปเพื่อความปลอดภัยจริง ก็สามารถใช้ระบบเดียวกันนี้เพื่ออนุญาต GrapheneOS ใน Play Integrity ได้
  • Unified Attestation เป็นอีกระบบหนึ่งที่มีลักษณะต่อต้านการแข่งขัน ซึ่งกำลังถูกผลักดันโดยหลายบริษัทในยุโรป และจะกีดกันผู้ใช้ฮาร์ดแวร์และซอฟต์แวร์ตามอำเภอใจในลักษณะคล้ายกัน
  • Unified Attestation ไม่ใช่คำตอบ และแย่กว่ามากเมื่อเทียบกับ Android hardware attestation API ที่เปิดกว้างกว่ามาก
  • Unified Attestation ของ Volla ถูกสร้างขึ้นทั้งหมดบน Android hardware attestation API
  • Unified Attestation ของ Volla มีอยู่เพื่อทำให้หน่วยงานกลางและบริการเป็นผู้ควบคุมว่าอะไรได้รับอนุญาตบ้าง

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

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

 
unsure4000 7 시간 전

ฉันชอบ Google มากจนอยากให้มีสักห้าอันเลย🥰
 
GN⁺ 9 시간 전
ความเห็นจาก Hacker News

  • EU Digital Identity Wallet (EUDI) กำหนดให้ต้องใช้การรับรองฮาร์ดแวร์จาก Google หรือ Apple ซึ่งในทางปฏิบัติคือผูกอัตลักษณ์ดิจิทัลทั้งหมดของ EU ไว้กับสองยักษ์ใหญ่สหรัฐ
    เท่ากับว่าพูดเรื่องอธิปไตยดิจิทัล แต่กลับตัดสินใจแบบนี้ และดูเหมือนจะมองว่าการคุ้มครองเด็กสำคัญกว่าอธิปไตย
    https://gitlab.opencode.de/bmi/eudi-wallet/wallet-developmen...

    • นั่นหมายความว่าเพียงประธานาธิบดีสหรัฐกดสวิตช์ครั้งเดียว ก็สามารถปิด Digital Identity Wallet ของ EU ได้
      ไม่เข้าใจเลยว่าทำไมถึงตัดสินใจแบบนี้ตั้งแต่แรก
    • เคยอีเมลไปหาผู้รับผิดชอบฝั่ง EU เรื่องนี้ แต่ได้เพียง คำตอบเชิงสั่งสอน ประมาณว่าแอปเป็นโอเพนซอร์สก็ดีแล้ว
      ดูชัดเจนว่าเป็นคำตอบที่ทำมาให้ผู้ใช้ทั่วไปที่ไม่มีความรู้ทางเทคนิค
    • เข้ามาเพราะคิดคล้ายกัน
      มีคนจำนวนมากพูดถึงอธิปไตยและการลดการพึ่งพาสหรัฐ แต่กลับไม่เห็นแรงคัดค้านที่ใหญ่กว่านี้ เลยอดสงสัยไม่ได้ว่าต้องอธิบายด้วยคำว่า ความไม่รู้ หรือไม่
    • ปัญหาใหญ่ของตัวระบุที่อยู่ในอุปกรณ์คือ มันต้องผูกติดกับอุปกรณ์อย่างแน่นหนาเพราะมีความเสี่ยงถูกคัดลอก
      โดยเฉพาะกับตัวระบุแบบคุ้มครองความเป็นส่วนตัวก็ยิ่งเป็นแบบนั้น จึงทำให้ การรับรองอุปกรณ์ กลายเป็นเรื่องสำคัญ
      ถ้ายืนยันไม่ได้ว่าฮาร์ดแวร์ป้องกันการดึงกุญแจของผู้ใช้ได้ ก็ไม่อาจรับประกันได้ว่ากุญแจยืนยันตัวตนถูกล็อกอยู่ในอุปกรณ์จริง
      ส่วนที่เลวร้ายที่สุดคือ สุดท้ายอาชญากรที่มุ่งมั่นก็จะหาวิธีดึงกุญแจนั้นไปใช้โกงจนได้ และผลลัพธ์คือ โอเพนซอร์สและคอมพิวติ้งแบบเปิด จะถูกทำลาย
    • ถ้าต้องการอัตลักษณ์ที่ปลอดภัย ISO7816 ก็มีอยู่แล้วและเป็นอิสระจาก Big Tech โดยสิ้นเชิง
      อีกประเด็นคือใครบ้างที่ควรถูกขอให้แสดงบัตรยืนยันตัวตน ซึ่งเป็นคนละเรื่องกัน และสำหรับกรณีออนไลน์ล้วน ๆ ส่วนใหญ่ผมมองว่าคำตอบคือ “ไม่” แต่ทางแก้ที่ภาคการเงินเชื่อถือมาหลายสิบปีก็มีอยู่แล้ว

  • แม้แต่การกำหนดให้ใช้ซิลิคอนและซอฟต์แวร์ที่ผ่านการอนุมัติก็ยังไม่ใช่ปัญหาใหญ่ที่สุดตรงนี้
    พวกเขาไม่ได้ใช้ zero-knowledge proofs หรือ blind signatures
    ดังนั้นทุกครั้งที่พิสูจน์ตัวตนด้วยอุปกรณ์ ก็จะทิ้งแพ็กเก็ตการพิสูจน์ที่ใช้เชื่อมโยงพฤติกรรมนั้นเข้ากับอุปกรณ์ได้
    พวกเขาใส่โครงสร้างอ้อม ๆ โดยให้เซิร์ฟเวอร์กลางออก one-time ID จาก device ID แบบคงที่เพื่อทำเหมือนใส่ใจความเป็นส่วนตัว แต่เราไม่รู้ว่าเซิร์ฟเวอร์กลางพวกนั้นทำอะไร ดังนั้นก็ต้องถือว่ามันบันทึกทุกอย่าง
    เส้นทาง remote attestation ก็แย่อยู่แล้ว ส่วนเส้นทาง DRM ID ยิ่งแย่กว่า เพราะไม่มีทางอ้อมที่มีความหมาย ทำให้ทุกไลเซนส์เซิร์ฟเวอร์เข้าถึงอัตลักษณ์คงที่ที่ถูกฝังไว้ในซิลิคอนได้ Google account path ยิ่งไม่ต้องพูดถึง
    ข้อเสนอให้ใช้ blind signatures กับ remote attestation ก็มีอยู่จริง แต่ตอนนี้ยังไม่ถูกใช้ในที่ที่เห็นชัด ๆ: <https://en.wikipedia.org/wiki/Direct_Anonymous_Attestation>
    มีเหตุผลเป็นไปได้หลายอย่าง เหตุผลที่เห็นได้ชัดคือพวกเขาอยากมีความสามารถในการละเมิดความเป็นส่วนตัวเมื่ออยากทำ หรือถูกบังคับให้ต้องมีความสามารถนั้น
    อีกเหตุผลคือ ถ้าเชื่อมโยงการพิสูจน์กับอุปกรณ์เฉพาะเครื่องไม่ได้ มาตรการลดการใช้งานในทางที่ผิดก็แทบเหลือแค่การจำกัดอัตรา ซึ่งอาจไม่เพียงพอตามมาตรฐานของพวกเขา ผู้โจมตีอาจตั้งฟาร์มอุปกรณ์ให้แต่ละเครื่องรับเงินรายชั่วโมงเพื่อให้บริการ remote attestation แก่ผู้ไม่หวังดี

    • ตรงที่ว่า “เมื่อผูกการพิสูจน์กับอุปกรณ์เฉพาะไม่ได้ มาตรการลดการใช้งานในทางที่ผิดที่ทำได้มีแค่การจำกัดอัตรา” ผมยังไม่เข้าใจอยู่ดี
      ไม่รู้ว่าบริการจะ จำกัดอัตรา ไปพร้อมกับรักษาความไม่ระบุตัวตนได้อย่างไร
      ถ้าบริการหนึ่งนับได้ว่าคำขอสองครั้งมาจากผู้กระทำคนเดียวกัน บริการสองแห่งก็สามารถแกล้งทำเป็นบริการเดียวกันเพื่อตรวจได้เหมือนกันว่าคำขอสองครั้งมาจากผู้กระทำคนเดียวกัน แล้วก็เชื่อมโยงกันได้
    • เราควรเลิกทำให้การถูกเฝ้าดูทั้งออนไลน์และบนอุปกรณ์กลายเป็นเรื่องปกติ
      การพูดทำนองว่า “ปัญหาไม่ใช่ hardware attestation แต่คือการไม่ใช้ zero-knowledge proofs” คือการทำให้พฤติกรรมแบบใหม่กลายเป็นเรื่องปกติ
      ซึ่งไม่ควรทำ ไม่ว่าจะใช้ zero-knowledge proofs หรือทำ hardware attestation ด้วยเทคโนโลยีความปลอดภัยล่าสุดก็ตาม ปัญหาคือ hardware attestation เอง
      การยืนยันอายุก็เหมือนกัน ปัญหาไม่ใช่ว่าการยืนยันอายุเสี่ยงต่อข้อมูลรั่วไหล แต่ปัญหาคือ การยืนยันอายุ นั่นเอง
    • อยากอ่านบทสรุปที่เรียบเรียงเรื่องนี้ไว้
      ตั้งแต่ตอนประกาศแอปก็มั่นใจคร่าว ๆ แล้วว่าโครงสร้างน่าจะเป็นแบบนี้
      จำได้ว่าในฟอรัม Graphene ก็เคยมีการคุยกันว่า DRM ID ไม่ได้แค่คงอยู่ แต่ยังคงเหมือนเดิมข้ามโปรไฟล์ด้วย
    • สงสัยว่าปัญหาเหล่านี้เป็นประเภทที่ Privacy Pass พยายามแก้อยู่หรือไม่
      ถ้าใช่ อะไรจะเป็นแรงจูงใจหรือแรงบังคับให้เกิดการนำไปใช้

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

    • ผมชอบออกไปปั่นจักรยานกับเพื่อนในกิจกรรมที่ Cascade Bicycle Club แห่ง Pacific Northwest จัด แต่การสมัครเข้าร่วมต้องผ่าน Google reCAPTCHA
      Google บล็อกผมแบบสมบูรณ์ไปแล้ว
      ถ้าคลิกสี่เหลี่ยมเพื่อเลือกสิ่งที่เขาขอ มันก็วนไม่จบ และถ้าพยายามใช้เวอร์ชันเสียงก็จะโดนบล็อกหมดเพราะอ้างว่ามีกิจกรรมต้องสงสัย
      ทุกวันนี้เลยปั่นคนเดียว และปีนี้ก็ไม่ได้ต่อสมาชิกแล้ว
      ครั้งล่าสุดที่เคยเจออะไรคล้ายกันคือช่วงที่ Facebook เริ่มกลายเป็นทางเดียวในการเข้าร่วมกิจกรรมบางอย่าง ตอนนั้นก็แค่ยอมรับว่าตัวเองถูกกันออกไป แล้วเอาเวลาและเงินไปใช้ที่อื่น
    • การสร้างสถานการณ์ไร้สาระแบบนี้ไม่จำเป็นต้องมี attestation ด้วยซ้ำ
      ธุรกิจหรือกลุ่มสังคมจำนวนมากก็เข้าถึงได้ก็ต่อเมื่ออยู่หลัง Facebook, WhatsApp และสิ่งคล้ายกันอยู่แล้ว
      มันให้ความรู้สึกเหมือน โลกดิสโทเปียแบบไซเบอร์พังก์ จริง ๆ คล้ายกับส่งจดหมายหรือพัสดุได้เฉพาะถึงคนที่สมัครบริการไปรษณีย์เอกชนเจ้าเดียวกัน หรือขับรถได้เฉพาะบนถนนที่มีข้อตกลงอนุญาตใช้ร่วมกับยี่ห้อรถของคุณ
    • ผมคิดว่าควรตัดประโยคที่ว่า “มันไม่ได้ให้ฟีเจอร์ความปลอดภัยที่มีประโยชน์” ออก
      ต่อให้มันมีฟีเจอร์ด้านความปลอดภัยจริง ความเสียหายข้างเคียงที่ทำให้ระบบปฏิบัติการที่ไม่ใช่ Google หรือ Apple กลายเป็น พลเมืองชั้นสอง ก็ยังคงอยู่ และนั่นคือปัญหาหลัก
    • ถ้าอย่างนั้นก็คงกลายเป็นข้อเสนอให้สร้างสำเนาแยกของบริการเหล่านั้นด้วยใช่ไหม
      เรื่องธนาคารหรือการติดต่อกับภาครัฐคงไม่สมจริง แต่บริการอื่น ๆ อีกมากอาจพอเป็นไปได้
      อย่างไรก็ดี ก็ยังต้องมีคนลงมือสร้างอยู่ดี และต้นทุนจะถูกกระจายไปยังคนจำนวนน้อยกว่า ซึ่งอาจไม่ได้ถูกชดเชยด้วยข้อดีที่ว่าไม่ต้องสร้างเทคโนโลยีโฆษณาและมีความซับซ้อนต่ำกว่า
      ถึงอย่างนั้น มันอาจเป็นปัญหาประเภท วัตถุดิบชั้นดี อย่างหนึ่ง ส่วนฮาร์ดแวร์คงยากกว่า
    • เราจะมีจำนวนมากพอถึงขั้นบริหารประเทศกันเองได้ไหม
      ฟังดูเหมือนคำถามโง่ ๆ แต่ถามอย่างจริงจัง

  • ตอนปี 1999 ที่ Intel ตัดสินใจใส่ หมายเลขซีเรียล ที่ซอฟต์แวร์อ่านได้ลงใน CPU นั้น มีแรงต่อต้านมหาศาลจนสุดท้ายต้องยกเลิกการตัดสินใจ
    หลังจากนั้นพวกอำนาจนิยมที่ผลักดัน “ความปลอดภัย” และ trusted computing ก็ยังเดินหน้าผลักดัน TPM และเทคโนโลยีที่เกี่ยวข้องต่อ และยังมีส่วนทำให้ ระบบนิเวศแบบกำแพงล้อมรั้ว บนมือถือเติบโตขึ้นด้วย
    ข้อกำหนด TPM ของ Windows 11 ก็เป็นอีกก้าวหนึ่งไปสู่เป้าหมายนั้น ผมตกใจมากที่เห็นการโฆษณาชวนเชื่อในที่นี่และที่อื่น ๆ ว่านั่นเป็นเรื่องดี
    เมื่อคำว่า “ความปลอดภัย” ถูกยกมาเป็นข้ออ้าง ก็เห็นชัดว่าคนจำนวนมากถูกบังคับให้ยอมอะไรก็ได้อย่างง่ายดาย หวังว่าจำนวนคนแบบนั้นจะลดลง
    สงครามกับคอมพิวติ้งเอนกประสงค์ยังดำเนินต่อไป และเราต้องสู้ต่อ
    Stallman ถูกเสมอเหมือนเคย ถึงเวลาอ่าน “Right to Read” ของเขาอีกครั้งแล้ว ถ้ายังไม่มี การทำหนังสั้นด้วย AI ก็ดูเป็นไอเดียที่ดี
    “ผู้ที่ยอมสละเสรีภาพเพื่อความปลอดภัย ย่อมไม่สมควรได้ทั้งสองอย่าง”

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

  • ดูเหมือนคอมเมนต์ที่นี่จะอ่านว่าเป็นการบอกว่าตัว attestation เองไม่ดี แต่ข้อโต้แย้งจริง ๆ น่าจะใกล้เคียงกับการบอกว่า ควรมีช่องทางที่รวมผู้ให้บริการที่ไม่ใช่ Apple และ Google ไว้อย่างชัดเจนด้วย
    ชื่อเรื่องให้ความรู้สึกว่า Apple กับ Google ชั่วร้ายและทำเรื่องนี้เพื่อทำให้การผูกขาดฝังแน่นขึ้น ขณะที่คู่แข่งอย่าง GrapheneOS ยืนหยัดสู้เพื่อผู้คน
    แต่ข้อโต้แย้งสุดท้ายกลับเป็นว่าพวกเขาเองก็ควรถูกนับรวมด้วย และพวกเขาถูก Play Integrity API ของ Google ปฏิเสธด้วยเหตุผลที่ไม่ชัดเจน พร้อมกล่าวหาว่าเหตุผลนั้นมีเจตนาร้าย ซึ่งทำให้ดูเหมือนพวกเขาเองก็ยอมรับคุณค่าด้านความปลอดภัยของมันเหมือนกัน
    สำหรับข้อมูลอัตลักษณ์สำคัญ การพิสูจน์สายโซ่ลายเซ็นทั้งหมดเป็นสิ่งจำเป็นจริง ๆ เพราะนั่นเป็นทางเดียวที่จะหลีกเลี่ยงสถานการณ์ที่ AI ทำอัตลักษณ์ปลอมเพื่อการฉ้อโกงได้อย่างง่ายดาย

  • สิทธิบัตรและลิขสิทธิ์คือรูปแบบการผูกขาดดั้งเดิม
    ตราบใดที่ซอฟต์แวร์ไม่เป็น โอเพนซอร์ส มันก็เป็นการผูกขาดตามนิยาม

  • น่าแปลกใจที่ใน HN ไม่มีคนรวยที่สนับสนุน GrapheneOS มากกว่านี้
    แผนภาพเวนน์ของคนมีฐานะและสายเทคนิคที่ใส่ใจปัญหานี้น่าจะซ้อนทับกันพอสมควร และถึง Graphene จะมีข้อบกพร่องมาก แต่ก็ทำงานพื้นฐานสำคัญจำนวนมากในพื้นที่นี้อยู่

  • อารยธรรมของเราจำเป็นอย่างยิ่งที่จะต้องมีวิธีดัดแปลงไมโครอิเล็กทรอนิกส์สมัยใหม่หลังการผลิต อย่างน้อยก็ต้องให้ร้านซ่อมที่มีอุปกรณ์พร้อมใช้งานได้
    ที่จริงต้องมีตั้งแต่เมื่อวานแล้ว
    อีกทางเลือกหนึ่งคือควรทำให้การวางจำหน่ายอุปกรณ์คอมพิวติ้งเอนกประสงค์ที่มี bootloader เริ่มต้นชนิดใดก็ตามอยู่ใน mask ROM ของ CPU หรือ SoC กลายเป็นสิ่งผิดกฎหมาย
    กล่าวคือ หลังรีเซ็ต คำสั่งแรกที่ CPU รันต้องมาจากสตอเรจที่อยู่นอกแพ็กเกจ CPU ทางกายภาพ

    • หรือไม่ก็ต้องยกเลิกกฎหมายที่ทำให้ การเลี่ยง DRM เป็นสิ่งผิดกฎหมาย
      อ้างอิง: https://pluralistic.net/2026/01/01/39c3/
    • เรื่องแบบนั้นคงไม่เกิดขึ้นไปอีกนานมาก
      แม้แต่ SoC ที่ค่อนข้างเรียบง่ายก็ยังทำงานหลายอย่างใน boot ROM ที่ไม่มีเอกสารเพื่อช่วยกระบวนการรีเซ็ตก่อนจะไปถึง reset vector ตามสถาปัตยกรรม
      และการมี รูทีน DFU ระดับต่ำใน boot ROM ที่ลบพลาดไม่ได้ก็มีคุณค่าอย่างมาก
    • แค่นั้นไม่ช่วยหรอก
      ซิลิคอนของ SoC สามารถถูกแก้ให้บันทึกทุกคำสั่งที่รันตั้งแต่เปิดเครื่องจนถึงคำสั่งส่งต่อ secure boot ได้
      ถ้ามีคำสั่งเสริมอย่างการอ่านสถานะ ตรวจว่าล้นหรือไม่ หรือสร้างลายเซ็น ระบบปฏิบัติการก็จะสามารถสร้าง attestation ของตัวเองโดยรายงานการแก้ไขก่อนบูตโดยนัยไปด้วย
    • ต้นฉบับเขียนโดยนักพัฒนาระบบปฏิบัติการทางเลือกที่ติดตั้งได้อย่างอิสระบนโทรศัพท์ Google ทุกรุ่นตั้งแต่ Pixel 6 เป็นต้นไป
    • ไม่จำเป็นต้องทำให้การวางจำหน่าย bootloader เริ่มต้นใน mask ROM ของ CPU หรือ SoC เป็นสิ่งผิดกฎหมาย
      แค่ทำให้การฝัง ข้อมูลกุญแจแบบฮาร์ดโค้ด ลงใน bootloader และการใช้กุญแจนั้นตรวจสอบโค้ดที่จะโหลด เป็นสิ่งผิดกฎหมายก็พอ

  • น่าตกใจที่เราปล่อยให้ Google และ Apple ซึ่งเป็นสองยักษ์ใหญ่ ตัดสินได้ว่าใครจะเข้าถึงบริการที่ไม่เกี่ยวข้องกับพวกเขาเลยได้หรือไม่ได้
    ลองจินตนาการว่าคุณถูกแบนจากบริการของ Google เพราะมีมุมมองต่อต้าน Google แล้วจึงล็อกอินบัญชีธนาคารของตัวเองไม่ได้
    ถึงเวลาต้อง แยก Alphabet จริง ๆ

  • สำหรับหัวข้อที่จริงจังขนาดนี้ คงจะดีกว่ามากถ้ามี บทความจริงที่มีเหตุผลเป็นระบบ สรุปไว้ในหน้าเดียว แทนที่จะเป็นเธรดที่อ่านยากแบบนี้