คำถามชวนอึดอัดเกี่ยวกับการยืนยันตัวตนนักพัฒนาแอนดรอยด์

 (commonsware.com)
5 คะแนน โดย GN⁺ 2025-08-28 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • โครงการ การยืนยันตัวตนนักพัฒนาแอนดรอยด์ ที่ Google จะเริ่มใช้ตั้งแต่ปี 2026 กำหนดให้นักพัฒนาแอปทุกรายต้องยืนยันตัวตน ซึ่งก่อให้เกิดข้อถกเถียงเรื่องสมดุลระหว่าง ความเป็นส่วนตัว กับความปลอดภัย
  • กรณีของ ICEBlock แสดงให้เห็นว่าสำหรับนักพัฒนาที่จำเป็นต้องใช้นามแฝง การ เปิดเผยตัวตน อาจนำไปสู่ความเสียหายทั้งส่วนตัวและทางอาชีพ
  • นโยบายความเป็นส่วนตัว ของ Google ระบุว่าสามารถแชร์ข้อมูลนักพัฒนาให้บุคคลที่สามได้โดยแทบไม่มีข้อจำกัด ทำให้เกิดความกังวลเรื่องความน่าเชื่อถือและความโปร่งใส
  • หากหลังปี 2027 มีการจำกัดการใช้ debug keystore และชื่อแพ็กเกจที่ซ้ำกัน ก็อาจทำให้การพัฒนาและทดสอบแอปในสภาพแวดล้อมการเรียนการสอนทำได้ยากขึ้น
  • แม้โครงการนี้จะมีเป้าหมายเพื่อป้องกัน แอปอันตราย แต่ก็ยังจำเป็นต้องมีการหารือเรื่องการไม่เปิดเผยตัวตน การเข้าถึงด้านการศึกษา และการขาดความร่วมมือกับองค์กรภาคประชาสังคม

ภูมิหลังและการตั้งปัญหา

  • Google จะกำหนดให้นักพัฒนาแอปแอนดรอยด์ทุกรายต้องผ่าน การยืนยันตัวตน ตั้งแต่ปี 2026 และจะอนุญาตให้ติดตั้งได้เฉพาะแอปจากนักพัฒนาที่ผ่านการยืนยันแล้วเท่านั้น
    • นโยบายนี้ใช้กับแอปที่เผยแพร่นอก Google Play ด้วย (sideloading)
    • เปิดให้เข้าถึงล่วงหน้าในเดือนตุลาคม 2025, เปิดสำหรับนักพัฒนาทุกคนในเดือนมีนาคม 2026, และเริ่มบังคับใช้ในบราซิล อินโดนีเซีย สิงคโปร์ และไทยในเดือนกันยายน 2026
  • กรณีของแอป ICEBlock ตอกย้ำความสำคัญของการไม่เปิดเผยตัวตน
    • ICEBlock เป็นแพลตฟอร์มที่ให้ผู้ใช้รายงานกิจกรรมของ ICE (Immigration and Customs Enforcement) แบบไม่เปิดเผยตัวตน โดยหลังจากที่ผู้พัฒนาเปิดเผยตัวตน ก็ต้องเผชิญกับ การข่มขู่ทางกฎหมาย และความเสียหาย เช่น คู่สมรสถูกเลิกจ้าง
    • ผู้พัฒนาแอปลักษณะคล้ายกันบนแอนดรอยด์ (ชื่อสมมติ “ICE Scream”) ก็อาจเผชิญความเสี่ยงคล้ายกันจากการเปิดเผยตัวตน

คำถามที่ 1: การคำนึงถึงการไม่เปิดเผยตัวตน

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

คำถามที่ 2: ความร่วมมือกับองค์กรภาคประชาสังคม

  • ยังไม่มีการยืนยันว่า Google ได้ร่วมมือกับองค์กรภาคประชาสังคมอย่าง EFF หรือ AccessNow เพื่อหารือเรื่องสมดุลระหว่างความเป็นส่วนตัวกับความปลอดภัยของโครงการยืนยันตัวตนนี้หรือไม่
    • องค์กรเหล่านี้มีประสบการณ์ยาวนานในการจัดการสมดุลดังกล่าว
    • ยังขาดข้อมูลว่า Google ได้นำความเชี่ยวชาญของพวกเขามาใช้หรือไม่ และผลลัพธ์เป็นอย่างไร

คำถามที่ 3: ความกำกวมของนโยบายความเป็นส่วนตัว

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

คำถามที่ 4: debug keystore กับสภาพแวดล้อมการพัฒนา

  • การพัฒนาแอปแอนดรอยด์ใช้ debug keystore ซึ่งเป็นสิ่งชั่วคราวและมักถูกเปลี่ยนอยู่บ่อยครั้ง
    • หลังปี 2027 หาก debug keystore ไม่ถูกรวมอยู่ในโครงการยืนยันตัวตน ก็อาจทำให้ไม่สามารถทดสอบแอปบนฮาร์ดแวร์ที่ผ่านการรับรองของ Google ได้
    • การกำหนดให้ต้องลงทะเบียน keystore ในสภาพแวดล้อมการศึกษา (เช่น ห้องเรียน, เซิร์ฟเวอร์ CI) อาจเพิ่ม อุปสรรคต่อการเรียนรู้

คำถามที่ 5: ปัญหาชื่อแพ็กเกจซ้ำกัน

  • ในสภาพแวดล้อมการศึกษา การใช้ ชื่อแพ็กเกจที่ซ้ำกัน เป็นเรื่องปกติ เช่น ในโปรเจกต์ตัวอย่างของ Google
    • โครงการยืนยันตัวตนจะห้ามใช้ชื่อแพ็กเกจซ้ำ ซึ่งทำให้นักพัฒนามือใหม่ไม่สามารถรันโค้ดตัวอย่างได้
    • ตัวอย่าง: ผู้เขียนหนังสือสอนพัฒนาแอป Android กังวลว่าผู้อ่านจะไม่สามารถรันตัวอย่างได้
    • Google ยังไม่ได้เสนอวิธีแก้ปัญหานี้

การหารือเพิ่มเติมและข้อเสนอแนะ

  • Google เปิด แบบฟอร์มออนไลน์ เพื่อรับฟังความคิดเห็นจากนักพัฒนา โดยสามารถส่งคำถามและข้อกังวลได้
  • องค์กรภาคประชาสังคมหรือผู้ที่สนใจสามารถติดต่อได้ที่ dev.verification@commonsware.com
  • หาก Google เองต้องการหารือ ก็สามารถติดต่อได้ที่ did.you.really.need.a.written.invitation@commonsware.com

นัยสำคัญ

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

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

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

 
ndrgrd 2025-08-28

ถ้าเป็นแอปที่นักพัฒนาแจกจ่ายไฟล์ apk เอง ก็ควรติดตั้งผ่าน Obtainium ให้มากที่สุดเท่าที่ทำได้ หากเป็นแพลตฟอร์มแจกจ่ายชื่อดังอย่าง Github หรือ Gitlab ก็สามารถติดตั้งได้ด้วยการกดไม่กี่ครั้ง และยังอัปเดตอัตโนมัติได้ด้วย
ไม่รวมโค้ดที่เกี่ยวข้องกับ Google ด้วย และดีในทุกด้าน

ถ้าคุณไม่สามารถเชื่อถือนักพัฒนาได้ ตั้งแต่แรกก็ควรจะไม่ติดตั้งแอปนั้นครับ
 
GN⁺ 2025-08-28
ความคิดเห็นจาก Hacker News

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

  • ผมไม่เข้าใจว่าทำไมการมี mobile OS โอเพนซอร์สที่ใช้งานได้จริงสักตัวถึงซับซ้อนขนาดนี้
    ผมใช้แต่ Linux PC ทั้งส่วนตัวและงานเท่านั้น (โน้ตบุ๊ก, เซิร์ฟเวอร์)
    สำหรับงานก็ต้องใช้ MS365, Google Workspace, Zoom อยู่บ้าง แต่ก็ยังพอใจเพราะอย่างน้อยเข้าผ่านเบราว์เซอร์ได้ จึงกันตัวเองออกจากระบบนิเวศแบบปิดได้
    ฝั่งมือถือมี PostmarketOS, Phosh, Ubuntu Touch แต่ผมยังไม่เคยใช้จริงในชีวิตประจำวัน
    บางทีก็คิดว่านี่เป็นความรับผิดชอบของผมหรือเปล่า แต่รัฐบาลของเราก็รองรับแอปยืนยันตัวตนแค่ iOS/Android เท่านั้น
    ที่ถูกคงต้องยืนหยัดใช้เว็บอย่างเดียว แต่เพราะความสะดวก สุดท้ายผมเองก็ยังยอมใช้แอป เลยรู้สึกว่าตัวเองอ่อนแอ
    ถ้ามี Ubuntu Touch กับ iPad ก็น่าจะใกล้เคียงกับการมีอุปกรณ์ที่ผมควบคุมความเป็นส่วนตัวได้เอง
    ท้ายที่สุดเราต้องการ ‘แพลตฟอร์มคอมพิวติ้งส่วนบุคคล’ ของจริงที่พกติดตัวได้โดยไม่ต้องแบกกระเป๋า
    มันน่าเศร้าที่แม้แต่ GrapheneOS อนาคตก็ยังขึ้นอยู่กับมือของศัตรูรายใหญ่ผู้ไม่ชอบให้ผู้ใช้ควบคุมตัวเองได้

  • ผมคาดว่าในอนาคตอันใกล้ สมาร์ตโฟนและแท็บเล็ตแบบปิดจะมีจำนวนมากกว่าเดสก์ท็อป/โน้ตบุ๊กทั่วไป
    คนส่วนใหญ่คงไม่มีแม้แต่โอกาสได้ครอบครองอุปกรณ์ที่เปิดกว้างอย่างแท้จริง
    และอาจเกิดวันที่แม้แต่โน้ตบุ๊กก็ถูกปิดตายด้วย

  • ตอนนี้คุณยังซื้อชิป RISC-V ที่เปิดกว้างเต็มที่และดีบักได้ตามใจชอบอยู่
    x86 ก็แทบจะเปิดกว้างเกือบสมบูรณ์เช่นกัน (ยกเว้นกรณีอย่าง XBox, PS5 ที่พยายามปิดเป็นกรณีพิเศษ)
    ดังนั้นผมจึงคิดว่าเรื่อง “สิทธิในการอ่าน” ของ Stallman ยังเป็นการพูดเกินจริงไปหน่อยในตอนนี้

  • ตรรกะที่ Stallman มองข้ามคือการสมมติว่าทุกระบบสมบูรณ์แบบ เจาะไม่ได้เด็ดขาด และผู้คนมีความเข้าใจซอฟต์แวร์กับระบบอย่างสมบูรณ์ไม่ว่าจะชอบหรือไม่ก็ตาม
    ถ้ามีการจำกัดดีบักเกอร์ สุดท้ายทุกคนก็จะหันไปใช้ดีบักเกอร์เถื่อนกันอยู่ดี
    คนส่วนใหญ่ (99.9%) ไม่สนใจ OSS เลย
    สิ่งที่คนสนใจคือแค่การใช้โทรศัพท์ของตัวเองตามต้องการ โดยไม่มีแอปอันตราย แอปไม่พึงประสงค์ หรือแอปโฆษณา
    อีกอย่าง การเผยแพร่กับการพัฒนาเป็นกิจกรรมคนละอย่างกัน

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

  • ที่ PC เปิดกว้างได้ ก็แค่เพราะ IBM คาดการณ์ผิด
    ตอนที่ IBM พยายามเข้าควบคุม มันก็สายเกินไปแล้ว

  • ผมคิดว่าแม้แต่คำว่า “sideload” เองก็มีปัญหา
    ทำไมไม่เรียกมันว่า “การรันโปรแกรม” ล่ะ?
    OS ที่ไม่ยอมให้ผมรันโปรแกรมที่ต้องการมันไม่มีเหตุผลเลย

  • ผมพอรู้คร่าว ๆ แล้วว่า “Stallman was right” หมายถึงอะไร เพราะไปถาม LLM มา
    แต่อยากรู้ว่ามีใครอธิบายให้ฟังตรง ๆ ได้ไหม
    ทุกครั้งที่ต้องทำความเข้าใจเรื่องแบบนี้จากคำตอบของ LLM อย่างเดียว ผมจะรู้สึกไม่ค่อยสบายใจ เลยอยากถามคนจริง ๆ มากกว่า

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

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

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

  • คุณซื้อไลเซนส์วิดีโอเกมบน Steam แล้วติดตั้งม็อดได้อย่างอิสระ
    โมเดลแบบเช่าถูกซ่อนไว้อย่างแนบเนียนในหลายที่แล้ว

  • เมื่อก่อนผมเคยใช้ Shizuku เพื่อจะใช้ Hail (เครื่องมือพักแอปชั่วคราว) บนโทรศัพท์
    แต่ช่วงหลังธนาคารที่ออกบัตรเครดิตของผมเริ่มตรวจว่ามี USB debugging หรือไม่ ผมเลยเลิกใช้มันไปแล้ว (ตอนนี้ 3DS OTP ก็ต้องรับทาง SMS แล้ว)
    ตอนนี้ในไทยมีธนาคารอยู่ราวสองแห่งที่ยังไม่ตรวจแบบนี้ แต่ผมรู้สึกว่าอีกไม่นานคงบล็อกกันหมด
    สุดท้ายผมเลยย้ายไปใช้ Dhizuku ตั้งค่าค่อนข้างยุ่งยาก แต่พอทำเสร็จแล้วก็ไม่ต้องมานั่งเปิด Shizuku แบบซับซ้อนทุกครั้งอีก ให้ความรู้สึกคล้าย untethered jailbreak เต็มรูปแบบ
    Dhizuku ทำงานโดยพื้นฐานเหมือนโทรศัพท์บริษัท ต่างกันแค่ว่าเจ้าของคือผมเอง
    เพื่อให้ “จัดการโปรไฟล์หลัก” ได้ ต้องลบบัญชีทั้งหมดออกจากระบบบัญชีของ Android และพิมพ์คำสั่ง ADB ยาว ๆ จึงแทบเป็นไปไม่ได้ที่จะนำไปใช้ในทางไม่ดี
    ต่อไปถ้าจะใช้ F-Droid วิธีแบบนี้อาจกลายเป็นมาตรฐานในหมู่วิศวกรก็ได้

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

  • อุปกรณ์นี้เป็นของผมแน่นอน และผมก็ควรใช้มันได้ตามที่ต้องการ
    แต่ก็ต้องคำนึงด้วยว่าเครื่องมือที่กล่าวถึงเหล่านี้ (Shizuku, Dhizuku) อาจส่งผลต่อความปลอดภัยของอุปกรณ์จริง และอาจทำให้โจมตีได้ง่ายขึ้น
    รวมถึงการให้สิทธิ์ DeviceOwner แก่แอปอื่นชั่วคราว ผมคิดว่าการใช้สิทธิ์เกินขอบเขตเป็นเรื่องอันตราย
    ยิ่งไปกว่านั้น ถ้าระบบความปลอดภัยอย่าง GrapheneOS เริ่มบล็อกการตั้งค่าแบบนี้ ปัญหาก็จะยิ่งใหญ่ขึ้น
    การตรวจจับรูท การตรวจ call stack ฯลฯ ในความเป็นจริงก็หลบเลี่ยงได้ง่าย จึงแทบไม่มีประสิทธิผล

  • มีแบบฟอร์มฟีดแบ็กสำหรับคนที่อยากแสดงความคิดเห็น
    ลิงก์แบบฟอร์มฟีดแบ็กของ Google
    การสนทนาที่เกี่ยวข้อง

  • ผมคิดว่านโยบายนี้จะไม่ถูกนำไปใช้กับ OEM จีน
    อุปกรณ์จีนถูกส่งมอบโดยปิด Google Mobile Services ไว้เป็นค่าเริ่มต้น และไม่มีแอป Play Store สำหรับผู้ใช้ด้วย
    ถ้าจะบังคับให้ต้องขออนุมัติจาก Google เพื่อพัฒนาแอปภายใน มันก็ไม่สมเหตุสมผล
    ผู้ผลิตแต่ละรายคงต้องสร้างบริการไลเซนส์สำหรับดีบักของตัวเองแยกกัน และการดีบักแอปที่อิง Google ก็อาจยากขึ้นตามนั้น

  • OEM จีนจำนวนมากเดิมทีก็ไม่ได้รับการรับรองจาก Google อยู่แล้ว ดังนั้นผมจึงคิดจริง ๆ ว่านโยบายนี้คงใช้ไม่ได้กับพวกเขา
    บางราย (Huawei) มีทั้ง app store ของตัวเองและโซลูชันทดแทน Google services อยู่แล้ว
    มันเป็นอุปกรณ์ de-googled โดยพฤตินัยก็จริง แต่ก็น่าเสียดายที่หลายครั้งกลับถูกติดตั้งสปายแวร์จากอีกฝ่ายแทน

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

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

  • ฝ่าย PR ได้เงินเดือนมาเพื่อหลบเลี่ยงคำถามลำบาก ๆ แบบนี้อย่างแนบเนียน
    ในทางกลับกัน การสื่อสารลักษณะนี้ยังถูกใช้เพื่อสร้างภาพว่า Google “กำลังร่วมมืออยู่” ด้วย

  • เหตุการณ์นี้กำลังทำให้เหตุผลหลักที่ผมเลือกใช้ Android แทน iPhone หายไป

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

  • ตอนช่วงแรกที่ Android แข่งกับ iPhone จุดเด่นที่สุดของ Android คือคุณติดตั้งแอปอะไรก็ได้ที่ต้องการ โดยไม่ต้องขออนุญาตจาก Google

  • ผมคิดว่าเรื่องนี้ (การปิดนโยบายของ Google มากขึ้น) อาจย้อนมาทำให้ Google ลำบากเองในที่สุด
    ถ้า Android เดินไปในทางปิดและควบคุมเข้มเหมือน iOS แล้ว เราก็ไม่รู้ว่าจะใช้ Android ไปทำไมอีก

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

  • เพราะอย่างนี้เอง ผมจึงคิดว่าอย่างน้อยในสหรัฐฯ (และใน EU ด้วยแต่ด้วยเหตุผลอีกแบบ) Google คงใช้มาตรการนี้จริงไม่ได้
    จริง ๆ ผมไม่คิดด้วยซ้ำว่าพวกเขาจะกล้าลองทำแบบนี้ แต่ตอนนี้เริ่มรู้สึกว่าอะไรก็เกิดขึ้นได้แล้ว เลยเดาไม่ออกเหมือนกัน