นักพัฒนา Android ของ Google ที่ตกเป็นตัวประกัน

 (solutional.ee)
2 คะแนน โดย GN⁺ 2023-08-28 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • งานบำรุงรักษาเล็ก ๆ เพื่ออัปเดต targetSdkVersion ของแอป Android แบบเลกาซีให้เป็นไปตามข้อกำหนดของ Google ลุกลามกลายเป็นเหตุขัดข้องในโปรดักชันบน Android 13 และการรอการตรวจสอบจาก Google Play ที่ยาวนาน
  • แอปเดิมจำเป็นต้องกำหนดเป้าหมายเป็น API level 31 ขึ้นไป เพื่อให้ยังคงเผยแพร่ต่อผู้ใช้บนอุปกรณ์ Android เวอร์ชันสูงกว่าระดับเป้าหมายได้ และผู้เขียนได้อัปจาก API level 30 เป็น 33 แล้วปล่อยใช้งาน
  • รีลีสแรกได้รับการอนุมัติภายใน 1 ชั่วโมง แต่บนอุปกรณ์ Android 13 จริง แอปเกิด แครช ทันทีหลังล็อกอิน และไม่มี วิธีโรลแบ็ก กลับไปเวอร์ชันก่อนหน้าที่ใช้งานได้ปกติ
  • บิลด์ที่แก้ไขถูกส่งทันทีหลังแก้โค้ด แต่ค้างอยู่ในสถานะรอตรวจสอบราว 72 ชั่วโมง และท้ายที่สุดเพิ่งถูกเผยแพร่สู่โปรดักชันในวันที่ 4 กันยายน หลังผ่านไป 11 วัน
  • แม้จะดูแลซอร์สโค้ดและโครงสร้างพื้นฐานเอง แต่แอปมือถือแบบเนทีฟยังถูกผู้ดูแล แอปสโตร์ ควบคุมช่องทางส่งมอบขั้นสุดท้าย ทำให้มีข้อจำกัดด้านการแก้ไขฉุกเฉิน การโรลแบ็ก และความเร็วในการปล่อยอัปเดต

การอัปเดต SDK เล็กน้อยที่ลุกลามเป็นอุบัติเหตุในโปรดักชัน

  • งานบำรุงรักษานี้เป็นของ แอปพลิเคชัน Android แบบเลกาซี ที่ลูกค้าใช้งานอยู่
    • ฟังก์ชันต่าง ๆ สมบูรณ์มาหลายปีแล้ว และไม่ใช่แอปที่กำลังพัฒนาอย่างต่อเนื่อง
    • ในอุดมคติคืออยากคงเวอร์ชันที่เสถียรไว้ตามเดิม
  • Google แจ้งข้อกำหนดระดับ Android API ทางอีเมลเมื่อวันที่ 18 สิงหาคม 2023
  • ใจความสำคัญของคำแนะนำจาก Google คือ แอปเดิมต้องกำหนดเป้าหมายเป็น API level 31 ขึ้นไป หากต้องการให้ยังคงเผยแพร่ต่อผู้ใช้บนอุปกรณ์ Android เวอร์ชันที่สูงกว่าได้
  • ผลกระทบที่แน่ชัดต่อแอปที่ติดตั้งไปแล้วไม่ชัดเจน จึงเลือกจัดการอัปเดตก่อนตามการตีความที่ปลอดภัยกว่า
  • ก่อนถึงเส้นตายเหลือเวลาไม่ถึง 3 สัปดาห์ และ Google ก็ไม่ได้ส่งการเตือนล่วงหน้าเร็วกว่านี้เกี่ยวกับข้อกำหนดดังกล่าว

เปลี่ยน targetSdkVersion จาก 30 เป็น 33

  • เริ่มงานในวันที่ 23 สิงหาคม และอัป targetSdkVersion ของแอปจาก API level 30 เป็น 33
  • บิลด์แรกไม่สำเร็จเพราะ dependency ด้านการวิเคราะห์ที่ไม่เข้ากัน
    • dependency นั้นไม่ได้ผูกกับ business logic มากนัก จึงสามารถถอดออกได้
  • จากนั้นจึงรันแอปบน Android emulator และฟังก์ชันหลักก็ดูเหมือนยังทำงานได้เหมือนเดิม
  • การเปลี่ยนแปลงนี้เป็น การอัปเดตเพื่อให้สอดคล้องกับนโยบาย ไม่ใช่การเพิ่มคุณค่าทางธุรกิจใหม่

การปล่อยบน Google Play ครั้งแรกและแครชบน Android 13

  • กระบวนการปล่อยขึ้น Google Play ในตอนแรกเป็นไปอย่างราบรื่น
    • แอปเลกาซีนี้อัปเดตเพียงปีละครั้งหรือสองครั้ง จึงต้องกรอกแบบสอบถามหลายรายการ
    • รีลีสผ่านการตรวจสอบและถูกปล่อยสู่โปรดักชันภายใน 1 ชั่วโมง
  • คืนนั้นราว 21:30 ปัญหาจึงปรากฏขึ้น เมื่อลูกค้ารายงานว่ามีผู้ใช้ล็อกอินเข้าแอปเวอร์ชันใหม่ไม่ได้
  • เมื่อลองทดสอบบนอุปกรณ์ Android จริง แอปก็ แครช ทันทีหลังล็อกอิน
  • จากการตรวจสอบเพิ่มเติมพบว่าปัญหาเกิดบน Android 13 ซึ่งเป็น Android เวอร์ชันล่าสุดในตอนนั้น ขณะที่เวอร์ชันก่อนหน้ายังทำงานปกติ
  • ในงานรอบแรกมีการทดสอบเฉพาะอิมเมจ emulator รุ่นเก่า จึงไม่พบปัญหาความเข้ากันได้
  • หากได้ทดสอบหลายเวอร์ชันของ Android ก็น่าจะจับปัญหานี้ได้
    • แม้ขอบเขตการเปลี่ยนแปลงจะเล็กและมีแรงกดดันเรื่องเส้นตายจนทำให้มั่นใจเกินไป แต่การครอบคลุมการทดสอบที่ไม่เพียงพอก็เป็นความผิดพลาดของทีม

โครงสร้างการปล่อยที่ปิดกั้นการโรลแบ็ก

  • การตอบสนองแรกที่ปลอดภัยที่สุดคือกู้คืนรีลีสก่อนหน้าที่ใช้งานได้ปกติ แล้วค่อยตรวจสอบแครชในเวลางานถัดไป แต่ Google Play ไม่มีตัวเลือกนั้น
  • ไม่มีวิธีถอนรีลีสโปรดักชันล่าสุดแล้วเปิดใช้งานเวอร์ชันก่อนหน้าอีกครั้ง
  • ทางเลือกถัดไปคือเปลี่ยน targetSdkVersion กลับไปเป็น 30 แล้วเพิ่มเวอร์ชันแอปเพื่อเผยแพร่บิลด์ใหม่ แต่ Google Play ปฏิเสธ
    • แม้ข้อความแนะนำที่เผยแพร่ดูเหมือนจะอนุญาต target ที่ต่ำกว่าจนถึงวันที่ 1 กันยายน แต่กลับเกิดข้อผิดพลาดว่าอัปเดตใหม่ต้องกำหนดเป้าหมายเป็น API level 33
  • มีการขอขยายเวลาที่อนุญาต API level 30 จนถึงวันที่ 1 พฤศจิกายน แต่ข้อผิดพลาดตอนเผยแพร่ก็ยังคงเดิม
  • เส้นทางที่เป็นไปได้จึงเหลือเพียงแก้แครชบน Android 13 แล้วส่งรีลีสใหม่

การแก้ไขภายใต้แรงกดดันและการรอตรวจสอบที่ยาวนาน

  • เวอร์ชันที่มีปัญหากำลังทยอยถูกส่งถึงผู้ใช้ผ่านการอัปเดตอัตโนมัติ และยิ่งบิลด์แก้ไขไปถึงโปรดักชันเร็วเท่าไร ก็ยิ่งลดจำนวนลูกค้าที่ได้รับผลกระทบได้มากขึ้น
  • สามารถทำให้แครชเกิดซ้ำได้บน Android 13 emulator และการแก้โค้ดที่ต้องทำก็มีไม่มาก
  • อย่างไรก็ตาม งานนี้ต้องทำในช่วงดึกภายใต้แรงกดดัน และมีเวลาอย่างจำกัดสำหรับการทดสอบ regression แบบครอบคลุม
  • แผนในตอนนั้นจึงใกล้เคียงกับการรับมือเชิงปฏิบัติ
    • แก้แครชที่ทราบทั้งหมด
    • ทดสอบ flow ที่สำคัญที่สุด
    • ส่งเวอร์ชันแก้ไขทันที
    • ทดสอบในวงกว้างต่อ และเตรียมอัปเดตเพิ่มเติมหากจำเป็น
  • บิลด์ใหม่ถูกส่งขึ้น Google Play แต่ผ่านไป 2 ชั่วโมงก็ยังค้างอยู่ในสถานะรอตรวจสอบ และตอนราว 01:00 ก็ยังไม่ได้รับการอนุมัติ
  • เช้าวันถัดมา แอปก็ยังอยู่ในสถานะ in review
  • เกือบทั้งวันถูกใช้ไปกับการทดสอบ Android 13 และตรวจสอบ Google Play Console พร้อมพบและแก้ปัญหาเล็กน้อยอีกไม่กี่จุดที่ไม่ร้ายแรงเท่ากับแครชตอนล็อกอิน
  • จนสิ้นวันนั้น เวอร์ชันแก้ไขสำหรับโปรดักชันก็ยังไม่ได้รับการอนุมัติ
  • ตอนนั้นบิลด์แก้ไขค้างรออยู่ราว 72 ชั่วโมง โค้ดถูกแก้แล้ว แต่การปล่อยกลับติดอยู่ในคิวตรวจสอบที่ไม่โปร่งใส

อัปเดตภายหลัง: การตรวจสอบ แชตซัพพอร์ต และการทยอยปล่อย

  • วันที่ 27 สิงหาคม ผู้เขียนนำเรื่องนี้ไปโพสต์บน Hacker News และมีทั้งการถกเถียงและคำวิจารณ์เกี่ยวกับกลยุทธ์การปล่อย Android ตามมา
    • บทความขึ้นหน้าแรก และตลอดหลายวันมีผู้เข้าชมไม่ซ้ำกันราว 130,000 คน
    • เว็บไซต์แบบสแตติกที่รันบน VPS ค่าใช้จ่ายราว €5 ต่อเดือนสามารถรองรับทราฟฟิกนี้ได้
    • ความสนใจดังกล่าวไม่ได้ทำให้ Google ตอบสนอง และอัปเดตแอปก็ยังคงอยู่ระหว่างการตรวจสอบ
  • วันที่ 1 กันยายน จึงพบ แชตซัพพอร์ต ที่ซ่อนอยู่หลังไอคอนเครื่องหมายคำถามใน Google Play Console
    • เจ้าหน้าที่ซัพพอร์ตรับปากว่าจะเร่งการตรวจสอบ แต่ไม่ได้ให้กรอบเวลาหรือทางออกที่ชัดเจน
    • น่าสังเกตว่าไม่มีใครในเธรดสนทนาขนาดใหญ่บน Hacker News เอ่ยถึงช่องทางนี้เลย
    • อาจเป็นเพราะ Google มีชื่อเสียงว่าเข้าถึงฝ่ายซัพพอร์ตได้ยาก จนนักพัฒนาไม่คาดหวังความช่วยเหลือโดยตรง
  • วันที่ 4 กันยายน อัปเดตที่แก้ไขแล้วจึงถูกเผยแพร่ในที่สุด หลัง การตรวจสอบ 11 วัน
  • หลังจากนั้นมีการส่งรีลีสย่อยถัดไปที่เล็กกว่า โดยใช้ การทยอยปล่อย แทนการส่งให้ผู้ใช้ 100% ทันที และอัปเดตนี้ผ่านการตรวจสอบภายใน 1 ชั่วโมง
  • วันที่ 7 กันยายน มีการส่งอัปเดตเล็กอีกตัวเพื่อแทนที่เวอร์ชันที่เข้าถึงผู้ใช้ไปแล้ว 99.9999%
    • ทันทีที่เวอร์ชันใหม่เข้าสู่การตรวจสอบ Google ก็หยุด rollout ก่อนหน้าโดยอัตโนมัติโดยไม่มีคำเตือน
    • หากการตรวจสอบรอบใหม่ใช้เวลาหลายวัน ผู้ใช้ที่เหลืออยู่ก็คงไม่ได้รับรีลีสก่อนหน้าด้วยเช่นกัน
    • ต่อให้ถอนการส่งเวอร์ชันใหม่ rollout ก่อนหน้าก็ไม่ถูกกู้คืน
    • โชคดีที่การตรวจสอบรอบนี้จบภายใน 1 ชั่วโมง

การควบคุมของแพลตฟอร์มที่เปลี่ยนความรับผิดชอบในโปรดักชัน

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

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

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

 
GN⁺ 2023-08-28
ความคิดเห็นจาก Hacker News

  • ผมได้รับอีเมลนี้ทั้งในฐานะส่วนตัวและในงาน
    ในส่วนตัว ผมทำและดูแลแอปโอเพนซอร์สสำหรับระบบขนส่งสาธารณะใน 16 เมืองแบบอาสา และต้อง อัปเดตแอป 16 ตัวภายใน 2 สัปดาห์ เพราะงานที่ไม่ได้เป็นประโยชน์กับใครเลย
    แอปของผมเป็น PWA และเวอร์ชัน Android เป็นรูปแบบที่ใช้ Cordova กับปลั๊กอินบางตัวเพื่อเพิ่มตัวเลือกแบบเนทีฟเล็กน้อย แต่พออัปเกรด Cordova เพื่อรองรับ Android API เป้าหมายใหม่ ปลั๊กอินที่ยังไม่ได้อัปเดตก็พัง ทำให้ต้องทำงานและทดสอบตลอดทั้งสุดสัปดาห์
    พูดตรง ๆ คืออยากเลิกทำแอป แล้วให้ผู้ใช้เข้าเว็บไซต์ไปติดตั้ง PWA เอง แต่ผู้ใช้ทั่วไปยังไม่รู้วิธีนั้น ที่แรกที่ผู้ใช้ไปค้นหาแอปก็ยังเป็น Play Store อยู่ดี ถ้า Google แค่ยอมให้ ส่ง PWA เข้าแอปสโตร์ได้โดยตรง ก็คงดี และผมไม่อยากต้องทำเรื่องนี้ซ้ำทุกปี
    ในงานก็รับมือกันอย่างวุ่นวายเหมือนกัน มีแอปเลกาซีที่ลูกค้าซัพพอร์ตบางส่วนใช้จนถึงสิ้นปี เป็นแอปที่ค่อนข้างซับซ้อน แค่เปลี่ยนเวอร์ชัน API เป้าหมาย หลายส่วนก็พังตั้งแต่การทดสอบพื้นฐานแล้ว เราได้รับการขยายเวลาแล้ว แต่รู้ดีว่าอัปเดตที่ไม่มีการเปลี่ยนแปลงฟีเจอร์ใด ๆ นอกจากทำให้ Google พอใจนี้ จะต้องใช้เวลานักพัฒนา 1–2 สัปดาห์ และ QA 1–2 สัปดาห์ ทั้งที่พอลูกค้าทั้งหมดย้ายไปแอปใหม่แล้ว ก็จะถอดแอปนี้ออกจากสโตร์อย่างเป็นทางการช่วงปลายปีอยู่ดี

    • มี Trusted Web Activities (TWA) ไว้ใช้ในกรณีแบบนี้ สามารถเอา PWA ขึ้น Play Store ได้โดยไม่ต้องใช้เฟรมเวิร์กอย่าง Cordova
      https://rangle.io/blog/publishing-a-web-app-to-the-play-stor...
      https://developers.google.com/codelabs/pwa-in-play#0
    • ขอพูดให้ชัดว่า ไม่ใช่แค่เพราะผู้ใช้ไม่รู้วิธีเท่านั้น แต่เพราะ Google และ Apple ไม่ได้ทำให้มันง่ายเท่ากับการติดตั้งแอปจากแอปสโตร์ของตัวเอง นั่นเป็นทางเลือก และเป็น ทางเลือกที่ตั้งใจทำ
    • ดูเหมือนคุณจะเข้าใจผู้ใช้ผิด ไม่ใช่แค่เรื่องความไม่รู้เฉย ๆ ผมอยากให้แอปกลับไปเป็นแอปเนทีฟจริง ๆ อีกครั้ง คือไม่ใช่แนว Cordova แทบไม่มีเว็บแอปไหนที่เทียบประสบการณ์ของแอปจริงที่ทำมาดีได้ ไม่ใช่ของบนเว็บที่ทำลวก ๆ
    • เห็นด้วย แอปส่วนตัวของผมหลายตัวก็ได้รับผลกระทบ
      แต่เดดไลน์นี้มีการแจ้งเตือนมาต่อเนื่องหลายเดือนแล้ว และเห็นได้ชัดว่าสักวันมันจะถูกแสดงให้เด่นชัดขึ้นแน่นอน ผมไม่ชอบถ้อยคำที่ใช้ และการบ่นว่าเวอร์ชัน production ยังใช้ได้แต่เวอร์ชันทดสอบไม่ผ่านเกณฑ์ก็ฟังไม่ขึ้น
      อีกอย่างมันเป็นปัญหาที่ต้องผลักอัปเดตใหม่อยู่เสมอ และเป็นแบบนี้ทุกปี แอปยังสามารถเปิดสาธารณะต่อไปได้อีกพักหนึ่ง
      ดังนั้นคำว่า มีเวลาแค่ 2 สัปดาห์ จึงไม่ถูกต้องนัก
    • ไม่รู้ว่าจะช่วยได้ไหม แต่ถ้าเป็นสถานการณ์ของผม ผมจะออกอัปเดตแอปสักหลายรอบ โดยใส่หน้าจออธิบายวิธีติดตั้งเวอร์ชัน PWA แล้วค่อย ๆ ถอยออกจากปัญหาเหล่านี้ น่าจะใส่ฟอร์มรับฟีดแบ็กเกี่ยวกับความยากลำบากที่ผู้ใช้เจอได้ด้วย

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

    • เห็นด้วยว่ามีหลายจุดที่ทำได้ดีกว่านี้ แต่ตามที่อธิบายไว้ นี่เป็น แอปพลิเคชันเลกาซี ไม่ใช่แอปที่กำลังพัฒนาอย่างคึกคักในปัจจุบัน การสร้างระบบ QA ที่แข็งแรงขนาดนั้นจึงไม่สมเหตุสมผล แอปนี้เขียนโดยบริษัทอื่นเมื่อนานมาแล้ว และไม่มีแม้แต่ unit test ง่าย ๆ นั่นคือความเป็นจริง
      แต่ต่อให้มีระบบที่ซับซ้อนขนาดนั้น ความผิดพลาดก็ยังเกิดขึ้นได้ และปัญหาจริง ๆ คือไม่มีวิธี revert, cancel หรือ rollback release
      ในสถานการณ์นี้ การปล่อยแบบเป็นขั้นช่วยลูกค้าทุกคนได้อย่างไร? เมื่อผู้ใช้ปลายทางได้รับเวอร์ชันที่เสียแล้ว มีวิธีให้เขาได้รับเวอร์ชันที่ใช้งานได้หรือไม่?
    • ขอให้ทิป ช่องกรอกนั้นรับค่าทศนิยมด้วย เรามักตั้งเป็น 99.99999999% เพื่อไม่ให้มีผู้ใช้หลุดไปโดยไม่ตั้งใจ และยังสามารถยกเลิกการปล่อยได้ตามที่บอก
    • ถ้าต้องดูแลเวอร์ชวลแมชชีนสำหรับ Android ทุกเวอร์ชันที่รองรับ ก็เอาเถอะ แต่สุดท้ายก็อดสงสัยไม่ได้ว่าแล้ว ค่าธรรมเนียม 30% ของรายได้นั้นเขาเก็บไปเพื่ออะไรกันแน่
    • ฟังดูเหมือนโทษเหยื่ออยู่เล็กน้อย สองเรื่องนั้นไม่ควรเป็นปัญหาตั้งแต่แรก
    • สิ่งที่พูดมาถูกต้องทั้งหมด และเป็นวิธีเดียวที่ปฏิบัติได้จริงสำหรับการอัปเดตและ release แต่น่าเสียดายที่เราไม่สามารถคาดหวังได้ว่าเมื่ออัปเดต API แล้วคอมไพล์ผ่าน มันจะทำงานได้เหมือนเดิม

  • ไม่เข้าใจปฏิกิริยาที่ไล่บี้ผู้เขียนต้นฉบับ แน่นอนว่าเขาอาจระวังได้มากกว่านี้ และอาจทดสอบการล็อกอินบน Android เวอร์ชันล่าสุดได้ แต่ถ้าไม่ใช่แครชตอนล็อกอินล่ะ? ถ้ามันทำงานบนเวอร์ชันล่าสุด แต่ใช้ไม่ได้บนเวอร์ชันอื่นล่ะ? แล้วควรขีดเส้นตรงไหน?
    ถึงจุดหนึ่งก็ควรพูดได้ว่า “นี่คือแพลตฟอร์มที่มีแอปหลายล้านแอปและนักพัฒนาหลายล้านคนใช้งานอยู่ตามตัวอักษร ความผิดพลาดเกิดขึ้นได้ และควรแก้ได้ง่าย ๆ เช่น เปิดเผยแพร่เวอร์ชันก่อนหน้าที่เคยได้รับอนุมัติแล้วอีกครั้งทันที แม้จะไม่รู้เทคนิคอย่างการหยุดการเผยแพร่ด้วยตัวเองหรือการทยอยปล่อยก็ตาม” โดยเฉพาะในที่อย่าง App Store การทำให้ย้อนกลับได้และกู้คืนได้คือ หลักการออกแบบพื้นฐาน

    • ผมคือผู้เขียนต้นฉบับ ขอบคุณที่ช่วยคิดไปด้วยกัน อย่างที่บอกไปแล้วในหลายคำตอบ ผมเห็นด้วยเต็มที่ว่าในแง่การทดสอบ ผมน่าจะทำได้ดีกว่านี้ แน่นอนว่าส่วนนี้ยังมีพื้นที่ให้ปรับปรุงอยู่เสมอ
      Google เป็นคนกำหนดเดดไลน์ และขอย้ำอีกครั้งว่า ผมเพิ่งได้ยินเรื่องนี้ครั้งแรกวันที่ 18 สิงหาคม ก่อนหน้านั้นไม่รู้เลย การเปลี่ยนแปลงตอนนั้นดูเล็กน้อย และเพราะแอปยังทำงานบน Android เวอร์ชันเก่าเหมือนเดิม ผมจึงไม่คาดคิดว่ามันจะล้มเหลวอย่างเละเทะขนาดนี้
      ผมไม่ใช่นักพัฒนา Android ที่เชี่ยวชาญ แต่มีประสบการณ์ด้านการพัฒนาซอฟต์แวร์โดยรวมมากกว่า 15 ปี จึงพอมีเซนส์ของตัวเองว่าอะไรจะทำงานอย่างไร ควรคาดหวังหรือกังวลอะไร ผมไม่รู้จริง ๆ ว่าแนวปฏิบัติที่ดีคือการทำ ทยอยปล่อยแบบ 99.99999999% เพื่อเหลือความเป็นไปได้ในการ “ถอน” รีลีสล่าสุดได้แม้เพียงบางส่วน
      ผมไม่เคยคิดฝันเลยว่าจะไม่มีวิธียกเลิกหรือลบรีลีสล่าสุดเพื่อกลับไปยังเวอร์ชันเดิมที่ทำงานได้ปกติ ดูเหมือนเรื่องแบบนี้ต้องเจอเองถึงจะเรียนรู้
      จะโทษผมที่ไม่ได้ทดสอบทุกฟีเจอร์บน Android ทุกเวอร์ชันก็ได้ และผมก็คิดแบบนั้นเหมือนกัน แต่ผมอยากให้เปิดตาและเข้าใจว่า วิธีที่ Play Store จัดการรีลีสในปัจจุบันนั้น ถ้าอยู่นอก Play Store คงไม่ใช่วิธีที่คนปกติจะทำกันเลย ใครก็อาจเจอปัญหาแบบนี้ได้สักวัน และผมหวังว่าบทความนี้กับเธรดนี้จะช่วยลดจำนวนผู้พัฒนาที่ต้องเจอสถานการณ์คล้ายกันได้
    • ประโยคที่ว่า “ถ้ามันใช้ได้บนเวอร์ชันล่าสุด แต่ใช้ไม่ได้บนเวอร์ชันอื่นล่ะ?” เป็นข้อแก้ตัวที่อ่อนมาก ต่อให้เป็นเว็บแอปก็ยังต้องทดสอบบนหลายเบราว์เซอร์
      Smoke test สำหรับรีลีสใหม่คือจรรยาบรรณพื้นฐานของอาชีพ
      การทยอยปล่อยพร้อมระบบ rollback ก็ไม่ใช่แนวคิดใหม่อะไร
    • การพอร์ตแอปไป Android 13 หรือก็คือ targetSdkVersion 33 แล้วไม่ทำ การทดสอบบน Android 13 นั้นไม่มีข้อแก้ตัว

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

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

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

    • ใช่ นั่นเป็นด้านหนึ่งของปัญหา และผมก็ไม่ได้เรียกร้องให้มี ความเข้ากันได้ย้อนหลัง มากเกินไปด้วย ความกังวลใหญ่ที่สุดในสถานการณ์นี้คือ บน Android ไม่มีวิธีคืนกลับ ยกเลิก หรือ rollback รีลีสได้ และทุกอย่างถูกขวางไว้หลังขั้นตอนรีวิวของ Google
      ทำไมถึงเป็นไปไม่ได้ที่จะ “ถอน” รีลีสที่มีปัญหา แล้วให้รีลีสก่อนหน้ายังคงแสดงเป็นเวอร์ชันล่าสุดต่อไป? ถ้าทำได้ ในบริบทของปัญหานี้ก็จะแก้ได้เกือบหมด
    • ผมคิดว่าจุดกึ่งกลางที่เป็นประโยชน์กับทุกคนคือการเปลี่ยน API แล้วทำให้การคอมไพล์พังไปเลย ให้ดีเวลลอปเปอร์แก้ compile error และใช้ API ให้ถูกต้อง
      แต่ไม่ควรเปลี่ยนพฤติกรรมของฟังก์ชันเดิมที่มี signature เดิม ถ้าเป็นผู้ให้บริการ API ก็ควรพยายามอย่างเต็มที่เพื่อให้ การคอมไพล์มีความหมาย
    • ไม่มีทางเลือกที่ชนะได้ดีที่สุด แต่ก็สามารถแจกจ่ายแอปแยกต่างหากได้ นี่ไม่ใช่ข้อกำหนดของ Android แต่เป็น ข้อกำหนดของ Play Store
      ในหลายกรณีมันไม่ง่ายเลย และคงไม่มีทางถูกใช้มากเท่าเวอร์ชันบน Play Store แต่การมีทางหนีไว้ก็ดี
    • ดูเหมือนสิ่งที่ผู้เขียนบ่นเป็นหลักคือการที่ Google ทำหน้าที่เป็นผู้ตัดสินว่าผู้ใช้สามารถรันซอฟต์แวร์อะไรได้ ปัญหา API ถูกเลิกใช้เป็นเพียงชนวนที่ทำให้เราตระหนักว่าเราเปราะบางต่อ ความเอาแน่เอานอนไม่ได้ของ Google แค่ไหน
    • ผมยอมรับเรื่องนี้เป็นข้อแก้ตัวของ Google ได้ยาก
      แอปพลิเคชันส่วนใหญ่ที่แจกจ่ายบน Android มุ่งเป้าไปที่ Android bytecode ไม่ใช่แอปพลิเคชันที่คอมไพล์เป็นเนทีฟ
      เหตุผลที่ C++ สร้างปัญหาความปลอดภัยที่เอาชนะได้ยากคือธรรมชาติแบบระดับต่ำ และข้อเท็จจริงที่ว่าเมื่อได้ native binary แล้วก็จบแค่นั้น
      แต่ถ้าเป็น bytecode ของภาษาที่มี memory safety แล้ว มีเหตุผลอะไรที่จะแบ็กพอร์ตแพตช์ความปลอดภัยไม่ได้? การรันโค้ดแบบนั้นโดยตัวมันเองก็มีลักษณะของการคอมไพล์ bytecode ซ้ำอยู่เรื่อย ๆ
      ถ้าจะดูว่าจุดยืนนี้ไร้สาระต่อ Google แค่ไหน JVM จนถึงตอนนี้ก็ยังรันและใช้งาน คลาสที่ target Java 1.0 จากปี 1996 ได้
      นี่ไม่ใช่ปัญหาความปลอดภัย แต่เป็นปัญหา “Google ไม่อยากสนับสนุนแพลตฟอร์ม”
      ผมพอเข้าใจได้ในระดับหนึ่งถ้า Google จะเข้มงวดกับชิ้นงานที่มีโค้ดคอมไพล์เนทีฟอยู่ข้างในมากขึ้น แต่การมีนโยบายแบบเหมารวมว่า “แอปถูก build โดย target Android เวอร์ชันเก่า เราเลยจะไม่ซัพพอร์ตอีกต่อไป” นั้นพูดไม่ขึ้น ดูเหมือนเป็นวิธีตัดแอปเก่าออกจากสโตร์มากกว่าจะเกี่ยวกับความปลอดภัย
      โดยเฉพาะอย่างยิ่ง นโยบายแบบนี้โดยเนื้อแท้คือการโยนภาระการบำรุงรักษาขนาดใหญ่ให้ดีเวลลอปเปอร์ Android ถ้าต้องการรองรับแอปพลิเคชันให้กว้างที่สุด ก็ย่อมเลือก target Android เวอร์ชันเก่าที่สุดเท่าที่ทำได้ แทบไม่มีใครเลือก target Android เวอร์ชันล่าสุด เพราะกลัวว่าจะตัดลูกค้าออกไปมากเกินไป
      ถ้า Google จริงจังกับความปลอดภัยและการเข้าถึงเทคโนโลยี Android ใหม่ ๆ อย่างกว้างขวาง ก็ควรพยายามแยก Android runtime ออกจากเวอร์ชันระบบปฏิบัติการ ไม่มีเหตุผลอะไรที่จะแจกจ่าย ART และ Dalvik runtime ผ่าน Google Play เหมือนส่วนอื่น ๆ ของอีโคซิสเต็ม Android ไม่ได้ และยังจะกำจัดสถานการณ์โง่ ๆ แบบ “ถ้าจะทำสิ่งนี้ต้องใช้ Android 17… อ้อ ผู้ผลิตฮาร์ดแวร์ไม่อัปเดตไดรเวอร์นี่นา” ได้ด้วย
      แต่ถ้าทำอย่างนั้นยอดขายเครื่องใหม่คงได้รับผลกระทบ จึงคงยอมรับไม่ได้สินะ

  • เห็นได้ชัดมาตลอดว่า Play Store และ “คอมมูนิตี้” ดีเวลลอปเปอร์ที่ถูกขังอยู่ในนั้นเป็นกับดัก การบังคับอัปเกรด API เป็นแค่ด้านหนึ่งของเรื่องนั้น
    แน่นอนว่ามีงานบางอย่างที่โทรศัพท์หรือแอปมือถือทำได้ดีที่สุด โดยปกติคือสิ่งที่เกี่ยวข้องกับการเคลื่อนที่ เช่น การนำทาง หรือสิ่งที่พึ่งพาเซนเซอร์ของโทรศัพท์ เช่น การหาว่าด้านไหนคือ “ข้างบน” แต่แทบทุกอย่างที่เหลือทำเป็นเว็บไซต์ได้
    ถ้าเป็นดีเวลลอปเปอร์คนเดียวที่ต้องดูแลแอปมือถือข้ามแพลตฟอร์ม คงลำบากจริง ๆ และผมเห็นใจ เพียงแต่ผมตัดสินใจไปนานแล้วว่าไม่อยากเล่นเกมของ แพลตฟอร์มกรรมสิทธิ์และ gatekeeper ดังนั้นจึงเห็นใจได้เฉพาะจากมุมมองของคนนอกโดยสิ้นเชิง

    • จริง ๆ แล้วสองอย่างนั้นก็ทำได้ง่ายในแอปเบราว์เซอร์เหมือนกัน
      สิ่งเดียวที่ยังทำบนมือถือได้ไม่ง่ายในตอนนี้แทบจะมีแค่ GPU compute shader เท่านั้น แต่ถ้า WebGPU ข้ามมาจากเบราว์เซอร์เดสก์ท็อปเมื่อไร เรื่องนั้นก็คงพังทลายเช่นกัน
      อีกอย่างที่นึกออกคือการจัดการไฟล์ทั่วทั้งระบบแบบทั่วไป สิ่งนั้นคงไม่มีวันมาถึง File System API อนุญาตให้ผู้ใช้มอบสิทธิ์เข้าถึงไดเรกทอรีบางแห่งได้ก็จริง แต่ผมไม่รู้ว่าสิทธิ์นั้นจะยังคงอยู่หลังรีเฟรชหน้าเว็บหรือไม่
    • ผมเคยมั่นใจว่า app store จะล้มเหลว เพราะไม่คิดว่าจะมีดีเวลลอปเปอร์มากพอที่ยอมสละหลักประกันว่าตนจะสามารถแจกจ่ายแอปของตัวเองได้จริง
    • อ่านเรื่องนี้บนเว็บที่มักโจมตี Google ว่าคุม gatekeeping ซอฟต์แวร์บน Android ไม่มากพอ และยกย่อง iPhone ว่าดีกว่าเพราะกวดขันอย่างเข้มงวดกว่าแล้วก็ขำดี
    • คงไม่อยากยืนกรานเชิงอุดมการณ์เรื่องอำนาจอธิปไตยของผู้ใช้เหนืออุปกรณ์ของตัวเองสินะ? แทนที่จะทำแบบนั้น ก็ทำตัวฉลาดและปฏิบัติจริง เดินตามเส้นทางที่มีแรงต้านน้อยที่สุดเข้าไปในคอกก็พอ

  • เมื่อคิดถึงหลักการข้อหนึ่งของ SRE ของ Google ที่ว่า “การ rollback เป็นเรื่องปกติ” ก็ถือว่าน่าขัน
    https://cloud.google.com/blog/products/gcp/reliable-releases...
    “ที่ Google ปรัชญาของเราคือ ‘การ rollback เป็นเรื่องปกติ’ หากพบข้อผิดพลาดในรีลีสใหม่ หรือมีเหตุให้สงสัยอย่างสมเหตุสมผล ทีมรีลีสจะ rollback ก่อน แล้วจึงค่อยตรวจสอบปัญหา คำขอ rollback จะไม่ถูกตีความว่าเป็นการโจมตีทีมรีลีสหรือคนที่เขียนโค้ดที่มีบั๊ก ตรงกันข้าม มันถูกเข้าใจว่าเป็น สิ่งที่ถูกต้อง เพื่อทำให้ระบบมีความน่าเชื่อถือมากที่สุดสำหรับผู้ใช้ ตราบใดที่รายการเปลี่ยนแปลงสำหรับ rollback อธิบายปัญหาที่สังเกตพบไว้ ก็จะไม่มีใครถามว่า ‘ทำไมถึง rollback การเปลี่ยนแปลงนี้’”

    • เมื่ออ้างอิงจากปีที่แล้ว ผลจากการที่นโยบาย Google Play กับการอัปเดต Android ปะปนกัน ทำให้ถ้าเผยแพร่แอปผ่าน Play Store วิธีเดียวที่จะ rollback ได้คือ ลบแอปแล้วรีเซ็ตข้อมูลผู้ใช้
      ไม่สามารถดาวน์เกรดไปยัง versionCode ที่ต่ำกว่าได้ และ versionCode เป็นสิ่งที่นักพัฒนากำหนดเอง
      Android 11 ห้ามเขียนลงในพื้นที่เก็บข้อมูล “ถาวร” ของโทรศัพท์ ยกเว้นกรณียกเว้นเกี่ยวกับสื่อ หรือการใช้ API DocumentFile ที่ปฏิบัติกับโฟลเดอร์ในเครื่องเหมือนที่เก็บข้อมูลบนคลาวด์ แต่ DocumentFile ใช้ไม่ได้กับหลายกรณีการใช้งาน
      นักพัฒนาสามารถตั้งค่า hasFragileUserData ได้ ซึ่งเมื่อมีการลบแอป จะต้องถามผู้ใช้ว่าจะลบข้อมูลหรือไม่ แต่เนื่องจากบั๊กของ Google/Android กล่องโต้ตอบนี้อาจไม่ปรากฏขึ้น
      ถ้าลบแอปแล้วผู้ใช้ไม่ได้ลบข้อมูล Android จะป้องกันการดาวน์เกรดไปยัง versionCode ที่ต่ำกว่า
      หากขอ MANAGE_EXTERNAL_STRORAGE ก็จะสามารถใช้ java.io.File แบบปกติได้
      Google Play อนุญาต MANAGE_EXTERNAL_STRORAGE เฉพาะในกรณีพิเศษเท่านั้น
    • “สำหรับฉันมี rollback แต่สำหรับเธอไม่มี rollback”

  • เรื่องเดียวกันนี้เกิดขึ้นกับแอปหลายตัวที่ผมทำโดยใช้เฟรมเวิร์กด้วย เวอร์ชัน API ใหม่ขัดแย้งกับ dependency เดิม และต้องลงแรงมหาศาลจริง ๆ เพื่อย้อนกลับไปสู่สภาพเดิมที่เคยมีอยู่แล้ว
    มันทำให้ผมเคารพ Microsoft มากขึ้นมาก เพราะของจากยุค 90 ยังรันบน Windows รุ่นใหม่ได้ราบรื่นกว่าแอปมือถือที่เขียนบน Android เมื่อ 4 ปีก่อน

    • ถ้าเฟรมเวิร์กที่ใช้ไม่ได้มาจาก Google ก็พูดแบบนั้นไม่ค่อยยุติธรรม
      เราคงไม่โทษ Microsoft ถ้า Adobe Flash ไม่ทำงานใน Store ของ Windows 11 ใช่ไหม?

  • ผมมองว่าการถูกบังคับให้เผยแพร่แอปผ่านแอปสโตร์ “ที่อนุมัติกันเอง” เพียงแห่งเดียวเท่านั้น มีข้อเสียมากเกินไปและแทบไม่มีข้อดีเลย
    ถ้าจะเรียกว่าข้อดีก็คงเป็นเรื่องที่น่าขันว่า ผู้ดูแลแอปสโตร์ช่วยตรวจมัลแวร์และไวรัสก่อนเผยแพร่ให้ แต่แอปที่เต็มไปด้วยโฆษณา Google และตัวติดตามของ Google/Facebook กลับได้รับการต้อนรับในทุกรูปแบบ
    อีกข้อคือทำให้ผู้ใช้ค้นหา ติดตั้ง และอัปเดตแอปได้ง่ายขึ้น ถ้าหาของที่ต้องการเจอท่ามกลางแอปเกมนับพันล้าน และแอปที่คล้ายกันมาก ๆ ซึ่งถูกเผยแพร่ขึ้นมาเพียงเพื่อส่งโฆษณาหรือเก็บข้อมูลส่วนตัวน่ะนะ
    ข้อเสียคือถูกผูกไว้กับอำเภอใจของผู้ดูแลแอปสโตร์ และไม่มี สิทธิ์ควบคุมกระบวนการเผยแพร่แอป ผมตัดสินใจเองไม่ได้ว่าจะเผยแพร่แอปได้หรือไม่ และเมื่อไหร่ แต่ผู้ดูแล App Store จะเป็นคนตัดสินตามความสะดวกของตนเอง ผมคิดว่าสิทธินี้ควรเป็นของผู้ใช้เท่านั้น
    สำหรับแอปเนทีฟเชิงพาณิชย์ เช่น แอปโฮมแบงก์กิ้ง ผมอยากล็อกอินเข้าไปยังพื้นที่ส่วนตัวบนเว็บไซต์ของนักพัฒนาแล้วดาวน์โหลด แอปควรมีลายเซ็น GPG และตรวจสอบความถูกต้องสมบูรณ์ของแพ็กเกจได้ ฟังก์ชันอัปเดตอัตโนมัติก็ทำได้เช่นกัน
    สำหรับแอปโอเพนซอร์สก็มีสโตร์ F-Droid และสามารถเพิ่มรีโพสิทอรีของตัวเองได้ ยอมรับว่ามันค่อนข้างเทคนิคและไม่เหมาะกับทุกคน ถ้ามี F-Droid ติดตั้งมากับมือถือใหม่ล่วงหน้าก็คงช่วยได้มาก แต่ไม่คิดว่า Google จะยอม
    อีกทางเลือกที่เป็นไปได้จริงคือ PWA ในความเห็นผม แอปที่จำเป็นต้องใช้ฟีเจอร์เนทีฟมีน้อยมาก และที่เหลือแทบทั้งหมดทำได้ด้วยเทคโนโลยี PWA ไม่จำเป็นต้องส่งอัปเดตให้ผู้ใช้หรือขอให้ผู้ใช้อัปเกรดด้วยซ้ำ
    แอปสโตร์แบบผูกขาดและเชิงพาณิชย์ที่ดำเนินงานโดยอ้างว่าทำให้ชีวิตผู้ใช้ง่ายขึ้นและให้ “ความปลอดภัยที่ดีกว่า” นั้น เป็นเครื่องมือที่ “ยอดเยี่ยม” ที่ทำให้ Apple และ Google ทำเงินได้หลายพันล้านดอลลาร์จากแรงงานของนักพัฒนาอิสระ และในกรณีของ Google ก็ยังทำให้รวบรวมและขายข้อมูลส่วนตัวของผู้ใช้ รวมถึงขายโฆษณาได้สารพัดวิธี

    • ยังตกหล่นข้อดีอีกอย่างไป คือกัน Boston Strangler[0] ไว้นอกบ้านได้ ถ้ามัดมือผู้ใช้ไว้ข้างหลัง คุณก็เป็นคนกำหนดได้ว่าผู้ใช้จะใช้งานผลงานของคุณภายใต้เงื่อนไขแบบไหน ไม่มีการละเมิดลิขสิทธิ์ และไม่มีการบล็อกโฆษณา
      นี่คือเหตุผลที่นักพัฒนาเกมในยุค 80–90 โดยมากทำตามโมเดล “Licensed by Nintendo” และนักพัฒนาแอปมือถือในช่วงปลายทศวรรษ 2000 ก็ทำแบบเดียวกันกับ iOS App Store พวกเขาไม่อยากร่วมมือโดยตรงกับผู้ใช้เพื่อเลี่ยงเจ้าของแพลตฟอร์ม แต่ต้องการให้เจ้าของแพลตฟอร์มมัดมือผู้ใช้ให้ และยอมรับว่ามือของตัวเองจะถูกมัดไปด้วยในกระบวนการนั้น
      ยกตัวอย่างกรณีแอปธนาคาร ธนาคารต้องการการยืนยันตัวตนระยะไกลที่ปลอดภัย ต้องการบล็อกผู้ใช้ที่ทำการโจมตีแบบ credential stuffing ใส่แอป ต้องการป้องกันไม่ให้มัลแวร์เปิดแอปธนาคารแล้วกดปุ่ม “โอนเงินให้มิจฉาชีพ” และต้องการป้องกันไม่ให้ผู้ใช้ดึงค่าลับทางคริปโตที่เกี่ยวกับ tap-to-pay ออกมา รวมถึงป้องกันไม่ให้นำค่าลับที่ขโมยมาใส่เข้าไปในแอปบนมือถือ
      แอปตรวจสอบด้วยตัวเองไม่ได้ว่ามือผู้ใช้ถูกมัดอยู่หรือไม่ จึงต้องมีบุคคลที่สามที่น่าเชื่อถือสำหรับธนาคาร ไม่ใช่สำหรับผู้ใช้ อยู่ในบูตเชนหรือ EL3 เพราะฉะนั้นสิ่งที่ต้องการไม่ใช่แค่การให้แอปกับลายเซ็น แต่ต้องการให้ Google ทำให้ เพื่อให้ Google สามารถมัดมือผู้ใช้ได้
      ประเด็นสำคัญคือประโยชน์ฝั่งผู้ใช้ของแอปสโตร์ทั้งหมดเป็นการหาเหตุผลมารองรับภายหลัง ตั้งแต่แรกเป้าหมายคือการมัดผู้ใช้ไว้ เพราะสำหรับพวกเขา ผู้ใช้เป็นเหมือนยุงหัวขโมยตัวเล็ก ๆ นี่คือ “ส่วนที่เงียบ” ที่พวกเขาไม่พูดออกมาดัง ๆ
      ได้โปรดขอให้ข้อเสนอ WEI ของ Google ไม่กลายเป็นจริง และขอให้ PWA ไม่ได้เข้าถึงฟังก์ชันพิสูจน์ยืนยัน Google เริ่มทำเรื่องไร้สาระอย่าง “ถ้าเป็นเบราว์เซอร์ที่ไม่รู้จักจะล็อกอินไม่ได้” อยู่แล้ว และไม่จำเป็นต้องปล่อยให้มะเร็งนั้นแพร่กระจาย
      F-Droid ยอดเยี่ยมมาก ลูกเล่นที่ Google ทำบน Android ควรถูกหยุด EU เคยทำได้ แต่สหรัฐฯ ก็ควรทำเช่นกันและทำให้มีผลในระดับนานาชาติ
      [0] ชื่อรหัสที่ MPAA ใช้เรียกการคัดลอกขนาดเล็กที่ไม่ใช่เชิงพาณิชย์ เช่น การอัดรายการทีวีด้วย VCR Jack Valenti เป็นคนแย่จริง ๆ ใช่ไหม?

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