GrapheneOS แก้ช่องโหว่ VPN รั่วบน Android ที่ Google ระบุว่าจะไม่แพตช์

 (cyberinsider.com)
1 คะแนน โดย GN⁺ 6 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • GrapheneOS ได้แก้ช่องโหว่การข้าม VPN ในอัปเดตใหม่ ซึ่งทำให้ที่อยู่ IP จริงอาจรั่วได้แม้จะเปิด “Always-On VPN” และ “Block connections without VPN” บน Android อยู่ก็ตาม
  • ช่องโหว่นี้มีต้นตอมาจากฟังก์ชัน การปิดการเชื่อมต่อ QUIC ในสแตกเครือข่ายของ Android 16 โดยแอปทั่วไปสามารถลงทะเบียน UDP payload กับ system_server ได้ด้วยสิทธิ์มาตรฐานเท่านั้น
  • เมื่อ UDP socket ของแอปถูกทำลาย system_server ที่มีสิทธิ์สูงจะส่ง payload ที่บันทึกไว้โดยตรงผ่าน physical network interface แทน VPN tunnel ทำให้ข้ามการป้องกันแบบ VPN lock ได้
  • Google จัดปัญหานี้เป็น “Won’t Fix (Infeasible)” และ “NSBC” โดยมองว่าไม่เข้าเกณฑ์ของคำแนะนำด้านความปลอดภัยของ Android และยังคงจุดยืนเดิม
  • GrapheneOS ได้ปิดใช้งาน “registerQuicConnectionClosePayload optimization” ใน release 2026050400 และยังรวมแพตช์ความปลอดภัย Android ประจำเดือนพฤษภาคม 2026, การปรับปรุง hardened_malloc, การอัปเดตเคอร์เนล Linux และการแก้ไขแบบ backport สำหรับ libpng CVE-2026-33636 ด้วย

วิธีการทำงานของช่องโหว่

  • ตาม การวิเคราะห์ทางเทคนิคของ Yusuf API ที่มีช่องโหว่อนุญาตให้แอปทั่วไปที่มีเพียงสิทธิ์ INTERNET และ ACCESS_NETWORK_STATE ซึ่งถูกให้โดยอัตโนมัติ สามารถลงทะเบียน UDP payload ใดก็ได้กับ system_server
  • หลังจากนั้น เมื่อ UDP socket ของแอปถูกทำลาย โปรเซส system_server ของ Android ที่มีสิทธิ์สูงจะส่ง payload ที่บันทึกไว้โดยตรงผ่าน physical network interface ของอุปกรณ์ แทนที่จะส่งผ่าน VPN tunnel
  • เนื่องจาก system_server ทำงานด้วยสิทธิ์เครือข่ายที่สูงกว่าและไม่อยู่ภายใต้ข้อจำกัดการกำหนดเส้นทางของ VPN แพ็กเก็ตดังกล่าวจึงข้ามการป้องกัน VPN lock ของ Android ได้อย่างสมบูรณ์
  • นักวิจัยด้านความปลอดภัย lowlevel/Yusuf ได้สาธิตช่องโหว่นี้บน Pixel 8 ที่ใช้ Android 16 โดยเปิด Proton VPN และโหมดล็อกของ Android พร้อมกัน
  • แอปดังกล่าวสามารถทำให้ที่อยู่ IP สาธารณะจริงของอุปกรณ์รั่วไปยังเซิร์ฟเวอร์ระยะไกลได้ แม้ว่าการป้องกันผ่าน VPN จะเปิดใช้งานอย่างสมบูรณ์ก็ตาม

สาเหตุและการจัดการของ Google

  • Google ได้นำฟีเจอร์นี้มาใช้เพื่อให้แอปพลิเคชันสามารถปิดเซสชัน QUIC ได้อย่างถูกต้องเมื่อ socket ถูกทำลายโดยไม่คาดคิด
  • การติดตั้งใช้งานนี้รับ payload ได้ตามอำเภอใจ โดยไม่ได้ตรวจสอบว่า payload ดังกล่าวเป็นเฟรม QUIC CONNECTION_CLOSE ที่ถูกต้องตามกฎหมายหรือไม่
  • เดิมทีการติดตั้งใช้งานนี้ยังไม่ได้ตรวจสอบด้วยว่าแอปพลิเคชันนั้นถูกจำกัดให้ส่งทราฟฟิกผ่าน VPN เท่านั้นหรือไม่
  • นักวิจัยรายงานปัญหานี้ต่อทีมความปลอดภัยของ Android แต่ Google จัดประเภทเป็น “Won’t Fix (Infeasible)” และ “NSBC” (Not Security Bulletin Class)
  • Google มองว่าปัญหานี้ไม่เข้าเกณฑ์ที่จะรวมไว้ในคำแนะนำด้านความปลอดภัยของ Android
  • นักวิจัยขอให้มีการทบทวนอีกครั้ง โดยชี้ว่าทุกแอปสามารถทำให้ข้อมูลเครือข่ายที่ใช้ระบุตัวตนรั่วไหลได้ด้วยสิทธิ์มาตรฐานเท่านั้น แต่ Google ยังคงจุดยืนเดิมและอนุมัติให้เปิดเผยข้อมูลเมื่อวันที่ 29 เมษายน

อัปเดตและแนวทางบรรเทาของ GrapheneOS

  • GrapheneOS เป็นระบบปฏิบัติการบนพื้นฐาน Android ที่เน้นความเป็นส่วนตัวและความปลอดภัย พัฒนาหลักสำหรับอุปกรณ์ Google Pixel และถูกใช้งานโดยผู้ใช้ที่ต้องการ application sandboxing ที่แข็งแกร่งขึ้น การลดผลกระทบจาก exploit และลดการพึ่งพาบริการของ Google
  • GrapheneOS ได้ปิดใช้งาน optimization ดังกล่าวทั้งหมดใน release 2026050400 เพื่อป้องกันการรั่วของ VPN
  • Yusuf ระบุว่า GrapheneOS ปล่อยการแก้ไขออกมาได้ภายในเวลาไม่ถึง 1 สัปดาห์
  • นอกจากการแก้ปัญหา VPN รั่วแล้ว รีลีสล่าสุดยังรวม ระดับแพตช์ความปลอดภัย Android เดือนพฤษภาคม 2026 แบบครบชุดด้วย
  • อัปเดตนี้ยังรวมการปรับปรุง hardened_malloc หลายรายการ, การอัปเดตเคอร์เนล Linux ครอบคลุม branch 6.1, 6.6 และ 6.12 ของ Android, และการแก้ไขแบบ backport สำหรับ CVE-2026-33636 ของ libpng
  • ยังมี Vanadium browser build ใหม่และการขยายข้อจำกัดของ Dynamic Code Loading มาพร้อมกันด้วย
  • ผู้ใช้ Android ทั่วไปสามารถบรรเทาปัญหานี้ชั่วคราวได้โดยปิดใช้งานแฟล็ก DeviceConfig ชื่อ close_quic_connection ผ่าน ADB
  • แนวทางเลี่ยงนี้ต้องใช้สิทธิ์เข้าถึงระดับนักพัฒนา
  • หาก Google ลบฟีเจอร์แฟล็กนี้ออกในการอัปเดตในอนาคต แนวทางบรรเทานี้ก็อาจไม่สามารถใช้ต่อได้

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

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

 
GN⁺ 6 시간 전
ความคิดเห็นใน Hacker News

  • ถ้า system_server ทำงานด้วยสิทธิ์เครือข่ายระดับสูงและไม่ถูกบังคับด้วยข้อจำกัดการกำหนดเส้นทางของ VPN ก็ชวนให้คิดว่า VPN บน Android ก็แทบจะไม่ใช่ VPN จริง ๆ ใช่ไหม
    นอกเหนือจากบั๊กนี้ ก็สงสัยว่า OS แบบปิดอื่น ๆ ทำงานในลักษณะเดียวกันหรือเปล่า

    • iOS ก็เหมือนกัน และเท่าที่ทราบ ถ้าจะเลี่ยงต้องใช้ไลเซนส์ enterprise สำหรับอุปกรณ์มากกว่า 250 เครื่อง
      Mullvad และรายอื่น ๆ ก็เคยพูดถึงปัญหานี้มานานแล้ว
    • คำอย่าง “private” หรือ “trust” มีความหมายไม่เหมือนกันในโลกคอมพิวเตอร์กับในธรรมเนียมของมนุษย์
      สิ่งที่น่ากังวลคือผู้คนเห็นคำที่สะกดเหมือนกันแล้วแยกความต่างตามบริบทไม่ออก จึงเผลอขยาย ความไว้วางใจแบบมนุษย์ ไปเป็น โมเดลความเชื่อถือของคอมพิวเตอร์
    • macOS ก็เคยมีกรณีที่แอปของระบบเองสามารถบายพาส always-on VPN ได้
      แต่ไม่แน่ใจว่ามีช่องโหว่หรือช่องทางที่ส่งทราฟฟิกไปยังปลายทางตามต้องการได้โดยตรงหรือไม่
    • สงสัยว่าการแก้ system_server และเส้นทางบายพาสอื่น ๆ ทำได้ยากแค่ไหน

  • คล้ายกับ Manifest V3 การป้องกันการสอดส่องไม่ได้สอดคล้องกับผลประโยชน์ของ Google
    ข้อจำกัดแบบนั้นกระทบกับ โมเดลธุรกิจ

  • เหตุผลทางเทคนิคที่ทำให้เรื่องนี้ร้ายแรงคือการรั่วไหลเกิดจาก system_server ซึ่งเป็นโปรเซสที่มีสิทธิ์สูง
    โหมดล็อกดาวน์ของ Android เองให้สัญญาไว้อย่างชัดเจนว่าไม่มีทราฟฟิกใดจะข้าม VPN ได้ ถ้าตัวระบบเองส่งแพ็กเก็ตออกทาง physical interface ก็แปลว่าคำสัญญานั้นถูกทำลายในระดับเคอร์เนล ไม่ใช่แค่ใน user space ดังนั้นจะบอกว่า “ไม่ถึงขั้นประกาศด้านความปลอดภัย” ก็ดูยาก

  • ถ้า Google อนุญาตให้เปิดเผยได้ตั้งแต่ 29 เมษายน ก็น่าแปลกที่ยังรักษา embargo และเลื่อนการปล่อยแพตช์ไปถึงเดือนพฤษภาคม
    ไม่เข้าใจว่าทำไมถึงไม่เปิดเผยทันที

    • เป็นไปได้มากว่าไม่อยากทำลายความสัมพันธ์กับ Google ในฐานะผู้ขายแพลตฟอร์ม
      จะชอบหรือไม่ก็ตาม GrapheneOS พึ่งพา Android ที่ Google ควบคุมอยู่

  • เข้าใจว่ามีเหตุผลทางธุรกิจที่ไม่ดีอยู่ แต่ก็ไม่แน่ใจว่าจะรักษาศักดิ์ศรีได้อย่างไรหาก จัดหมวด VPN leak ว่าไม่ใช่ปัญหาด้านความปลอดภัย

    • มันขึ้นอยู่กับว่ามองบทบาทของ VPN อย่างไร
      เดิมที VPN มีไว้เพื่อเข้าถึงเครือข่ายส่วนตัวหรือเครือข่ายงานผ่านอีกเครือข่ายหนึ่ง เช่น เชื่อมสำนักงานเข้าด้วยกันหรือเชื่อมจากบ้านเข้าออฟฟิศ ภายหลังถึงค่อยถูกมองเป็นเครื่องมือด้านความปลอดภัยรูปแบบหนึ่ง
      ถ้ามองโค้ด VPN ว่า “ขอแค่ให้มือถือเข้าถึงเครื่องพิมพ์ที่ออฟฟิศผ่าน 5G ได้ก็พอ” มันอาจเป็นเพียงบั๊กเล็ก ๆ ที่ปิดการเชื่อมต่อ QUIC ได้ไม่สมบูรณ์ แต่ถ้ามองว่า “WireGuard tunnel นี้ต้องปกปิดตัวตนของฉันไม่ว่าอะไรจะเกิดขึ้น” หรือ “มันต้องเป็นสำเนาที่ครบถ้วนของทราฟฟิกทั้งหมดที่เข้าออกอินเทอร์เน็ต” ก็ถือว่าเป็นปัญหาใหญ่
      มองอย่างไร Android VPN หรือแทบทุก VPN ไม่ได้ถูกออกแบบมาเป็นมาตรการคุ้มครองความเป็นส่วนตัวหรือความปลอดภัย โดยเฉพาะเมื่อเจอกับแอปที่รันโค้ดบนอุปกรณ์ได้ และตัวเครื่องเองก็มีปฏิสัมพันธ์เครือข่ายหลายแบบ รวมถึงภายในโมเด็มชิปด้วย
      การที่ Google ปิดบั๊กนี้ไปเป็นความผิดพลาด แต่ก็พอเข้าใจได้ว่าทำไมโครงการ bug bounty ถึงไม่นับเป็นบั๊กความปลอดภัย
    • เป็นคำถามที่ถามได้ก็ต่อเมื่อสมมติว่ามีศักดิ์ศรีให้รักษา
    • สำหรับ Google นี่ไม่ใช่บั๊ก แต่เป็นฟีเจอร์
      Google เป็นทั้งบริษัทโฆษณาและผู้รับจ้างด้านการโจมตี ดังนั้นการที่ผู้ใช้ VPN ทำแพ็กเก็ตรั่วจึงเป็นประโยชน์กับทั้งสองด้าน
    • พวกเขาได้เงินมาก็เพื่อทำแบบนั้น
    • คงทำงานที่ Google ไม่ได้ ถ้ายังมองว่าการเปิดเผยข้อมูลส่วนบุคคลโดยไม่พึงประสงค์เป็นประเด็นด้านความปลอดภัย

  • คล้ายกับกรณีที่ Meta ถอด end-to-end encryption ออก
    ประมาณว่า “ไม่สิ เราอยากเห็นทุกอย่างที่คุณพูดและทำ”

  • อยากรู้ว่ามีวิธีไหนดีในการหาโทรศัพท์สำหรับ GrapheneOS
    อยากลองใช้ GrapheneOS มานาน แต่ก็ยังลังเลที่จะซื้อ Pixel จริง ๆ แม้แต่มือสอง รุ่นซีรีส์ “a” ก็มักเกิน 300 ดอลลาร์ และต้องย้อนไปหลายรุ่น ยังมีเรื่องปลดล็อก bootloader ได้หรือไม่อีกด้วย จะให้จ่าย 449 ดอลลาร์กับ Pixel 10a ใหม่ตอนนี้ก็ยังไม่ไหว

    • ตอนนี้อาจยังไม่ช่วย แต่ GrapheneOS เพิ่งประกาศ พาร์ตเนอร์กับ Motorola ดังนั้นอีกประมาณ 1 ปีน่าจะเริ่มมีการรองรับอุปกรณ์ Motorola บางรุ่น
      ส่วนตัวตอนเปิดตัว Google Fi ซื้อ Pixel 10a มาได้ราว 300 ดอลลาร์
    • ไม่แนะนำให้ซื้อ Pixel 10a
      Pixel 9a แทบจะเป็นเครื่องเดียวกันและยังมีขายเป็นของใหม่อยู่
    • แนะนำ ซีรีส์ Pixel 8 ขึ้นไป
      ซื้อของใหม่จากร้านทั่วไปหรือ Google Store จะชัวร์กว่าร้านของโอเปอเรเตอร์
      ของมือสองแทบจะเป็นการพนันเพราะปัญหา OEM unlock ดังนั้นควรเช็กนโยบายคืนสินค้าให้ดีและตรวจสอบว่าเข้าถึงการปลดล็อก OEM ได้ก่อนซื้อ
    • ตอบไว้ในอีกเธรดแล้ว: https://news.ycombinator.com/item?id=48076522
      โดยพื้นฐานคือซื้อ Pixel 6 ขึ้นไปที่มั่นใจได้ว่าปลดล็อก bootloader ได้ แต่ Pixel 6 ใกล้จะเหลือเพียงการซัพพอร์ตขั้นต่ำแล้ว จึงแนะนำ Pixel 7 ขึ้นไป รายการมือสองส่วนใหญ่ปลดล็อก bootloader ไม่ได้
      สรุปคือควรซื้อจาก Google โดยตรง หรือซื้อจาก eBay ที่ติดตั้ง GrapheneOS/CalyxOS/LineageOS มาแล้ว หรือซื้อเครื่องที่ผู้ขายระบุชัดว่าปลดล็อก bootloader ได้
      จากประสบการณ์ส่วนตัว ถ้าผู้ขายไม่ได้ระบุเองอยู่แล้ว การขอให้ตรวจสอบ bootloader มักไม่ค่อยช่วย แทบไม่มีใครอยากไล่เช็กให้ คำตอบก็มักจะเป็น “ไม่ได้” หรือไม่ก็เข้าใจคำถามผิดแล้วตอบแค่ว่าเป็น “unlocked phone” หรืออาจจะเบื่อคำถามแนวนี้อยู่แล้ว
    • อีกวิธีคือรออีกหน่อย
      มีงานกำลังทำอยู่เพื่อรองรับฮาร์ดแวร์โทรศัพท์มากขึ้น และก่อนหน้านี้ก็มีการเดากันอยู่พักใหญ่ว่าจะเป็นแบรนด์ไหน

  • ลองซื้อ Pixel 6 มือสองราคาถูกมาเพื่อใช้ GrapheneOS แต่ไม่ค่อยชอบ
    รู้สึกว่า ประสบการณ์ใช้งานของ LineageOS ดีกว่ามาก โครงสร้าง package manager ดูประหลาดเหมือนตุ๊กตารัสเซีย แอป “App Store” เริ่มต้นมีแค่โปรแกรมพื้นฐานไม่กี่ตัว และหนึ่งในนั้นยังเป็น package manager อีกตัวคือ Accrescent ซึ่งก็ยังมีแอปน้อยมาก จนต้องหา package manager อีกตัวอยู่ดี ฝั่ง GrapheneOS ดูเหมือนจะชอบ Obtainium มากกว่า F-Droid ซึ่งก็ดูเป็นการตัดสินใจที่แปลก
    ส่วนตัวชอบ package manager แบบโอเพนซอร์สเต็มรูปแบบมากกว่า และการ build จากซอร์สภายนอกแทนที่จะเชื่อถือแพ็กเกจจาก GitHub โดยตรง โดยเฉพาะถ้าทำให้ reproducible ได้ ก็มีคุณค่าจริง โมเดลความปลอดภัยของ GrapheneOS ดูรวมศูนย์แปลก ๆ ข้อดีด้านความเป็นส่วนตัวและความปลอดภัยที่รายงานกันมาก็ตัดสินเองได้ยาก

    • ก็แค่ดาวน์โหลด F-Droid โดยตรงสิ
      ไม่เข้าใจว่าทำไมต้องยึดติดว่าแอปสโตร์ที่ติดตั้งมาให้ล่วงหน้าแบบตายตัวเป็นสิ่งจำเป็น
      การดูแลแอปสโตร์ก็หนักพอ ๆ กับการดูแล Android fork อยู่แล้ว และเมื่อมีตัวเลือกอย่าง F-Droid, Play Store กับ Aurora Store, Obtainium ฯลฯ อยู่แล้ว ก็ยากจะโทษนักพัฒนา GrapheneOS ที่ไม่ทุ่มแรงมหาศาลเพิ่มอีก
    • App Store เป็นเพียงจุดเริ่มต้นขั้นต่ำสำหรับตัดสินใจว่าจะเอาแอปจากที่ไหน
      สภาพเริ่มต้นมีแค่ launcher และระบบปฏิบัติการขั้นต่ำ ซึ่งก็เพียงพอทั้งหมดสำหรับสายมินิมัล
      ถ้าต้องการมากกว่านั้น ผู้ใช้ก็เป็นคนตัดสินใจเองว่าจะไปทางไหน ฉันเรียกสิ่งนี้ว่า การให้อำนาจผู้ใช้ แต่ดูเหมือนคุณจะเรียกว่าความไม่สะดวก ถ้าอย่างนั้น OS นี้อาจไม่เหมาะกับคุณ
    • การที่ซอฟต์แวร์เป็น free/open source ไม่ได้แปลว่าจะปลอดภัยกว่าหรือเป็นส่วนตัวกว่าโดยเนื้อแท้
      “โอเพนซอร์ส” โดยพื้นฐานก็เป็นเพียงคำด้านไลเซนส์
      “App Store” ของ GrapheneOS มีไว้เพื่อให้แอปพื้นฐานที่สุดที่จำเป็นต่อการใช้งานทั่วไป ส่วนที่ Accrescent ถูกแจกจ่ายผ่านช่องทางนั้นก็เพราะมันปฏิบัติตาม baseline ด้านความปลอดภัยของ Android ในฐานะ app repository จริง ๆ ซึ่ง F-Droid และ Aurora Store ไม่ได้ทำ
      ส่วนตัวไม่คิดว่าวิธีที่บุคคลที่สาม build แอปและตรวจดูพฤติกรรมไม่พึงประสงค์แบบ F-Droid จะมีคุณค่ามาก การตรวจแบบนี้เชื่อถือได้ต่ำและเคยถูกหลบเลี่ยงมาแล้ว นั่นก็เป็นหนึ่งในเหตุผลที่ WireGuard ไม่อยู่บน F-Droid อีกต่อไป ถ้าคุณไม่เชื่อใจแอปมากพอจะรับตรงจากนักพัฒนา ก็คงไม่ควรใช้แอปนั้น
      ข้อดีด้านความเป็นส่วนตัวและความปลอดภัยของ GrapheneOS ถูกออกแบบมาให้แทบมองไม่เห็นสำหรับผู้ใช้ทั่วไป ตัวอย่างเช่น hardened memory allocator และ memory tagging extension ที่ช่วยป้องกันบั๊ก memory corruption รวมถึงความสามารถในการติดตั้ง Google Play แบบ sandboxed เพื่อใช้บริการของ Google โดยไม่ให้ Google ควบคุมทั้งอุปกรณ์ได้
    • GrapheneOS สืบทอดส่วนติดต่อผู้ใช้มาจาก Android Open Source Project และ Android fork ของผู้ผลิตหลายรายรวมถึงระบบเริ่มต้นของ Pixel ก็อิงจากสิ่งนี้
      App Store ของ GrapheneOS มีไว้เพื่อเติมบทบาท primary app store ที่ AOSP ต้องการ นอกจากนี้ยังใช้แยกการอัปเดตแอป primary ออกจากการอัปเดต OS และในบางกรณีก็ทำหน้าที่เป็นมิเรอร์ให้แอปด้วย
      Accrescent ถูกมิเรอร์เพราะเน้นความเป็นส่วนตัวและความปลอดภัย ตอนนี้ยังอยู่ในสถานะอัลฟาและปิดรับการส่งแอป แต่จะเปิดในเร็ว ๆ นี้
      Google Play ถูกมิเรอร์ไว้เพื่อความเข้ากันได้กับแอปที่ต้องใช้ Google Play และเพื่อการเข้าถึง Play Store
      เหตุผลที่ชุมชน GrapheneOS ชอบ Obtainium ก็เพราะมันดึง แอปที่นักพัฒนาลงลายเซ็นไว้เอง จากที่อย่าง GitHub ได้ ส่วน F-Droid เซ็นและ build แอปเกือบทั้งหมดในคลังหลักด้วยโครงสร้าง build ที่ล้าสมัยและการกำกับดูแลที่อ่อนแอ
      โมเดลความปลอดภัยของ GrapheneOS สืบทอดจากโมเดลความปลอดภัยของ AOSP และเสริมความแข็งแกร่งเพิ่มเติมบนพื้นฐานนั้น
    • ดีใจมากที่ CalyxOS กลับมาคึกคักอีกครั้ง
      GrapheneOS มีงานวิศวกรรมที่น่าทึ่งหลายอย่าง แต่ฝั่ง Calyx ดูเรียบง่ายกว่าและจัดการหลายเรื่องในแบบที่ใกล้เคียง Android เดิมมากกว่า

  • GrapheneOS บอกว่าได้ปิดการทำงานของ optimization registerQuicConnectionClosePayload เพื่อ “แก้ VPN leak” และทำให้ attack vector นี้แทบใช้ไม่ได้จริงบน Pixel ที่รองรับ
    พูดอีกอย่างคือ GrapheneOS “แก้” การรั่วนี้ด้วยการปิด optimization นั้น
    เมื่อก่อนใน HN คนเคยชื่นชม QUIC และกดคะแนนต่ำให้คอมเมนต์ที่ถามว่า QUIC เป็นประโยชน์กับใครมากที่สุด การใช้ QUIC อาจสอดคล้องกับผลประโยชน์ของคนอื่น แต่สำหรับฉันมันเป็น tradeoff ที่ไม่คุ้มจึงบล็อกทราฟฟิก QUIC
    QUIC บางครั้งถูกเปิดไว้เป็นค่าเริ่มต้นในซอฟต์แวร์ที่ Google แจกจ่ายอย่าง Android และในบางกรณีก็ไม่มีทางปิดได้

    • แม้บน GrapheneOS เอง QUIC ก็ยังทำงานได้ตามปกติ
      สิ่งที่ GrapheneOS เอาออกมีเพียงวิธีที่แอปสามารถขอให้ OS ปิดการเชื่อมต่อ QUIC โดยอัตโนมัติ ในกรณีเช่นแอปตายเท่านั้น จากมุมมองของเซิร์ฟเวอร์ มันเป็น optimization เพราะช่วยหลีกเลี่ยงการปล่อยให้การเชื่อมต่อค้างเปิดกินทรัพยากรจนหมดเวลา idle แล้วค่อยเข้าสู่ขั้นตอนปิด แต่จากฝั่งไคลเอนต์ไม่ใช่ optimization อะไร
      นอกจากนี้ GrapheneOS ยังแก้ VPN leak อื่นอีกประมาณ 5 จุด และกำลังแก้เพิ่มอยู่ด้วย ปัจจุบันการทำงานของ VPN บน Android เป็นแบบ per-profile VPN แต่โปรไฟล์ยังไม่ได้ใช้ network namespace ของตัวเอง ทำให้ตัวแก้ DNS และบริการส่วนกลางหลายตัวต้องรองรับ VPN ให้ถูกต้อง จึงเสี่ยงต่อการรั่ว
      ในอนาคตมีแผนปรับโครงสร้าง VPN ให้ทนต่อการรั่วได้มากขึ้นมาก และจะมีการรองรับการรันแอปหรือกลุ่มแอปใน virtual machine ซึ่งให้การปกป้องที่แข็งแรงกว่าได้
    • นี่คือการที่เส้นทางสำหรับปิดการเชื่อมต่อ QUIC อย่างสวยงามถูกเปิดเผยผ่านการเรียกที่ไม่เหมาะสมหรือถูกนำไปใช้ในทางที่ผิด ไม่ใช่ว่า GrapheneOS ปิด QUIC ทั้งหมด
      ตัว QUIC เองยอดเยี่ยมอยู่แล้ว และนี่ไม่ใช่คุณสมบัติของโปรโตคอล แต่ใกล้เคียงกับฟีเจอร์ของ Google Android ที่เป็นระบบปฏิบัติการเพื่อการสอดส่อง มากกว่า
      ยิ่งไปกว่านั้น เมื่อตรวจบนระบบก่อนรุ่นล่าสุดก็ยังทำงานได้ไม่ถูกต้องอยู่ดี

  • Android แบบสต็อกคือสปายแวร์และแอดแวร์
    ถ้าเป็นเมื่อก่อนซอฟต์แวร์แบบนี้คงถูกเรียกว่าเป็นมัลแวร์และถูกลบออกไปแล้ว แต่ตอนนี้มันกลายเป็นค่าปริยาย

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