จุดยืนด้านมาตรฐานของ Mozilla คัดค้าน Web Environment Integrity API
(github.com/mozilla)- ในอีชู 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 ความคิดเห็น
ความคิดเห็นจาก Hacker News
รูปแบบการโจมตีคร่าว ๆ เป็นแบบนี้: ผู้โจมตีสร้างอุปกรณ์อย่างสมาร์ตโฟน สร้างคู่กุญแจ แล้วเก็บไว้ใน HSM ภายในอุปกรณ์ ซึ่งโดยทั่วไปเรียกว่า trusted enclave จากนั้นเซ็นกุญแจสาธารณะด้วย master key
อุปกรณ์ถูกออกแบบให้รันซอฟต์แวร์ของผู้โจมตี และเมื่อซอฟต์แวร์ที่ผู้ใช้เลือกถูกรันด้วยสิทธิ์สูง HSM จะรับรู้ข้อเท็จจริงนั้นในแบบที่ย้อนกลับไม่ได้จนกว่าจะรีบูต HSM จะเซ็นข้อความว่า “อุปกรณ์นี้กำลังรันซอฟต์แวร์ของผู้โจมตี” พร้อมเนื้อหาที่ซอฟต์แวร์ของผู้โจมตีต้องการส่งต่อ แต่จะไม่เซ็นหากซอฟต์แวร์ที่ผู้ใช้เลือกกำลังรันอยู่ นอกจากนี้ยังรวมกุญแจสาธารณะที่ถูกเซ็นด้วย master key เข้าไปด้วย เพื่อให้ผู้สมรู้ร่วมคิดตรวจสอบได้ว่าอุปกรณ์ไม่ได้อยู่ภายใต้การควบคุมของผู้ใช้ แต่อยู่ภายใต้การควบคุมของ ฝ่ายที่จำกัดเสรีภาพของผู้ใช้
หากเลือกได้ หลักฐานยืนยันนี้อาจถูกส่งผ่านเซิร์ฟเวอร์ของผู้โจมตี แล้วถูกเปลี่ยนเป็นหลักฐานยืนยันใหม่ที่ผ่านการทำให้ไม่ระบุตัวตนหรือการตรวจสอบเงื่อนไขตามอำเภอใจ ท้ายที่สุด บุคคลที่สามจึงได้รับการรับประกันด้วยวิธีนี้ว่าอุปกรณ์กำลังรันซอฟต์แวร์ของผู้โจมตี และสามารถทำให้ผู้ใช้รันซอฟต์แวร์ที่ต้องการไม่ได้ หรือบังคับให้ใช้อุปกรณ์ตามวิธีที่ผู้โจมตีและผู้สมรู้ร่วมคิดต้องการ การโจมตีนี้เกิดขึ้นแล้วบน Android ผ่าน SafetyNet และ Play Integrity API ของ Google และบน iOS โดย Apple และตอนนี้ก็กำลังจะขยายมาสู่เว็บ
Web Integrity API นี้คือวิธีทำให้พวกเขากลายเป็น คนกลางที่จำเป็นต้องมี ไม่ใช่คนกลางที่เลือกได้
แล้ว “ผู้โจมตี” คนนี้ก็ไม่ได้อะไรเพิ่มด้วย นี่ไม่ใช่ผู้โจมตี แต่คือ ผู้ผลิตอุปกรณ์ การอธิบายกระบวนการ remote attestation โดยเรียก TPM ว่าเป็นผู้โจมตีจึงดูแปลก
ดังนั้นระบบแบบนี้จึงผลักต้นทุนไปให้ผู้ใช้ทั่วไป ขณะเดียวกันให้ประโยชน์เฉพาะฝ่ายที่มีความสามารถเช่นนั้น
เป็นเรื่องที่คาดไว้แล้ว แต่ถ้าส่งคนไปใช้ Firefox และทำให้ห่างจากตระกูล Chromium ไม่ได้ ก็ไม่มีความหมาย คนที่ลงทุนกับความปลอดภัยและการรักษาความปลอดภัยของเว็บ หรือพูดกว้าง ๆ คือ ความไว้วางใจ ควรมีความรับผิดชอบอยู่บ้าง
ยังไม่เห็นข้อมูลว่า Brave จะรองรับสิ่งนี้หรือไม่ แต่ถ้าผมเข้าใจถูก ตราบใดที่ใช้ Chromium ก็ดูเหมือนไม่มีทางเลือก และหวังว่าผมจะเข้าใจผิด
สุดท้ายผมคิดว่าเราต้องกลับไปสู่ หน้าจอเลือกเบราว์เซอร์ ที่มีกฎหมายรองรับอย่างถาวร เหมือนหลังเหตุการณ์ผูก IE มากับระบบ ไม่เช่นนั้นแรงเสียดทานและแรงจูงใจจะยังคงทำให้ผู้เล่นรายใหญ่รายเดียวแข็งแกร่งขึ้นเรื่อย ๆ
สิ่งที่สำคัญกว่าคือเสรีภาพและความสามารถในการทำงานร่วมกัน
แถมติดตั้ง uBlock Origin ไว้ล่วงหน้าได้ด้วย เราก็ทำแบบนั้นอยู่
ถ้าสิ่งนี้ถูก implement ผู้ใช้อาจถูกตัดสินว่า identity “ไม่เพียงพอ” จนเข้าถึงบางเว็บไซต์หรือบริการไม่ได้ และนั่นอาจสร้างแรงจูงใจให้ย้ายไปเบราว์เซอร์อื่นที่ไม่มีฟีเจอร์นี้
ผมพูดที่อื่นไปแล้วเหมือนกันว่า ผู้คนควรใช้ Firefox ถ้าทุกคนหยุดใช้ ก็จะไม่มีฝ่ายที่มีเสียงพอจะต่อกรกับเรื่องไร้สาระของ Google ได้ Google เป็นเจ้าของ Chrome และทำอะไรก็ได้ตามต้องการ
ไม่ได้บอกว่า Firefox สมบูรณ์แบบหรือดีกว่า แต่บอกว่าจำเป็น เราต้องมีเบราว์เซอร์คู่แข่งที่มีส่วนแบ่งตลาดอย่างมีนัยสำคัญ และมี rendering engine ที่ท้ายที่สุดไม่ได้อยู่ภายใต้การควบคุมของ Google ไม่อย่างนั้นก็ต้องเลิกบ่น แล้วปล่อยให้ Google ทำตามที่ต้องการ
ลองค้นคร่าว ๆ แล้วพบว่าเมื่อ 5–10 ปีก่อน รายได้มากกว่า 50% มาจาก Google แต่หาข้อมูลล่าสุดกว่านี้ไม่เจอ ถ้า Google เป็นแหล่งรายได้หลักของ Mozilla โดยเฉพาะถ้าเกินครึ่ง Google ก็แทบจะควบคุม Mozilla ได้ด้วยอำนาจต่อรองจากการตัดแหล่งรายได้ใหญ่ที่สุดของ Mozilla
อีกทั้งยังเกิดคำถามว่าบริษัทหรือองค์กรแบบไหนควรพัฒนาเบราว์เซอร์ ทุกคนคาดหวังว่าเบราว์เซอร์จะฟรี แต่การพัฒนา การดำเนินงาน และการบำรุงรักษาไม่ฟรี บริษัทเบราว์เซอร์เชิงพาณิชย์อย่าง Brave ก็เลี่ยงไม่ได้ที่จะต้องหารายได้จากเบราว์เซอร์ เช่น โทเคนคริปโต BAT หรือโฆษณาในแท็บใหม่
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 แบบเป็นส่วนตัวส่วนใหญ่ถูกออกแบบให้ผู้ดำเนินการโฆษณานับได้ว่ามีกี่คนคลิกโฆษณา แต่ไม่รู้ว่าใครคลิกหรือทำอะไรอย่างอื่น ข้อเสนอของ Safari มีการจำกัดจำนวนแคมเปญที่รันได้ต่อโดเมน เพื่อป้องกันการสร้าง “แคมเปญ” แยกตามผู้ใช้แต่ละคนแล้วใช้ทำ fingerprinting ในครั้งเดียว ไม่รู้ว่าข้อเสนอของ Mozilla ต่างกันอย่างไร
ส่วน user agent ควรต้องใส่ใจเรื่องแบบนี้หรือไม่ เป็นอีกคำถามหนึ่ง
https://www.theregister.com/2023/06/29/google_trueview_skepticism/
โดยเฉพาะรีมาร์เก็ตติ้งคือสาเหตุที่ทำให้โฆษณายุคใหม่สร้าง “ความรู้สึกเหมือนถูกเฝ้าดู” คือพอค้นหาอะไรสักอย่าง ก็มีโฆษณาของสิ่งนั้นเป็นหมื่นชิ้นตามหลอกหลอนไปตลอดสัปดาห์ถัดไป
น่าเสียดายที่ Mozilla ยอมเล่นตามขยะอย่าง IPA แต่อย่างน้อยในตอนนี้ ผู้ใช้ยังมีเสรีภาพที่จะปิดใช้งาน ลบออก หรือฟอร์กได้ ในทางกลับกัน การยืนยันระยะไกลแทบจะเป็นเกมโอเวอร์ต่อแนวคิดของ user agent เอง
การตรวจจับเบราว์เซอร์, การตรวจจับ “สภาพแวดล้อม”
ผู้ดูแลเว็บไซต์บางแห่งอาจออกแบบ เว็บไซต์ที่ Chrome เข้าใช้งานไม่ได้ เพื่อเป็นวิธีประท้วง ก็น่าจะสนุกดีถ้าได้เห็น Google พยายามหาทางเลี่ยง โดยเฉพาะถ้ามันฮิตเฉพาะในหมู่เว็บไซต์ขนาดเล็กและไม่ใช่เชิงพาณิชย์
แต่แทนที่จะบล็อกทั้งหมด ผมจะเหลือไว้เฉพาะฟังก์ชันที่จำเป็นจริง ๆ แล้วแจ้งเตือนต่อเนื่องให้เปลี่ยนไปใช้เบราว์เซอร์อื่นหรือใช้ของอย่าง Tampermonkey ควรมีคำแนะนำที่ชัดเจนด้วยว่าต้องทำอะไร
วิธีที่ดีในการตรวจจับว่ารองรับฟีเจอร์นี้หรือไม่คืออะไร? JavaScript API?
โชคดีที่ Google ก็แก้ไขเมื่อประมาณ 4 เดือนก่อนเช่นกัน เครื่องมือทดสอบข้ามเบราว์เซอร์ฟรีหลายตัวตอนนี้ยังสามารถแสดงอาการพังนั้นได้ด้วยการทดสอบเวอร์ชัน
ฝั่งมือถือที่เป็นคู่กันอย่าง Play Integrity API ควรถูกทำให้ผิดกฎหมายและสู้กันในศาล เพราะแนวคิดหลักคือการกำจัด ROM จากบุคคลที่สาม ผมจึงคิดว่ามีแนวโน้มขัดกับสิทธิในการซ่อมของ EU และกฎหมายขยะอิเล็กทรอนิกส์ด้วย
เราควรเริ่มเปลี่ยนจุดโฟกัสของการถกเถียงไปที่ปัญหาความปลอดภัยที่ Google และโฆษณาของตนสร้างขึ้น
ควรแยก Google ออกเป็นส่วน ๆ เพื่อไม่ให้ผลประโยชน์ของ Google ทำให้ Android และ Chrome แปดเปื้อน
อยากบริจาคให้ Mozilla แต่กังวลว่าเงินของฉันจะไหลเข้ากระเป๋าผู้บริหารระดับ C-level มีวิธีบริจาคแบบเจาะจงให้ ทีมหลักของ Firefox หรือ MDN ไหม?
แม้แต่ CEO ที่รับค่าตอบแทนสูงเกินเหตุอย่างไร้สาระก็ยังจำเป็นต่อบริษัท ผมไม่เชื่อเหตุผลที่ว่าในสหรัฐฯ ถ้าจะดึง CEO ดี ๆ มาต้องจ่ายแพง ๆ แต่ CEO แย่ ๆ ก็ทำบริษัทพังได้เหมือน GE, Enron, Boeing, Twitter
ตัวอย่างสนุก ๆ ของความล้มเหลวจากการจำกัดวัตถุประสงค์ของงบประมาณคือ MARTA ของ Atlanta เมื่อก่อนกฎหมายเงินทุนบังคับให้ตรึงค่าใช้จ่ายดำเนินงานกับรายจ่ายฝ่ายทุนไว้ที่ 50/50 ผลคือมีรถไฟขบวนใหม่ แต่ส่วนที่เหลือพังทลายลง
ธุรกิจคือโครงสร้างที่มีเงินเข้า เงินออก และมีผลิตภัณฑ์ถูกสร้างขึ้น คุณเลือกได้ว่าจะจ่ายเงินให้ผลิตภัณฑ์ที่ชอบหรือไม่ ส่วนพวกเขาจะใช้เงินที่ได้รับอย่างไรก็เป็นเรื่องของพวกเขา
แต่เงินเป็นสิ่งที่ทดแทนกันได้ ถ้าบริจาค 500 ดอลลาร์เพื่อสนับสนุน MDN เงิน 500 ดอลลาร์ที่เดิมจากรายได้ปกติจะไป MDN ก็อาจถูกแทนที่ ทำให้อีก 500 ดอลลาร์ไปเข้ากระเป๋า C-level หรือไปที่ Pocket เป็นต้น ตัวเงินดอลลาร์เองจะไปยังที่ที่คุณระบุไว้ แต่ก็อาจทำให้รายจ่ายอื่นที่คุณไม่ชอบเกิดขึ้นได้
กลับกัน ถ้าบริจาค 50,000 ล้านดอลลาร์เพื่อสนับสนุน MDN ก็เป็นอีกเรื่อง งบสนับสนุน MDN เดิมย่อมถูกปลดล็อกแน่ แต่รายจ่ายของ MDN คงไม่มีทางถึง 50,000 ล้านดอลลาร์ ดังนั้นเงินที่เกินความต้องการของ MDN ก็ไม่มีที่ไป
การใช้ผลิตภัณฑ์และเป็นลูกค้าอาจมีคุณค่าต่อพวกเขาและแถลงการณ์ของพวกเขามากกว่า
Mozilla อาจคัดค้านได้ แต่ถ้ามันถูกใส่ใน Chrome และเริ่มถูกใช้งานอย่างแพร่หลาย สุดท้ายก็คงต้อง implement เหมือน CDM
สุดท้ายผู้ใช้จะเห็นแค่ว่าเว็บไซต์บางเว็บใช้ได้บน Chrome แต่ใช้ไม่ได้บน Firefox เมื่อมีต้นทุนจริงเป็นการสูญเสียส่วนแบ่งตลาดที่อาจเกิดขึ้น Firefox ก็จะตัดสินว่าไม่มีเหตุผลจะคัดค้านอีก
จุดยืนมาตรฐานของ WebKit ก็น่าดู: https://webkit.org/standards-positions/
เรื่องนี้ยังไม่ได้สะท้อนอยู่ในนั้น และน่าจะมีแนวโน้มคัดค้าน
มีประวัติศาสตร์ยาวนานที่แฮกเกอร์ในความหมายดั้งเดิมใช้คอมพิวเตอร์ทำสิ่งที่คนอื่นไม่ต้องการให้ทำ และคนอื่นเหล่านั้นก็ทำอะไรไม่ได้ หรืออย่างมากก็ทำได้แค่แข่งสะสมอาวุธกัน มันแย่สำหรับพวกเขา แต่ดีมากต่อสังคมโดยรวม
สิ่งนั้นทำให้เกิด GNU, “IBM Compatible”, ตัวบล็อกโฆษณา, Firefox, BitTorrent, YouTube ReVanced/youtube-dl และอีกมากมาย
เป้าหมายของ การรับรองอุปกรณ์ สำหรับซอฟต์แวร์ผู้บริโภคคือการยุติสิ่งนี้ Apple เป็นผู้บุกเบิกบน iOS ก่อน และตอนนี้กำลังแพร่ไปยังการประมวลผลทั้งหมดด้วยพลังของทุนนิยม การรับรองอุปกรณ์หมายความว่าแฮกเกอร์แพ้ และนั่นเป็นจุดจบที่เลวร้าย
ภัยคุกคามคู่แฝดอีกอย่างคืออุตสาหกรรมซอฟต์แวร์กำลังจัดการเรื่องความปลอดภัยให้เรียบร้อยจริง ๆ สมัยก่อนการเจลเบรก iOS เป็นเรื่องพบได้ทั่วไป แต่ตลอด 1 ปีที่ผ่านมาไม่มีการเจลเบรก iOS เลย Rust ก็ไม่ได้ช่วยอะไร
เรากำลังพุ่งเข้าสู่โลกที่ผู้ผลิตและผู้ถือสิทธิ์ทรัพย์สินทางปัญญาควบคุมคอนเทนต์ที่ตนสร้างขึ้นได้อย่างสมบูรณ์ และคงสภาพนั้นไว้ด้วยวิทยาการเข้ารหัสลับล้ำสมัยกับซอฟต์แวร์ที่ปลอดภัยสุดขีดแต่เป็นศัตรูกับผู้บริโภค นี่เป็นหนึ่งในพัฒนาการที่อันตรายที่สุดในประวัติศาสตร์ และหากกลายเป็นความจริงก็จะย้อนกลับไม่ได้ Stallman พูดถูก
คล้ายกับการบอกว่าความสุขของคุณอาจดีขึ้นได้ถ้ายอมส่งกระเป๋าสตางค์ให้เมื่อถูกจ่อปืน