1 คะแนน โดย GN⁺ 2023-07-26 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ในอีชู standards-positions ของ Mozilla มีการขอให้แสดงจุดยืนต่อ Web Environment Integrity API และ Mozilla ได้สรุปเป็น position: negative โดยระบุว่าข้อเสนอนี้ขัดกับหลักการความเปิดกว้างของเว็บ
  • ข้อเสนอนี้ แม้ต้นแบบของ Chromium จะพึ่งพา Google Play Integrity อยู่ในขณะนี้ แต่ในสเปกระบุว่าเป็นกลางต่อผู้ให้บริการ อย่างไรก็ตาม ผู้ร้องขอกังวลว่าในทางปฏิบัติอาจแข็งตัวกลายเป็นระบบที่มีผู้ให้บริการไม่กี่รายครอบงำ คล้ายกับ EME
  • Mozilla เห็นว่า API นี้อาจกลายเป็นกลไกที่จำกัดการเลือกอุปกรณ์ ระบบปฏิบัติการ และเบราว์เซอร์ จึงเป็นอันตรายต่อ ความเปิดกว้างของระบบนิเวศเว็บ และไม่เป็นผลดีกับผู้ใช้
  • ในบรรดากรณีใช้งานที่เสนอมา “การตรวจจับทราฟฟิกที่ไม่ใช่มนุษย์” อาจขัดขวางการใช้งานเว็บในรูปแบบเดิม เช่น เทคโนโลยีช่วยการเข้าถึง, การทดสอบอัตโนมัติ, การเก็บถาวร, และสไปเดอร์ของเสิร์ชเอนจิน ที่ทำหน้าที่แปลง ตรวจสอบ จัดทำดัชนี และสรุปเนื้อหาสำหรับมนุษย์
  • Mozilla ระบุว่าการตรวจจับการฉ้อโกงและทราฟฟิกที่ไม่ถูกต้องเป็นปัญหาที่ยากและมีความสนใจจะแก้ไข แต่เห็นว่าข้อเสนอนี้ยังอธิบายไม่เพียงพอว่าจะสร้างความคืบหน้าจริงให้กับกรณีใช้งานเหล่านั้นอย่างไร และมีข้อเสียที่ชัดเจนหากนำไปใช้

คำขอในอีชูและขอบเขตของข้อเสนอ

  • GitHub issue นี้ขอให้ Mozilla แสดงจุดยืนอย่างเป็นทางการต่อสเปกเว็บที่กำลังเกิดขึ้นชื่อ Web Environment Integrity API
  • เอกสารที่แนบมากับคำขอ:
  • ต้นแบบของ Chromium ในปัจจุบันพึ่งพา Google Play Integrity แต่ผู้ร้องขอระบุว่าสเปกนั้นเองเป็น กลางต่อผู้ให้บริการ

ความกังวลเบื้องต้นที่ถูกหยิบยกขึ้น

  • ผู้ร้องขอยกกรณีของ EME เป็นตัวอย่างว่า แม้ในทางทฤษฎีจะเป็นกลางต่อผู้ให้บริการ แต่ในทางปฏิบัติมีผู้ให้บริการที่ได้รับการยอมรับอย่างกว้างขวางอยู่เพียงไม่กี่ราย
    • Google Widevine: ใช้บน Firefox, Chrome และ Android ในเกือบทุกแพลตฟอร์ม
    • Microsoft PlayReady: ใช้บน Microsoft Edge, Windows และอุปกรณ์ Android บางส่วนร่วมกับ Widevine
    • Apple FairPlay: ใช้บน Safari และในระบบนิเวศของ Apple
  • มีความกังวลว่าสถานการณ์เดียวกันอาจเกิดขึ้นกับ Web Environment Integrity API และในทางปฏิบัติเว็บไซต์อาจเริ่มกำหนดให้ต้องใช้ เบราว์เซอร์ที่ได้รับการอนุมัติล่วงหน้า
  • ความเห็นหนึ่งวิจารณ์ว่า API นี้ไม่ได้มอบอะไรให้ผู้ใช้ปลายทาง และอาจถูกใช้เพียงเพื่อจำกัดผู้ใช้เท่านั้น อีกทั้งสเปกยังคลุมเครือและกลไกเบื้องหลังไม่ชัดเจน

เหตุผลที่ Mozilla คัดค้าน

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

ปัญหาของกรณีใช้งาน “การตรวจจับทราฟฟิกที่ไม่ใช่มนุษย์”

  • Mozilla เห็นว่ากรณีใช้งานที่เสนอพึ่งพาความสามารถในการ “detect non-human traffic”
  • วิธีการดังกล่าวอาจรบกวนการใช้งานเว็บในรูปแบบที่มีอยู่เดิม
    • เทคโนโลยีช่วยการเข้าถึง

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

บทสรุปและการจัดการอีชู

  • Mozilla ระบุว่าการตรวจจับการฉ้อโกงและทราฟฟิกที่ไม่ถูกต้องเป็นปัญหาที่ยาก และมีความสนใจในการแก้ปัญหานี้
  • อย่างไรก็ตาม ข้อเสนอ Web Environment Integrity API ยังอธิบายไม่ได้ว่าจะสร้าง ความคืบหน้าเชิงรูปธรรม ให้กับกรณีใช้งานที่ระบุไว้อย่างไร และมีข้อเสียที่ชัดเจนหากถูกนำไปใช้
  • จากการวิเคราะห์นี้ สมาชิกของ Mozilla ได้ติดป้ายจุดยืนต่อข้อเสนอนี้เป็น negative
  • เนื่องจากข้อเสนอนี้เป็นข้อเสนอในคลัง GitHub ส่วนบุคคล ไม่ใช่งานในสายมาตรฐานหรือของกลุ่มบ่มเพาะแบบสาธารณะ จึงเห็นว่าไม่จำเป็นต้องมี dashboard entry แยกต่างหาก
  • อีชูนี้ถูกปิดในสถานะเสร็จสิ้น หลังติดป้าย position: negative เมื่อวันที่ 25 กรกฎาคม 2023

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

 
GN⁺ 2023-07-26
ความคิดเห็นจาก Hacker News
  • รูปแบบการโจมตีคร่าว ๆ เป็นแบบนี้: ผู้โจมตีสร้างอุปกรณ์อย่างสมาร์ตโฟน สร้างคู่กุญแจ แล้วเก็บไว้ใน HSM ภายในอุปกรณ์ ซึ่งโดยทั่วไปเรียกว่า trusted enclave จากนั้นเซ็นกุญแจสาธารณะด้วย master key
    อุปกรณ์ถูกออกแบบให้รันซอฟต์แวร์ของผู้โจมตี และเมื่อซอฟต์แวร์ที่ผู้ใช้เลือกถูกรันด้วยสิทธิ์สูง HSM จะรับรู้ข้อเท็จจริงนั้นในแบบที่ย้อนกลับไม่ได้จนกว่าจะรีบูต HSM จะเซ็นข้อความว่า “อุปกรณ์นี้กำลังรันซอฟต์แวร์ของผู้โจมตี” พร้อมเนื้อหาที่ซอฟต์แวร์ของผู้โจมตีต้องการส่งต่อ แต่จะไม่เซ็นหากซอฟต์แวร์ที่ผู้ใช้เลือกกำลังรันอยู่ นอกจากนี้ยังรวมกุญแจสาธารณะที่ถูกเซ็นด้วย master key เข้าไปด้วย เพื่อให้ผู้สมรู้ร่วมคิดตรวจสอบได้ว่าอุปกรณ์ไม่ได้อยู่ภายใต้การควบคุมของผู้ใช้ แต่อยู่ภายใต้การควบคุมของ ฝ่ายที่จำกัดเสรีภาพของผู้ใช้
    หากเลือกได้ หลักฐานยืนยันนี้อาจถูกส่งผ่านเซิร์ฟเวอร์ของผู้โจมตี แล้วถูกเปลี่ยนเป็นหลักฐานยืนยันใหม่ที่ผ่านการทำให้ไม่ระบุตัวตนหรือการตรวจสอบเงื่อนไขตามอำเภอใจ ท้ายที่สุด บุคคลที่สามจึงได้รับการรับประกันด้วยวิธีนี้ว่าอุปกรณ์กำลังรันซอฟต์แวร์ของผู้โจมตี และสามารถทำให้ผู้ใช้รันซอฟต์แวร์ที่ต้องการไม่ได้ หรือบังคับให้ใช้อุปกรณ์ตามวิธีที่ผู้โจมตีและผู้สมรู้ร่วมคิดต้องการ การโจมตีนี้เกิดขึ้นแล้วบน Android ผ่าน SafetyNet และ Play Integrity API ของ Google และบน iOS โดย Apple และตอนนี้ก็กำลังจะขยายมาสู่เว็บ

    • ผมชอบการเรียกสิ่งนี้ว่าเป็น การโจมตี ยังไม่เคยจัด Google กับพวกไว้ในหัวว่าเป็น “คนกลาง” แต่โดยเนื้อแท้แล้วสิ่งที่เกิดขึ้นก็ตรงนั้นจริง ๆ
      Web Integrity API นี้คือวิธีทำให้พวกเขากลายเป็น คนกลางที่จำเป็นต้องมี ไม่ใช่คนกลางที่เลือกได้
    • ถ้านำกรอบแบบนี้ไปใช้เสนอปัญหาในสื่อ บล็อก ฯลฯ น่าจะมีประโยชน์ ฝั่งตรงข้ามกำลังบิดความหมายของคำอยู่แล้ว และการนำเสนอ DRM ว่าเป็น “แกนหลักของอินเทอร์เน็ตแบบเปิด” นั้นน่าขยะแขยงจริง ๆ
    • ในสถานการณ์นี้ ผู้โจมตีเป็นคนสร้างฮาร์ดแวร์ของผมเอง ซึ่งมันไม่สมเหตุสมผลเลย ถ้าเป็นแบบนั้น เขาก็ทำอะไรก็ได้อยู่แล้ว และในทางปฏิบัติก็ดูไม่ต่างจาก “ผู้โจมตีเป็นเจ้าของฮาร์ดแวร์ ดังนั้นทำได้ทุกอย่างตามตัวอักษร”
      แล้ว “ผู้โจมตี” คนนี้ก็ไม่ได้อะไรเพิ่มด้วย นี่ไม่ใช่ผู้โจมตี แต่คือ ผู้ผลิตอุปกรณ์ การอธิบายกระบวนการ remote attestation โดยเรียก TPM ว่าเป็นผู้โจมตีจึงดูแปลก
    • สุดท้ายก็มีผลข้างเคียงที่แก้ไม่ได้ เพราะความจริงที่ว่าเราส่งไฟฟ้าผ่านสายไฟ: บุคคลเพิ่มเติมที่สามารถดัดแปลงฮาร์ดแวร์ได้มากพอ ยังคงโจมตีผู้โจมตีและผู้สมรู้ร่วมคิดของเขาได้
      ดังนั้นระบบแบบนี้จึงผลักต้นทุนไปให้ผู้ใช้ทั่วไป ขณะเดียวกันให้ประโยชน์เฉพาะฝ่ายที่มีความสามารถเช่นนั้น
    • มีวิธีหลีกเลี่ยงการโจมตีนี้ระหว่างใช้สมาร์ตโฟนไหม? นึกถึง Ubuntu Phone ที่ใกล้ตายขึ้นมาเลย
  • เป็นเรื่องที่คาดไว้แล้ว แต่ถ้าส่งคนไปใช้ Firefox และทำให้ห่างจากตระกูล Chromium ไม่ได้ ก็ไม่มีความหมาย คนที่ลงทุนกับความปลอดภัยและการรักษาความปลอดภัยของเว็บ หรือพูดกว้าง ๆ คือ ความไว้วางใจ ควรมีความรับผิดชอบอยู่บ้าง
    ยังไม่เห็นข้อมูลว่า Brave จะรองรับสิ่งนี้หรือไม่ แต่ถ้าผมเข้าใจถูก ตราบใดที่ใช้ Chromium ก็ดูเหมือนไม่มีทางเลือก และหวังว่าผมจะเข้าใจผิด

    • เมื่อดูคำตำหนิที่ Mozilla ได้รับรอบ ๆ เรื่องนี้ ก็อยากให้ยอมรับความดีความชอบที่สมควรได้รับบ้าง
      สุดท้ายผมคิดว่าเราต้องกลับไปสู่ หน้าจอเลือกเบราว์เซอร์ ที่มีกฎหมายรองรับอย่างถาวร เหมือนหลังเหตุการณ์ผูก IE มากับระบบ ไม่เช่นนั้นแรงเสียดทานและแรงจูงใจจะยังคงทำให้ผู้เล่นรายใหญ่รายเดียวแข็งแกร่งขึ้นเรื่อย ๆ
    • ผลลัพธ์สุดท้ายน่าจะเป็นเว็บไซต์ DRM และเว็บไซต์ธนาคารบอกว่า “ใช้ Chrome เพื่อดำเนินการต่อ” ผู้ใช้ก็จะย้ายไป Chrome ต่อไป และท้ายที่สุด Mozilla ก็จะถูกบังคับให้ implement ตาม
    • คำว่า “ความปลอดภัยและการรักษาความปลอดภัย” กลายเป็นคำที่น่ารังเกียจสำหรับหลายคน เพราะทำให้นึกถึง ดิสโทเปียแบบอำนาจนิยม ที่ Google และคนอื่น ๆ กำลังสร้าง
      สิ่งที่สำคัญกว่าคือเสรีภาพและความสามารถในการทำงานร่วมกัน
    • อีกวิธีหนึ่งคือให้ผู้ดูแลระบบหรือองค์กร IT ที่ดูแล SMB ติดตั้ง Firefox ไว้ล่วงหน้าบนเวิร์กสเตชัน ผู้ใช้จะคุ้นเคยกับเบราว์เซอร์นั้นและอาจใช้เป็นการส่วนตัวด้วย
      แถมติดตั้ง uBlock Origin ไว้ล่วงหน้าได้ด้วย เราก็ทำแบบนั้นอยู่
    • การย้ายแบบนั้นจะเกิดขึ้นก็ต่อเมื่อผู้คนทำสิ่งที่เคยทำในเบราว์เซอร์ประจำไม่ได้อีกต่อไป ผมเคยคิดว่า Manifest V3 จะทำให้ userscript พังและทำให้การบล็อกโฆษณายุ่งยากขึ้น แต่จนถึงตอนนี้ยังไม่เกิดเรื่องแบบนั้น จึงยังไม่มีเหตุผลพอที่จะย้ายออกจาก Chrome
      ถ้าสิ่งนี้ถูก implement ผู้ใช้อาจถูกตัดสินว่า identity “ไม่เพียงพอ” จนเข้าถึงบางเว็บไซต์หรือบริการไม่ได้ และนั่นอาจสร้างแรงจูงใจให้ย้ายไปเบราว์เซอร์อื่นที่ไม่มีฟีเจอร์นี้
  • ผมพูดที่อื่นไปแล้วเหมือนกันว่า ผู้คนควรใช้ Firefox ถ้าทุกคนหยุดใช้ ก็จะไม่มีฝ่ายที่มีเสียงพอจะต่อกรกับเรื่องไร้สาระของ Google ได้ Google เป็นเจ้าของ Chrome และทำอะไรก็ได้ตามต้องการ
    ไม่ได้บอกว่า Firefox สมบูรณ์แบบหรือดีกว่า แต่บอกว่าจำเป็น เราต้องมีเบราว์เซอร์คู่แข่งที่มีส่วนแบ่งตลาดอย่างมีนัยสำคัญ และมี rendering engine ที่ท้ายที่สุดไม่ได้อยู่ภายใต้การควบคุมของ Google ไม่อย่างนั้นก็ต้องเลิกบ่น แล้วปล่อยให้ Google ทำตามที่ต้องการ

    • รายได้ส่วนใหญ่ของ Mozilla ไม่ได้มาจากการจ่ายเงินให้วาง Google เป็นเสิร์ชเอนจินเริ่มต้นหรือ? ไม่รู้ว่าช่วงไม่กี่ปีที่ผ่านมาเปลี่ยนไปหรือยัง
      ลองค้นคร่าว ๆ แล้วพบว่าเมื่อ 5–10 ปีก่อน รายได้มากกว่า 50% มาจาก Google แต่หาข้อมูลล่าสุดกว่านี้ไม่เจอ ถ้า Google เป็นแหล่งรายได้หลักของ Mozilla โดยเฉพาะถ้าเกินครึ่ง Google ก็แทบจะควบคุม Mozilla ได้ด้วยอำนาจต่อรองจากการตัดแหล่งรายได้ใหญ่ที่สุดของ Mozilla
      อีกทั้งยังเกิดคำถามว่าบริษัทหรือองค์กรแบบไหนควรพัฒนาเบราว์เซอร์ ทุกคนคาดหวังว่าเบราว์เซอร์จะฟรี แต่การพัฒนา การดำเนินงาน และการบำรุงรักษาไม่ฟรี บริษัทเบราว์เซอร์เชิงพาณิชย์อย่าง Brave ก็เลี่ยงไม่ได้ที่จะต้องหารายได้จากเบราว์เซอร์ เช่น โทเคนคริปโต BAT หรือโฆษณาในแท็บใหม่
    • ถ้า Firefox ใช้ได้จริงสำหรับผม ผมก็คงใช้ แต่มันไม่เป็นแบบนั้น เลยใช้ไม่ได้
  • Mozilla เองช่วยแสดงจุดยืนต่อ ข้อเสนอ IPA ของตนที่ติดตามผู้ใช้ทั่วทั้งอินเทอร์เน็ตได้ไหม?
    ถ้าผู้ใช้เห็นโฆษณาสินค้าที่ searchengine.example ต่อมาค้นหาสินค้านั้นที่ reviews.example แล้วซื้อที่ shop.example เบราว์เซอร์ของ Mozilla จะส่งอีเวนต์ทั้งหมดนี้ไปยังบริการรวมข้อมูลหนึ่งรายการหรือมากกว่า ทำให้ shop.example เข้าใจได้อย่างน้อยในระดับข้อมูลรวมว่าผู้ใช้เคยเห็นโฆษณาที่ searchengine.example และถูกเปิดรับอีกครั้งที่ reviews.example แน่นอนว่าต้องตั้งอยู่บนสมมติฐานว่าเชื่อใจกลุ่มคาร์เทลที่ให้บริการรวมข้อมูล
    เมื่อก่อนบริษัทเทคโนโลยีโฆษณายังติดตามผู้ใช้จาก IP ต้นทางได้แม้ปิดคุกกี้ แต่ IPA ทำให้ติดตามข้ามหลาย IP ได้ผ่านตัวระบุติดตามที่ไม่ซ้ำกัน และติดตามได้โดยไม่ขึ้นกับการตั้งค่าคุกกี้ ยังมีการเสนอให้ระบบปฏิบัติการมอบตัวระบุติดตามที่ไม่ซ้ำกันซึ่งใช้ได้กับทุกแอปและเบราว์เซอร์ในอุปกรณ์ ทำให้แยกแยะอุปกรณ์หลายเครื่องที่อยู่หลัง IP เดียวกันได้ด้วย
    https://github.com/patcg-individual-drafts/ipa/

    • เพื่อให้โฆษณาทำงานได้ attribution เป็นสิ่งจำเป็น หากไม่มี attribution ที่เป็นอิสระจากแพลตฟอร์มที่ซื้อโฆษณา แพลตฟอร์มโฆษณานั้นก็อาจโกงได้
      เรื่องนี้แยกจากการติดตามโฆษณาที่สร้างโปรไฟล์ความสนใจของผู้ใช้ หรือรีมาร์เก็ตติ้งที่ซื้อโฆษณาเพื่อยิงใส่ผู้ที่เคยเข้าชมในอดีต ระบบ attribution แบบเป็นส่วนตัวส่วนใหญ่ถูกออกแบบให้ผู้ดำเนินการโฆษณานับได้ว่ามีกี่คนคลิกโฆษณา แต่ไม่รู้ว่าใครคลิกหรือทำอะไรอย่างอื่น ข้อเสนอของ Safari มีการจำกัดจำนวนแคมเปญที่รันได้ต่อโดเมน เพื่อป้องกันการสร้าง “แคมเปญ” แยกตามผู้ใช้แต่ละคนแล้วใช้ทำ fingerprinting ในครั้งเดียว ไม่รู้ว่าข้อเสนอของ Mozilla ต่างกันอย่างไร
      ส่วน user agent ควรต้องใส่ใจเรื่องแบบนี้หรือไม่ เป็นอีกคำถามหนึ่ง
      https://www.theregister.com/2023/06/29/google_trueview_skepticism/
      โดยเฉพาะรีมาร์เก็ตติ้งคือสาเหตุที่ทำให้โฆษณายุคใหม่สร้าง “ความรู้สึกเหมือนถูกเฝ้าดู” คือพอค้นหาอะไรสักอย่าง ก็มีโฆษณาของสิ่งนั้นเป็นหมื่นชิ้นตามหลอกหลอนไปตลอดสัปดาห์ถัดไป
    • ดูจากต้นฉบับแล้ว ดูเหมือนว่าสามารถถามจุดยืนของ Mozilla ได้โดยเปิด GitHub issue ที่ https://github.com/mozilla/standards-positions
    • พูดอย่างเป็นธรรม “Web Integrity” หรือก็คือการยืนยันระยะไกล หรือ เอเจนต์เฝ้าระวังของบริษัท ที่ฝังอยู่ในฮาร์ดแวร์ “ของฉัน” เป็นปัญหาพื้นฐานกว่ามาก เพราะมันสามารถขัดขวางไม่ให้รันเบราว์เซอร์ฟอร์กที่ตัดช่องโหว่ด้านความปลอดภัยโดยเจตนาอย่าง IPA ออกไปได้ตั้งแต่แรก
      น่าเสียดายที่ Mozilla ยอมเล่นตามขยะอย่าง IPA แต่อย่างน้อยในตอนนี้ ผู้ใช้ยังมีเสรีภาพที่จะปิดใช้งาน ลบออก หรือฟอร์กได้ ในทางกลับกัน การยืนยันระยะไกลแทบจะเป็นเกมโอเวอร์ต่อแนวคิดของ user agent เอง
    • ไม่ว่าข้อเสนอของ Mozilla จะแย่แค่ไหน นี่ก็เป็นการเบี่ยงประเด็น สุดท้ายมันรับใช้ผลประโยชน์ของ Google และช่วยปกป้องข้อเสนอที่ดิสโทเปียกว่านั้นมาก
    • ที่ว่า “เบราว์เซอร์ของ Mozilla จะส่งอีเวนต์ทั้งหมดนี้ไปยังบริการรวมข้อมูลหนึ่งรายการหรือมากกว่า” หมายถึงกรณีที่ผู้ใช้อณุญาต
  • การตรวจจับเบราว์เซอร์, การตรวจจับ “สภาพแวดล้อม”
    ผู้ดูแลเว็บไซต์บางแห่งอาจออกแบบ เว็บไซต์ที่ Chrome เข้าใช้งานไม่ได้ เพื่อเป็นวิธีประท้วง ก็น่าจะสนุกดีถ้าได้เห็น Google พยายามหาทางเลี่ยง โดยเฉพาะถ้ามันฮิตเฉพาะในหมู่เว็บไซต์ขนาดเล็กและไม่ใช่เชิงพาณิชย์

    • เป็นความคิดที่ดี อาจช่วยได้ด้วยการฝึกให้ผู้ใช้ใช้หลายเบราว์เซอร์บ่อยขึ้น ลูก ๆ ของฉันก็ใช้หลายเบราว์เซอร์บนอุปกรณ์ Android อยู่แล้วเพื่อบล็อกโฆษณา YouTube ถ้ามีเหตุผลมากพอ คนก็ยินดีใช้เบราว์เซอร์อื่น
      แต่แทนที่จะบล็อกทั้งหมด ผมจะเหลือไว้เฉพาะฟังก์ชันที่จำเป็นจริง ๆ แล้วแจ้งเตือนต่อเนื่องให้เปลี่ยนไปใช้เบราว์เซอร์อื่นหรือใช้ของอย่าง Tampermonkey ควรมีคำแนะนำที่ชัดเจนด้วยว่าต้องทำอะไร
      วิธีที่ดีในการตรวจจับว่ารองรับฟีเจอร์นี้หรือไม่คืออะไร? JavaScript API?
    • ตลอด 6 ปีอันยาวนาน Chrome เข้าเว็บไซต์ของผมไม่ได้ เบราว์เซอร์อื่นทั้งหมดเข้าได้ แต่ Chrome ไม่สามารถเคารพการตั้งค่าฝั่งเซิร์ฟเวอร์ที่บังคับเจรจาเฉพาะแบบที่ไม่ใช่ HTTP/3 และอนุญาตเฉพาะ ChaCha/Poly โดยตัด AES/RSA ออกได้ Microsoft Edge แก้ไขหลังจากนั้นไม่นาน
      โชคดีที่ Google ก็แก้ไขเมื่อประมาณ 4 เดือนก่อนเช่นกัน เครื่องมือทดสอบข้ามเบราว์เซอร์ฟรีหลายตัวตอนนี้ยังสามารถแสดงอาการพังนั้นได้ด้วยการทดสอบเวอร์ชัน
    • อาจใช้เป็นข้อมูลอ้างอิงได้: https://news.ycombinator.com/item?id=25240299
  • ฝั่งมือถือที่เป็นคู่กันอย่าง Play Integrity API ควรถูกทำให้ผิดกฎหมายและสู้กันในศาล เพราะแนวคิดหลักคือการกำจัด ROM จากบุคคลที่สาม ผมจึงคิดว่ามีแนวโน้มขัดกับสิทธิในการซ่อมของ EU และกฎหมายขยะอิเล็กทรอนิกส์ด้วย
    เราควรเริ่มเปลี่ยนจุดโฟกัสของการถกเถียงไปที่ปัญหาความปลอดภัยที่ Google และโฆษณาของตนสร้างขึ้น

    • Google กำลังใช้ trusted computing ในทางที่ผิด พอเข้าใจได้ว่าธนาคารบางแห่งอยากให้โค้ดประมวลผลการชำระเงินรันบนอุปกรณ์ที่ถูกล็อกไว้ แต่ในปัจจุบัน อุปกรณ์ Android แบบนั้นมีแอดแวร์และสปายแวร์ของ Google ที่ไม่จำเป็นเลยสำหรับอุปกรณ์ที่เชื่อถือได้เพื่อการชำระเงิน
      ควรแยก Google ออกเป็นส่วน ๆ เพื่อไม่ให้ผลประโยชน์ของ Google ทำให้ Android และ Chrome แปดเปื้อน
  • อยากบริจาคให้ Mozilla แต่กังวลว่าเงินของฉันจะไหลเข้ากระเป๋าผู้บริหารระดับ C-level มีวิธีบริจาคแบบเจาะจงให้ ทีมหลักของ Firefox หรือ MDN ไหม?

    • การเจาะจงแบบนั้นไม่สมเหตุสมผลในมุมของ Mozilla ต่อให้มีเงินบริจาคสำหรับ Firefox แต่ถ้าจ่ายเงินให้พนักงานทำความสะอาดสำนักงาน ค่าเช่า ฝ่ายบุคคล บัญชี และกฎหมายไม่ได้ ก็จ้างและดำเนินงาน “ทีมหลักของ Firefox กับ MDN” ไม่ได้
      แม้แต่ CEO ที่รับค่าตอบแทนสูงเกินเหตุอย่างไร้สาระก็ยังจำเป็นต่อบริษัท ผมไม่เชื่อเหตุผลที่ว่าในสหรัฐฯ ถ้าจะดึง CEO ดี ๆ มาต้องจ่ายแพง ๆ แต่ CEO แย่ ๆ ก็ทำบริษัทพังได้เหมือน GE, Enron, Boeing, Twitter
      ตัวอย่างสนุก ๆ ของความล้มเหลวจากการจำกัดวัตถุประสงค์ของงบประมาณคือ MARTA ของ Atlanta เมื่อก่อนกฎหมายเงินทุนบังคับให้ตรึงค่าใช้จ่ายดำเนินงานกับรายจ่ายฝ่ายทุนไว้ที่ 50/50 ผลคือมีรถไฟขบวนใหม่ แต่ส่วนที่เหลือพังทลายลง
    • คุณวิเคราะห์แบบเดียวกันกับการซื้อทุกอย่างไหม? ร้านแซนด์วิชที่คุณซื้อเป็นมื้อกลางวันอาจเอาเงินนั้นไปซื้อพิซซ่าให้เจ้าของกับภรรยาที่ไม่ได้ทำงานในวันนั้นเลยก็ได้ แบบนั้นทำให้โกรธไหม?
      ธุรกิจคือโครงสร้างที่มีเงินเข้า เงินออก และมีผลิตภัณฑ์ถูกสร้างขึ้น คุณเลือกได้ว่าจะจ่ายเงินให้ผลิตภัณฑ์ที่ชอบหรือไม่ ส่วนพวกเขาจะใช้เงินที่ได้รับอย่างไรก็เป็นเรื่องของพวกเขา
    • คุณสามารถบริจาคแบบ มีข้อจำกัด ให้ Mozilla Foundation ได้ และถ้าพวกเขารับ ก็จะถูกผูกมัดตามข้อจำกัดนั้น เว้นแต่ผู้บริจาคจะยินยอมเป็นอย่างอื่น
      แต่เงินเป็นสิ่งที่ทดแทนกันได้ ถ้าบริจาค 500 ดอลลาร์เพื่อสนับสนุน MDN เงิน 500 ดอลลาร์ที่เดิมจากรายได้ปกติจะไป MDN ก็อาจถูกแทนที่ ทำให้อีก 500 ดอลลาร์ไปเข้ากระเป๋า C-level หรือไปที่ Pocket เป็นต้น ตัวเงินดอลลาร์เองจะไปยังที่ที่คุณระบุไว้ แต่ก็อาจทำให้รายจ่ายอื่นที่คุณไม่ชอบเกิดขึ้นได้
      กลับกัน ถ้าบริจาค 50,000 ล้านดอลลาร์เพื่อสนับสนุน MDN ก็เป็นอีกเรื่อง งบสนับสนุน MDN เดิมย่อมถูกปลดล็อกแน่ แต่รายจ่ายของ MDN คงไม่มีทางถึง 50,000 ล้านดอลลาร์ ดังนั้นเงินที่เกินความต้องการของ MDN ก็ไม่มีที่ไป
    • Mozilla ไม่ใช่สหกรณ์ แต่เป็นแค่ นิติบุคคลไม่แสวงหากำไร นักพัฒนาก็เป็นพนักงานของนิติบุคคลนั้นเหมือนบริษัทอื่น ๆ พูดตรง ๆ ผมมองว่าบริษัทมีรายได้ค่อนข้างดีและไม่ได้พึ่งพาการบริจาคมากนัก
      การใช้ผลิตภัณฑ์และเป็นลูกค้าอาจมีคุณค่าต่อพวกเขาและแถลงการณ์ของพวกเขามากกว่า
    • วิธีที่ใกล้เคียงที่สุดตอนนี้คือจ่ายเงินให้ผลิตภัณฑ์สักตัว มี Pocket Premium, Firefox Relay, Mozilla VPN
  • Mozilla อาจคัดค้านได้ แต่ถ้ามันถูกใส่ใน Chrome และเริ่มถูกใช้งานอย่างแพร่หลาย สุดท้ายก็คงต้อง implement เหมือน CDM
    สุดท้ายผู้ใช้จะเห็นแค่ว่าเว็บไซต์บางเว็บใช้ได้บน Chrome แต่ใช้ไม่ได้บน Firefox เมื่อมีต้นทุนจริงเป็นการสูญเสียส่วนแบ่งตลาดที่อาจเกิดขึ้น Firefox ก็จะตัดสินว่าไม่มีเหตุผลจะคัดค้านอีก

    • ลองนึกดูว่าแนวทาง “ไม่ใช่ Chrome แต่แทบจะเป็น Chrome” ส่งผลต่อส่วนแบ่งตลาดอย่างไร ผู้ใช้แบบนั้นไม่มีปัญหาที่จะใช้ Chrome ไปเลย ดังนั้นตลาดนั้นจริง ๆ อาจไม่ได้ใหญ่ขนาดนั้น
  • จุดยืนมาตรฐานของ WebKit ก็น่าดู: https://webkit.org/standards-positions/
    เรื่องนี้ยังไม่ได้สะท้อนอยู่ในนั้น และน่าจะมีแนวโน้มคัดค้าน

  • มีประวัติศาสตร์ยาวนานที่แฮกเกอร์ในความหมายดั้งเดิมใช้คอมพิวเตอร์ทำสิ่งที่คนอื่นไม่ต้องการให้ทำ และคนอื่นเหล่านั้นก็ทำอะไรไม่ได้ หรืออย่างมากก็ทำได้แค่แข่งสะสมอาวุธกัน มันแย่สำหรับพวกเขา แต่ดีมากต่อสังคมโดยรวม
    สิ่งนั้นทำให้เกิด GNU, “IBM Compatible”, ตัวบล็อกโฆษณา, Firefox, BitTorrent, YouTube ReVanced/youtube-dl และอีกมากมาย
    เป้าหมายของ การรับรองอุปกรณ์ สำหรับซอฟต์แวร์ผู้บริโภคคือการยุติสิ่งนี้ Apple เป็นผู้บุกเบิกบน iOS ก่อน และตอนนี้กำลังแพร่ไปยังการประมวลผลทั้งหมดด้วยพลังของทุนนิยม การรับรองอุปกรณ์หมายความว่าแฮกเกอร์แพ้ และนั่นเป็นจุดจบที่เลวร้าย
    ภัยคุกคามคู่แฝดอีกอย่างคืออุตสาหกรรมซอฟต์แวร์กำลังจัดการเรื่องความปลอดภัยให้เรียบร้อยจริง ๆ สมัยก่อนการเจลเบรก iOS เป็นเรื่องพบได้ทั่วไป แต่ตลอด 1 ปีที่ผ่านมาไม่มีการเจลเบรก iOS เลย Rust ก็ไม่ได้ช่วยอะไร
    เรากำลังพุ่งเข้าสู่โลกที่ผู้ผลิตและผู้ถือสิทธิ์ทรัพย์สินทางปัญญาควบคุมคอนเทนต์ที่ตนสร้างขึ้นได้อย่างสมบูรณ์ และคงสภาพนั้นไว้ด้วยวิทยาการเข้ารหัสลับล้ำสมัยกับซอฟต์แวร์ที่ปลอดภัยสุดขีดแต่เป็นศัตรูกับผู้บริโภค นี่เป็นหนึ่งในพัฒนาการที่อันตรายที่สุดในประวัติศาสตร์ และหากกลายเป็นความจริงก็จะย้อนกลับไม่ได้ Stallman พูดถูก

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