เมื่อแอปขอสิทธิ์ ควรมีตัวเลือก “ให้ข้อมูลปลอม”

 (archive.md)
1 คะแนน โดย GN⁺ 2023-07-09 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เมื่อแอปขอสิทธิ์ OS ไม่ควรอนุญาตให้ตอบได้แค่ ใช่/ไม่ใช่ แต่ควรเพิ่ม “ตัวเลือกให้ข้อมูลปลอม” ให้กับสิทธิ์ทุกหมวดหมู่
  • หากขอรายชื่อผู้ติดต่อ ก็ให้ รายชื่อผู้ติดต่อปลอมที่สร้างขึ้น, หากขอเข้าถึงไมโครโฟน ก็ให้เสียงสภาพแวดล้อมแบบสุ่ม, หากขอข้อมูลตำแหน่ง ก็ให้พิกัดของเกาะเล็ก ๆ ขนาด 5×5m
  • หากบล็อกการเข้าถึง แอปจะปฏิเสธว่า “ถ้าอย่างนั้นก็ใช้ไม่ได้” แต่หากให้ ข้อมูลปลอม โครงสร้างจะกลายเป็นการลงโทษเฉพาะบริการที่เรียกขอข้อมูลที่ไม่จำเป็น
  • การบอยคอตบังคับให้ผู้ใช้ต้องเสียสละส่วนตัวอย่างมาก แต่สร้างผลกระทบต่อบริษัทเพียงเล็กน้อย จึงมองว่า malicious compliance มีประสิทธิภาพกว่าการบอยคอต
  • ประเด็นนี้เชื่อมโยงไปสู่เรื่อง สิทธิ์การควบคุมของผู้ใช้ ที่ผู้ใช้ควรควบคุมแอปและซอฟต์แวร์ระบบได้ในฐานะผู้ดูแลอุปกรณ์ที่ตนเป็นเจ้าของ

ข้อเสนอหลัก — ตัวเลือกข้อมูลปลอมแยกตามสิทธิ์

  • OS ควรมีตัวเลือก “ใช่ แต่ให้ข้อมูลปลอม” สำหรับคำขอสิทธิ์ทุกหมวดหมู่ นอกเหนือจาก ใช่/ไม่ใช่
    • คำขอรายชื่อผู้ติดต่อ → ให้รายชื่อผู้ติดต่อปลอมที่สร้างแบบสุ่ม
    • คำขอไมโครโฟน → ให้เสียงสภาพแวดล้อมแบบสุ่ม (random ambiance)
    • คำขอตำแหน่ง → ตอบว่าอยู่บนเกาะเล็ก ๆ ขนาด 5×5m
  • หากบริการเรียกขอข้อมูลที่ไม่จำเป็น จะมีผลเป็นการ ลงโทษ ด้วยการใส่ข้อมูลไร้ประโยชน์ลงในฐานข้อมูลของบริการนั้น
  • ต่างจากการบล็อกการเข้าถึง ข้อมูลปลอมทำให้แอปตอบกลับว่า “ใช้งานไม่ได้” ได้ยากขึ้น ขณะเดียวกันก็ทำให้การเก็บข้อมูลที่ไม่จำเป็นหมดประสิทธิภาพ

เหตุผลที่อ้างว่าเหนือกว่าการบอยคอต

  • การบอยคอตแอปที่จำเป็นเป็นข้อตกลงที่เสียเปรียบ เพราะผู้ใช้ต้อง เสียสละส่วนตัวอย่างมาก แต่สร้างความเสียหายที่แทบไม่สะดุดตาต่อมหาเศรษฐี
    • เป็นโครงสร้างที่ฝ่ายที่ต่อสู้ต้องสูญเสียมากที่สุด จึงเสียเปรียบสำหรับผู้ใช้
  • มุมมองนี้เห็นว่าวิธีฉีดข้อมูลปลอมให้อำนาจแก่ผู้ใช้ มากกว่า
  • ใช้สำนวนว่า “malicious compliance” สนุกกว่าการบอยคอต

วิธีการที่มีอยู่ซึ่งถูกกล่าวถึงในการอภิปราย

  • Location spoofing

    • ในอดีต location spoofing ทำได้แค่เป็นการตั้งค่า แบบทั่วระบบ (global) และยากที่จะเลือกเป็นรายแอป
    • ใน Developer options ของ Android หากกำหนดแอปใดแอปหนึ่งให้เป็นแอป mock location จะถูกนำไปใช้แบบทั่วระบบ
    • Firefox มี ส่วนขยาย สำหรับ spoof ข้อมูลหลากหลาย เช่น geolocation แต่การทำงานบนโทรศัพท์น่าจะมีประโยชน์กว่า
    • มีกรณีใช้ข้อมูลตำแหน่งปลอมใน Pokémon GO เพื่อโกง จึงยืนยันได้ว่าเป็นไปได้ทางเทคนิค

  • XPrivacyLua

    • เคยทำงานได้ตรงตามที่ผู้ใช้ต้องการบนอุปกรณ์ที่ root แล้ว แต่ต้องใช้ Magisk (การแก้ไขระบบ)
    • ปัจจุบันอยู่ในสถานะ หยุดบำรุงรักษา และไม่เข้ากันได้กับอุปกรณ์ทั้งหมด

  • ฟีเจอร์สิทธิ์พื้นฐานของ Android

    • Android สามารถเลือกการเข้าถึงข้อมูลเป็นรายแอป หรือตั้งให้ถามทุกครั้งได้อยู่แล้ว
    • อย่างไรก็ตาม นั่นเป็นเพียงวิธีบล็อก ไม่ใช่ การให้ข้อมูลปลอม

ไอเดียต่อยอดและตัวอย่าง

  • การปนเปื้อนข้อมูลด้วย AI

    • มีข้อเสนอให้ป้อนข้อมูลไร้ความหมายแก่ data miner แบบวนซ้ำ เพื่อทำให้หมดประสิทธิภาพ
    • ไอเดียคือใช้ข้อมูลที่ AI สร้างขึ้นเพื่อปนเปื้อนไปถึง คอนเทนต์สำหรับฝึก AI

  • การรับมือการติดตามโฆษณา

    • กล่าวถึง AdNauseam (fork ของ uBlock Origin) ซึ่งบล็อกโฆษณาไปพร้อมกับคลิกโฆษณาทั้งหมดเพื่อทำให้ข้อมูล targeting หมดประสิทธิภาพ
    • มีการประเมินว่าความพยายามในอดีตใช้ทรัพยากรมาก

  • การก่อกวนโปรไฟล์ติดตามในเบราว์เซอร์

    • มีบริการที่หมุนไปตามหลายเว็บไซต์อย่างรวดเร็วด้วยเบราว์เซอร์และคุกกี้ เพื่อก่อกวน fingerprinting และการติดตาม
    • สามารถเลือกรูปแบบแบบสุ่มหรือแบบอิงโปรไฟล์ได้ (เช่น “ท่องเว็บเหมือนฮิปปี้ชาวเอกวาดอร์วัย 70 ปี”)
    • กล่าวถึงกรณี TrackThis ที่ Mozilla สร้างขึ้น

ข้อจำกัดและข้อกังวลที่ถูกยกขึ้น

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

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

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

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

  • เห็นด้วยกับไอเดีย “ข้อมูลปลอม” แต่แอปควรถูกกำหนดให้ จัดการอย่างนุ่มนวล แม้ผู้ใช้จะปฏิเสธสิทธิ์เข้าถึงข้อมูลจริง
    สมัยก่อนตอนพัฒนา iOS นโยบายของ Apple คือห้ามลงโทษผู้ใช้เพราะปฏิเสธสิทธิ์ หรือปิดแอปด้วย exit() และแอปต้องทำงานต่อไป
    ย้อนกลับไปนานกว่านั้น แอปยังไม่สามารถบังคับให้ต้องมี “บัญชี” เพื่อใช้งานได้ด้วยซ้ำ จำได้ว่ากว่า 10 ปีก่อน บริษัทเคยเพิ่มข้อบังคับให้ต้องมีบัญชีแล้วถูก App Store ปฏิเสธอย่างสมเหตุสมผล ทุกวันนี้เห็นแอปที่บังคับมีบัญชีมากขึ้นเรื่อย ๆ ดูเหมือนจุดยืนนี้จะผ่อนคลายลงแล้ว

    • ประโยคที่ว่า “แอปไม่สามารถเรียกร้องบัญชีเพื่อให้แอปทำงานได้” น่าจะขาดเงื่อนไขสำคัญบางอย่าง หรือไม่ก็ผมไม่เข้าใจความหมาย
      แอปธนาคาร, เกมออนไลน์, แอป Twitter ในปัจจุบัน, แอปอย่าง Dropbox/Nextcloud จะทำงานได้อย่างไรถ้าไม่มีบัญชี
      จริงอยู่ที่ในหลายแอป การบังคับบัญชีเป็นกลเม็ดทางการตลาด แต่กฎทั่วไปแบบนั้นดูไม่น่าจะใช้ได้
    • WhatsApp ยัง “ลงโทษ” ผู้ใช้อยู่ถ้าปฏิเสธการเข้าถึงรายชื่อ โดยซ่อนชื่อทั้งหมดและแสดงเฉพาะหมายเลขโทรศัพท์ แม้อีกฝ่ายจะตั้งชื่อไว้ในโปรไฟล์ของตัวเองก็ตาม
      Facebook/Meta แย่มาก
    • ข้อมูลส่วนตัวปลอม อย่างรายชื่อหรือรูปภาพยังพอรับได้ แต่พอเป็นตำแหน่งที่ตั้งแล้วจะคลุมเครือขึ้น
      ถ้าเป็นการแสดงตำแหน่งของฉันบนแผนที่หรือค้นหาธุรกิจใกล้เคียง การให้ข้อมูลปลอมก็ทำได้
      แต่ถ้าเป็นแอปทดสอบความเร็วอินเทอร์เน็ตที่ทำแผนที่ความเร็วแยกตามผู้ให้บริการ หรือแอปที่ให้ผู้ใช้รายงานสภาพอากาศในพื้นที่เพื่อปรับปรุงพยากรณ์ ก็ควรพูดได้ว่า “ให้ตำแหน่งที่แม่นยำ หรือไม่ก็อย่าให้เลย ไม่ต้องการตำแหน่งปลอม”
      แพลตฟอร์มคงต้องตัดสินว่าจะให้ข้อยกเว้นกับแอปที่รับข้อมูลจากผู้ใช้ซึ่งส่งผลต่อคนอื่นหรือไม่
      Apple ดูเหมือนจะสร้างจุดกึ่งกลางที่ค่อนข้างดีในเรื่องนี้ ผู้ใช้ไม่จำเป็นต้องอนุญาต “ตำแหน่งที่แม่นยำ” ให้แอป และสำหรับรูปภาพก็สามารถให้แอปเห็นเฉพาะรูปที่ผู้ใช้เลือกผ่านตัวเลือกรูปภาพที่ระบบจัดเตรียมให้ได้
    • สิ่งที่แย่ที่สุดบน iOS คือ Google Photos ถ้าไม่อนุญาตให้เข้าถึงรูปทั้งหมด ก็เปิดแอปไม่ได้เลย และไม่ยอมรับการอนุญาตเฉพาะรูปที่เลือกด้วย
      แม้แค่อยากดูรูปที่เก็บไว้บนคลาวด์อยู่แล้วก็ยังเป็นเหมือนกัน
    • ต่อให้พูดว่า “แอปควรจัดการอย่างนุ่มนวลแม้ผู้ใช้จะปฏิเสธสิทธิ์เข้าถึงข้อมูลจริง” แล้วถ้าไม่ทำตามจะทำอย่างไร
      นั่นเท่ากับเสนอวิธีแก้ปัญหาเชิงองค์กรให้กับปัญหาเชิงเทคนิค จึงทำงานได้ยาก และวิธีที่ใช้ได้จริงมีเพียง ข้อมูลปลอม เท่านั้น จากมุมมองของแอป ต้องทำให้ดูเหมือนว่าได้รับอนุญาตแล้ว แม้จริง ๆ จะไม่ได้รับสิทธิ์ก็ตาม

  • บน Android ที่รูทแล้ว XPrivacy ทำเรื่องแบบนี้ได้มาตั้งแต่ 7 ปีก่อน และก็มีทางเลือกสมัยใหม่อยู่บ้างเหมือนกัน แต่ผมไม่ได้รูทโทรศัพท์มานานแล้วจึงรับประกันไม่ได้: https://github.com/M66B/XPrivacy
    แน่นอนว่านี่ไม่ใช่วิธีสายหลัก และเห็นด้วยว่าควรถูกติดตั้งมาให้ในตัวตั้งแต่ต้น แต่ทั้ง Android และ iOS ต่างก็ยอมให้มีเรื่องไร้สาระอย่างแอปจำกัดภูมิภาค หรือการบล็อกการจับภาพหน้าจอของคอนเทนต์ DRM ดังนั้นคงไม่ง่าย

    • ลองใช้ในลักษณะนี้แล้วก็รู้สึกได้ด้วยตัวเองว่าในฐานะผู้ใช้มันถูกออกแบบมาให้เสียเปรียบแค่ไหน และทำให้เลิกเชื่อว่าโทรศัพท์คือคอมพิวเตอร์
      โทรศัพท์คือ อุปกรณ์ส่งมอบคอนเทนต์ของผู้ขาย และผู้ใช้ก็อยู่ในอำนาจการจัดการของพวกเขา
    • XPrivacy เจ๋งมากจริง ๆ แต่การรูทและติดตั้ง Xposed บนโทรศัพท์สมัยใหม่ซับซ้อนขึ้นมาก หรือไม่ก็ถูกปิดกั้นไปเลย
      GrapheneOS ใช้กับแอปธนาคารได้ไม่ค่อยดี, Google ทำให้การรูทผ่าน Magisk บน Android Beta พังหลายครั้ง และถึงจุดหนึ่งก็เลิกใส่ใจไป
      GrapheneOS หรือโปรเจกต์คล้าย ๆ กันอาจทำฟีเจอร์แบบนี้ได้ก็ได้
    • XPrivacy ยอดเยี่ยม แต่เมื่อปฏิเสธสิทธิ์บางอย่าง แอปมักจะตายบ่อย ๆ สุดท้ายก็เท่ากับว่ายังให้ ข้อมูลปลอม ได้ไม่ดีพอ
      หนักจนไม่กด “ปฏิเสธ” ทันที แต่จะกด “ปฏิเสธชั่วคราว” ก่อนเสมอ ถ้าแอปทำงานได้ค่อยปฏิเสธถาวร และถ้าแอปตายก็ต้องหาชุดสิทธิ์ขั้นต่ำที่จำเป็นต้องอนุญาต
    • ฟีเจอร์นี้คงไม่มีวันเข้าไปอยู่ในอิมเมจจากโรงงานหรือ Android upstream แต่ถ้าความต้องการจากผู้ใช้มากพอ ก็มีความเป็นไปได้ที่จะเข้าไปอยู่ในโปรเจกต์อย่าง LineageOS
    • “แอปจำกัดภูมิภาค” จริง ๆ แล้วไม่ใช่แบบนั้น แต่เป็นการที่แต่ละแอปสโตร์เปิดให้กระจายแอปเฉพาะในภูมิภาคที่เลือกได้
      แอปอาจมอบประสบการณ์ที่ดีไม่ได้ในทุกประเทศ, อาจยังไม่ได้แปลให้รองรับทุกภาษา, อาจไม่มีผู้ดูแลเนื้อหาสำหรับภาษานั้น, อาจต้องปฏิบัติตามกฎหมายของแต่ละประเทศ หรือไลเซนส์การเผยแพร่คอนเทนต์ลิขสิทธิ์อาจจำกัดเฉพาะบางประเทศ ดังนั้นนี่จึงเป็นฟีเจอร์สำคัญสำหรับแอปสโตร์
      การป้องกันการจับภาพหน้าจอของคอนเทนต์ DRM เป็นฟีเจอร์ที่นักพัฒนาแอปร้องขอเพราะข้อกำหนดทางกฎหมายของไลเซนส์คอนเทนต์อย่างภาพยนตร์ สตูดิโอภาพยนตร์ไม่ต้องการให้ผู้คนสตรีมหรือบันทึกภาพยนตร์ ดังนั้นแพลตฟอร์มแอปจึงต้องมีวิธีแสดงคอนเทนต์ดังกล่าวอย่างปลอดภัย

  • “ถ้ามีคนถามคำถามที่เขาไม่มีสิทธิ์ถาม คุณก็ไม่มีหน้าที่ต้องบอกความจริง”
    — Leonard Schiffman
    ที่มา: “Blend me in: Privacy-Preserving Input Generalization for Personalized Online Services” https://drive.google.com/file/d/10OmoqMmHFcb7PsQtaU_GW4aCAJe...

  • แนวคิดที่ว่าในคำขอสิทธิ์ของแอป ระบบปฏิบัติการควรมีตัวเลือกนอกจากใช่/ไม่ใช่ เป็น “ใช่ แต่ให้ป้อน ข้อมูลปลอม แก่แอป” นั้นมีปัญหา
    ผู้ใช้จำนวนไม่น้อยยังไม่รู้ด้วยซ้ำว่าจะส่งต่ออีเมลอย่างไร
    ลองจินตนาการดูว่าถ้าคนเหล่านั้นใช้ระบบนำทางของ Google Maps แล้วเลือกข้อมูลปลอมโดยไม่เข้าใจความหมาย จะเกิดความสับสนแบบไหน
    Google Maps: “เลี้ยวขวา”
    คนขับที่กำลังขับบนถนนเลียบทะเล: “โอเค”
    รถ: ตู้ม

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

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

    • นั่นไม่ถูกต้อง ตัวอย่างเช่น การเข้าถึงบริการตำแหน่งมี CLAuthorizationStatus: https://developer.apple.com/documentation/corelocation/claut...
      การแจ้งเตือนแบบพุชมี UNAuthorizationStatus: https://developer.apple.com/documentation/usernotifications/...
      ข้อมูลสุขภาพมี HKAuthorizationStatus: https://developer.apple.com/documentation/healthkit/hkauthor...
      รายชื่อติดต่อมี CNAuthorizationStatus: https://developer.apple.com/documentation/contacts/cnauthori...
      รูปภาพมี PHAuthorizationStatus: https://developer.apple.com/documentation/photokit/phauthori...
      รูปภาพเป็นกรณีพิเศษ เพราะผู้ใช้เลือกได้ระหว่างปฏิเสธการเข้าถึง, เข้าถึงแบบจำกัด, และเข้าถึงทั้งหมด รู้ได้ว่าถูกปฏิเสธหรือไม่ แต่แยกไม่ได้ระหว่างการเข้าถึงแบบจำกัดกับเข้าถึงทั้งหมด
    • อยากรู้ว่าตำแหน่งทำงานอย่างไร
      และถ้าโฟลเดอร์รูปภาพว่างเปล่า ก็คงแทบจะแน่นอนว่าหมายถึงไม่มีสิทธิ์ คนที่ไม่เคยถ่ายรูปเลยนั้นหายากมาก
    • แล้วสิทธิ์อื่น ๆ ที่ในทางปฏิบัติส่งออบเจ็กต์ว่างไม่ได้ล่ะเป็นอย่างไร
      เช่น ถ้าผู้ใช้อนุญาตสิทธิ์ดูตำแหน่ง ออบเจ็กต์ตำแหน่งที่ส่งให้แอปก็ย่อมมีข้อมูลที่เกี่ยวข้องอยู่แล้ว ถ้าระบบปฏิบัติการส่งออบเจ็กต์ตำแหน่งว่างไป ก็จะเห็นชัดว่าเป็นการปฏิเสธสิทธิ์ไม่ใช่หรือ หรือใช้วิธีซ่อนไว้หลังข้อผิดพลาดบางอย่าง
    • นี่ไม่จริงอย่างชัดเจน และเห็นได้จากแทบทุกแอปที่ขอเข้าถึงการแจ้งเตือน

  • ผมมองว่า “ให้ข้อมูลปลอม” เป็นวิธีที่ผิด วิธีที่ดีกว่าควรเป็น การให้ข้อมูลจากแหล่งทดแทน และแหล่งทดแทนนั้นควรเป็นโปรแกรมอื่นใดก็ได้
    แหล่งทดแทนอาจเป็นอะไรก็ได้ที่ผู้ใช้ต้องการ เช่น ข้อมูลว่าง, ข้อมูลสุ่ม, ข้อมูลปลอมแต่สอดคล้องกัน, ข้อมูลจากไฟล์ทดแทน (เช่น รายชื่อผู้ติดต่อแยกต่างหาก หรือรูปภาพจากไฟล์แทนกล้อง), ข้อมูลที่ถูกแปลง (เช่น กลับหัวรูปจากกล้อง), การกรอง, การบันทึก, การถามผู้ใช้เป็นรายข้อมูล, การให้รหัสข้อผิดพลาดแทนข้อมูลและให้ผู้ใช้กำหนดรหัสข้อผิดพลาดได้ ฯลฯ ควรรวมไปถึงการเข้าถึงวันที่/เวลาปัจจุบันทั้งหมดด้วย
    สิ่งนี้จะเพิ่มการควบคุมของผู้ใช้ และยังมีประโยชน์สำหรับการทดสอบและการเข้าถึงสำหรับผู้พิการด้วย
    หนึ่งในไอเดียของผมเกี่ยวกับการออกแบบระบบปฏิบัติการคือ สิทธิ์แบบพร็อกซี รวมสิทธิ์แบบพร็อกซีเข้าไปในความปลอดภัยที่อิงสิทธิ์ ให้ I/O ทั้งหมดใช้สิ่งนี้ ใช้ได้ใน command shell ในแบบที่ดีกว่า UNIX pipe และใช้ในวิธีอื่น ๆ ได้ด้วย รวมถึงวันที่/เวลาด้วย นอกจาก Yield และ Quit แล้ว จะเรียก system call ใด ๆ ไม่ได้เลยหากไม่มีคีย์สิทธิ์

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

  • ไม่จำเป็นต้องทำตัวร้ายใส่กันเลย กฎง่าย ๆ คือ “ไม่ ก็เป็นตัวเลือกหนึ่ง เว้นแต่กรณีที่มันไม่ใช่ตัวเลือกจริง ๆ”
    ถ้ามันไม่ใช่ตัวเลือก ก็ต้องอธิบายให้ชัดเจนมากว่าทำไม และน่าจะต้องระบุในกระบวนการตรวจสอบแอปด้วย ไม่เช่นนั้นแอปก็ควรถูกปฏิเสธ
    ตัวอย่างเช่น ถ้า TikTok/Instagram ขอสิทธิ์กล้องและไมโครโฟน ทั้งสองอย่างไม่ใช่สิ่งจำเป็นต่อการใช้งานแอป ดังนั้น “ไม่” จึงเป็นตัวเลือก ถ้าบางส่วนของแอปสามารถใช้งานได้โดยไม่มีสิทธิ์บางอย่าง ความรับผิดชอบในการออกแบบให้ทำงานแบบนั้นอยู่ที่ฝั่งแอป ถ้ากล้องหรือไมโครโฟนถูกปิด ก็แค่ปิดใช้งานแบบมีเงื่อนไขเฉพาะฟีเจอร์ที่ต้องใช้สิทธิ์นั้น
    พูดให้ง่ายกว่านั้น ภาระอยู่ที่ผู้ขอ ถ้าไม่ชัดเจนหรือพยายามเลี่ยงแบบฉลาด ๆ คำตอบก็คือไม่ ฟังดูอาจเข้มงวด แต่ผู้สร้างแอปสามารถหลีกเลี่ยงขั้นตอนเพิ่มเติมนี้ได้ทั้งหมดด้วยการทำให้สิทธิ์เป็นตัวเลือก
    ถ้าโฟกัสที่การบังคับใช้เรื่องนี้ ก็ไม่จำเป็นต้องมีการแข่งขันสะสมอาวุธเล็ก ๆ น้อย ๆ และยังเป็นตัวเลือกที่ดีกว่าสำหรับผู้ใช้ด้วย

    • ฟังดูดี แต่จะบังคับใช้อย่างไร
      ผู้ที่บังคับใช้เรื่องนี้ได้ในที่นี้มีเพียง Google/Apple/Microsoft app store เท่านั้น ยากจะมั่นใจว่าพวกเขามีแรงจูงใจเพียงพอที่จะบังคับใช้อย่างสม่ำเสมอและเป็นมิตรกับผู้ใช้ ถ้ามีจริงก็คงทำไปแล้ว

  • โทรศัพท์ Samsung มีสวิตช์ การเข้าถึงกล้อง และการเข้าถึงไมโครโฟน
    เมื่อปิด จะมีข้อความแบบนี้ขึ้นมา:

    Turn off Camera access?  
All apps will be blocked from using the camera. Apps  
will still work, but they will only be able to access an  
empty black screen. For example, you can still make  
and receive video calls, but the other person won't be  
able to see you.
    • ในกรณีการเข้าถึงไมโครโฟน: 
      Turn off Microphone access?  
All apps will be blocked from using the microphone  
Apps will still work, but they won't be able to access  
any sounds from the microphone. For example, you  
can still make and receive calls, but the other person  
won't be able to hear you.

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

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

  • ถ้าแอปต้องการข้อมูลของฉันเพื่อปรับปรุงประสบการณ์ของฉัน และเป็นการปรับปรุง เฉพาะประสบการณ์ของฉันเท่านั้น เมื่อป้อนข้อมูลปลอมให้ ประสบการณ์ของฉันเท่านั้นที่ควรแย่ลง นักพัฒนาหรือเจ้าของแอปไม่ควรเดือดร้อนอะไร
    แต่ถ้าเป้าหมายคือการทำ data mining จากฉันเหมือนในกรณีส่วนใหญ่ ข้อมูลปลอมก็น่าจะช่วยขัดขวางสิ่งนั้นได้ดี
    แน่นอนว่าในกรณีอย่าง WhatsApp มันคงไม่ค่อยมีประโยชน์ เพราะผู้คนยินดีซิงก์รายชื่อผู้ติดต่อทั้งหมดกับ Facebook/Meta เพื่อให้ได้ประสบการณ์ส่งข้อความที่ดีขึ้นอีกเล็กน้อย

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