Apple ได้ปล่อยใช้การยืนยันอุปกรณ์บนเว็บ (attestation) ไปแล้ว และเราแทบไม่ทันสังเกต
(httptoolkit.com)- ระหว่างที่ข้อเสนอ Web Environment Integrity ของ Google กำลังเป็นประเด็นถกเถียง Apple ก็ได้ปล่อยระบบยืนยันอุปกรณ์บนเว็บที่คล้ายกันอย่าง Private Access Tokens ไปแล้วบน macOS 13, iOS 16 และ Safari
- Private Access Tokens ทำงานโดยเมื่อเซิร์ฟเวอร์ส่ง HTTP 401 พร้อมชาเลนจ์
PrivateTokenเบราว์เซอร์และระบบปฏิบัติการจะขอให้ attester ตรวจสอบสถานะอุปกรณ์ แล้วส่งคำขอซ้ำกลับไปพร้อมโทเค็นที่ลงลายเซ็นแล้ว - Cloudflare และ Fastly ได้นำสิ่งนี้ไปใช้งานเพื่อลด CAPTCHA แต่โครงสร้างเดียวกันนี้ก็เป็นพื้นฐานให้เว็บเซิร์ฟเวอร์สามารถกำหนดให้ผู้ใช้ต้องพิสูจน์ว่าอุปกรณ์ของตนเป็น ไคลเอนต์ที่ถูกต้องตามปกติ ได้
- Safari มีส่วนแบ่งตลาดราว 20% จึงยังมีผลกระทบจำกัด แต่ตระกูล Chromium มีมากกว่า 70% ดังนั้นหากรวมข้อเสนอของ Google เข้าไปด้วย เว็บไคลเอนต์ราว 90% อาจกลายเป็นเป้าหมายของ attestation
- Attestation อาจกีดกันเบราว์เซอร์ใหม่ ระบบปฏิบัติการใหม่ โอเพนซอร์ส และอุปกรณ์ที่ผู้ใช้ดัดแปลงเอง อีกทั้งยังเสี่ยงที่กฎจะเข้มงวดขึ้นจากเงื่อนไขอย่างระยะเวลาซัพพอร์ตทางการ หรือการติดตั้งส่วนขยายบล็อกโฆษณา
การนำ Apple Private Access Tokens มาใช้งานและจุดประสงค์
- มีความกังวลเพิ่มขึ้นต่อข้อเสนอ Web Environment Integrity ซึ่งดูเหมือนว่าผู้เขียนจาก Google กำลังพัฒนาและทำต้นแบบบน Chromium
- ข้อเสนอนี้เข้าข่าย attestation บนเว็บ ซึ่งอาจจำกัดฟีเจอร์หรือการเข้าถึงทั้งไซต์ตามการที่ไคลเอนต์ได้รับการอนุมัติจากผู้ออกที่เชื่อถือได้หรือไม่
- ผู้ออกความเชื่อถือจริง ๆ มีแนวโน้มสูงว่าจะเป็น Apple, Microsoft และ Google
- Apple ได้พัฒนาและปล่อยระบบที่คล้ายกันมากอย่าง Private Access Tokens ไปแล้วตั้งแต่ 1 ปีก่อน และตอนนี้ถูกรวมเข้ากับ macOS 13, iOS 16 และ Safari
- Apple อธิบาย Private Access Tokens ว่าเป็น “เครื่องมือทรงพลังที่ช่วยพิสูจน์ว่าคำขอ HTTP มาจากอุปกรณ์ที่ถูกต้องตามกฎหมาย โดยไม่เปิดเผยตัวตน”
- เป้าหมายหลักของฟีเจอร์นี้คือการกำจัด CAPTCHA และ Cloudflare กับ Fastly ก็นำไปผสานเป็นกลไกสำหรับระบุไคลเอนต์จริง
- คำอธิบายจาก Cloudflare: Eliminating CAPTCHAs on iPhones and Macs using new standard
- คำอธิบายจาก Fastly: Private Access Tokens: Stepping into the privacy-respecting CAPTCHA-less
วิธีการทำงานของ Private Access Tokens
- Private Access Tokens เป็นการแลกเปลี่ยนที่ค่อนข้างเรียบง่ายบน HTTP โดยมี API ของเบราว์เซอร์ที่ฝังมาในตัวเป็นผู้จัดการ และเชื่อมกับองค์ประกอบของระบบปฏิบัติการเพื่อตรวจสอบว่าเบราว์เซอร์และ OS นั้น ถูกต้องตามกฎหมาย หรือไม่
- คำว่า “ถูกต้องตามกฎหมาย” ในที่นี้ถูกกำหนดโดย attester หรือก็คือหน่วยงานอย่าง Apple
- ลำดับการทำงานพื้นฐานมีดังนี้
- เบราว์เซอร์ส่งคำขอ HTTP ไปยังเว็บเซิร์ฟเวอร์
- เว็บเซิร์ฟเวอร์ปฏิเสธคำขอ และตอบกลับด้วย HTTP 401 พร้อมชาเลนจ์
PrivateToken - เบราว์เซอร์ส่งบางส่วนของชาเลนจ์พร้อมข้อมูลอุปกรณ์ที่ผ่านการตรวจสอบจาก OS ไปยัง attester
- attester ตรวจสอบว่าอุปกรณ์เป็นของจริงและไม่ได้ถูกดัดแปลง จากนั้นจึงส่งโทเค็นที่ลงลายเซ็นแล้วกลับมาร่วมกับผู้ออกโทเค็นที่ origin เชื่อถือและเชื่อถือ attester รายนี้
- เบราว์เซอร์ส่งคำขอซ้ำโดยใส่โทเค็นที่ลงลายเซ็นแล้วไว้ในเฮดเดอร์
Authorization - เซิร์ฟเวอร์สามารถปฏิบัติต่อไคลเอนต์รายนั้นแตกต่างออกไปได้ โดยอิงจากข้อเท็จจริงที่ว่าไคลเอนต์ได้รับการตรวจสอบจากผู้ให้ความเชื่อถือแล้ว
- กระบวนการนี้เกิดขึ้นอยู่แล้วบนอุปกรณ์ Apple ที่ใช้ Safari เมื่อบริการอย่าง Fastly หรือ Cloudflare ซึ่งใช้ฟีเจอร์นี้ สงสัยในความชอบธรรมของคำขอ
- Private Access Tokens แยก flow ของ origin, issuer และ attester ออกจากกันเพื่อมุ่งรักษาความเป็นส่วนตัว แต่การที่ผู้ใช้จะได้รับการปฏิบัติแบบใดบนเว็บก็ยังขึ้นอยู่กับว่า Apple มองว่าการตั้งค่าอุปกรณ์, OS และเบราว์เซอร์นั้นยอมรับได้หรือไม่
ความต่างด้านการแพร่กระจายระหว่าง Safari และ Chromium
- แม้แค่ Private Access Tokens เพียงอย่างเดียวก็สร้างภาระให้กับเว็บและอุตสาหกรรมโดยรวม แต่ด้วยส่วนแบ่งตลาดของ Safari จึงยากที่จะขยายตัวได้เร็วเท่าข้อเสนอของ Google
- ส่วนแบ่งตลาดเบราว์เซอร์ของ Safari ปัจจุบันอยู่ที่ราว 20%
- บนมือถือราว 25%
- บนเดสก์ท็อปราว 15%
- Chrome มีมากกว่า 60% ในทุกกลุ่ม และเมื่อรวม Chromium ทั้งหมดที่รวม Brave, Edge, Opera, Samsung Internet และอื่น ๆ แล้ว จะสูงกว่านั้นอีกราว 10 จุดเปอร์เซ็นต์
- หากมีเพียง Safari ที่ให้ฟีเจอร์นี้ ผู้ให้บริการบางรายอาจใช้งานได้ แต่ก็ยังยากที่จะบล็อกหรือปฏิบัติต่อไคลเอนต์ที่ไม่มี attestation แตกต่างออกไป
- ต่อให้ Safari ไม่ทำ attestation ให้กับ OS หรือเบราว์เซอร์รุ่นเก่า ก็ยากที่จะส่งผลกระทบใหญ่ต่อผู้ใช้ และในเชิงสถิติผู้ใช้อาจแค่เห็น CAPTCHA มากขึ้น
- แต่เมื่อเว็บไคลเอนต์ที่ใช้ Chromium มีมากกว่า 70% หาก Web Environment Integrity ถูกนำมาใช้ ก็อาจแพร่กระจายอย่างรวดเร็วไปเป็นส่วนสำคัญของเว็บ
- หาก Web Environment Integrity และ Private Access Tokens อยู่ร่วมกัน เว็บไคลเอนต์ราว 90% ก็อาจตกอยู่ภายใต้ attestation ได้ และแรงกดดันแบบ “ไม่มี attestation จึงควรถูกมองว่าน่าสงสัย” อาจเพิ่มขึ้น
วิธีที่ Attestation สั่นคลอนความเปิดกว้างของเว็บ
- Attestation เอื้อให้ใช้งานได้เฉพาะ ไคลเอนต์ที่ได้รับอนุมัติ เท่านั้น จึงไม่เป็นผลดีต่อการแข่งขันและนวัตกรรม
- การสร้างเบราว์เซอร์หรือ OS ใหม่จะยากขึ้น
- ความพยายามแบบโอเพนซอร์ส ชุมชน หรืออินดี้รายเล็ก อาจถูกกีดกันจากกลไกแบบนี้อย่างต่อเนื่อง
- มีการเปรียบเทียบว่าหากสมัย IE6 มี attestation อยู่แล้ว การเติบโตของ Firefox และ Chrome คงเผชิญอุปสรรคใหญ่
- โดยการออกแบบ โครงสร้างนี้ทำให้ผู้ใช้ควบคุมอุปกรณ์ของตัวเองได้ยากขึ้น
- หนึ่งในเป้าหมายหลักคือผู้ใช้ที่ใช้ซอฟต์แวร์ที่ถูกดัดแปลงจะไม่ได้รับ attestation ว่าเป็นไคลเอนต์ที่ถูกต้องตามกฎหมาย
- กรณีใช้งานอย่างการท่องเว็บด้วยโทรศัพท์ Android ที่รูตแล้วอาจถูกกีดกัน
- OS หรือฮาร์ดแวร์ที่ผู้ใช้สามารถดัดแปลงได้อย่างเต็มที่ก็ยากที่จะได้รับ attestation ตามแนวทางที่ข้อเสนอเหล่านี้ตั้งใจไว้
- ผู้ให้การอนุมัติอาจทำให้กฎเข้มงวดขึ้นได้ในภายหลัง
- “ทำ attestation ให้เฉพาะอุปกรณ์ที่ยังอยู่ในช่วงซัพพอร์ตทางการ 2 ปีเท่านั้น”
- “ไม่ทำ attestation ให้กับเบราว์เซอร์ที่ติดตั้งส่วนขยายบล็อกโฆษณา”
- ผู้สนับสนุน Web Environment Integrity มองว่าสามารถใช้ holdbacks ซึ่งเป็นการปฏิเสธ attestation สำหรับบางคำขอ เพื่อป้องกันการบล็อกที่อิงกับ attestation ได้
- อย่างไรก็ตาม มีความกังวลว่าแรงกดดันทางธุรกิจจะทำให้ holdbacks ใช้งานจริงได้ยาก และ Android Play Integrity attestation ที่ Google ใช้อยู่ในปัจจุบันก็ไม่ได้ใช้แนวทางนี้
- ความสำเร็จของเว็บพึ่งพาอย่างมากกับการที่สามารถใช้ไคลเอนต์และเซิร์ฟเวอร์ที่หลากหลายได้อย่างเสรี และ attestation ก็ทำลายสมมติฐานนี้ตั้งแต่ระดับการออกแบบ
ความเสี่ยงที่ปรากฏแล้วบน Android
- บน Android นั้น ในทางเทคนิคผู้ใช้สามารถสร้างและรัน OS ของตนเองได้ และดิสทริบิวชัน Android อย่าง LineageOS ก็ยังทำงานได้ตามปกติ
- แต่เพราะฟังก์ชัน attestation จึงยังมีความเสี่ยงต่อเนื่องที่แอปสำคัญอย่างแอปธนาคารจะมองผู้ใช้เป็นสิ่งน่าสงสัยและบล็อกการใช้งาน
- การขัดขวางการแข่งขันระหว่างเวอร์ชัน Android ก็เป็นปัญหาอยู่แล้ว แต่การขัดขวางการแข่งขันทั้งฝั่งเบราว์เซอร์และ OS บนเว็บอาจก่อผลกระทบร้ายแรงยิ่งกว่า
- ใน Anti-Fraud Community Group ยังมี ข้อเสนออื่น ๆ ในตระกูลเดียวกันที่กำลังพูดคุยถึงความเป็นไปได้ของฟีเจอร์เว็บลักษณะนี้
- ปัญหาการโกงและบอตบนเว็บเป็นเรื่องจริง และการถกเถียงเรื่องวิธีป้องกันก็มีคุณค่า แต่การปิดกั้นการแข่งขัน การทำให้โอเพนซอร์สและเว็บแบบเปิดอ่อนแอลง และการพรากอำนาจควบคุมอุปกรณ์จากผู้ใช้ ไม่ใช่เงื่อนไขแลกเปลี่ยนที่สมเหตุสมผล
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
เมื่อวาน ข้อเสนอเบื้องต้นของ Google มีปฏิกิริยาจำนวนมากอย่างเช่น “การแยกบริษัทเริ่มฟังดูสมเหตุสมผลขึ้นมาก”, “ไปให้พ้น Google”, “โกรธและเศร้า”, “ชื่อเสียงของคนที่เกี่ยวข้องจบสิ้นหมดแล้ว”
วันนี้ มีการเปิดเผยว่า Apple ไม่เพียงเสนอฟีเจอร์เดียวกันนี้เมื่อปีก่อน แต่ยังนำไปใช้งานจริงและปล่อยออกมาแล้วด้วย กลับมีโทนอย่าง “นี่อาจเป็นโอกาสที่น่าสนใจในการเริ่มต้นความฝันที่หายไปนานอีกครั้ง”, “พอเข้าใจจุดยืนของทั้งสองฝ่ายอยู่บ้าง”, “จะเปิดไว้ใน Safari ก่อนแล้วเฝ้าดูไปสัก 1–2 ปี”
โดยรวมแล้วยังเป็นแง่ลบอยู่ แต่ ความต่างของโทนที่มีต่อ Apple กับ Google ชัดเจนเกินไป และดูเหมือนสนามบิดเบือนความจริงยังคงอยู่ดี
หนึ่งในนั้นมาโพสต์บน Hacker News ด้วยตัวเองด้วย จึงกลายเป็นการกระตุ้นให้คนที่ไม่ชอบคิดว่าถ้ารุมก่อกวนมากพอ คนเหล่านั้นจะยอมถอย
Apple ไม่เสียเวลากับเรื่องแบบนั้น แต่ตรวจสอบ วางแผน และลงมือทำ ไม่มีใครรู้ตัวตนของคนที่เกี่ยวข้อง โดยปกติก็ไม่ขอ feedback และแทบไม่อธิบายความชอบธรรมของแผนด้วยซ้ำ การโกรธ Apple ในเว็บฟอรัมนั้นไร้ประโยชน์พอ ๆ กับโกรธกำแพงอิฐ
คำซ้ำซากเรื่อง บริษัทไร้ใบหน้า ไม่ได้มีขึ้นโดยไม่มีเหตุผล แต่มันเป็นนโยบายโดยตั้งใจเพื่อปกป้องพนักงาน
แต่กับ Apple กลับตรงกันข้าม เสรีภาพในการติดตั้งแอป third-party ถูกบอกว่าอันตราย เสรีภาพในการใช้ iMessage บนเบราว์เซอร์ถูกบอกว่าไร้เหตุผล และคนส่วนใหญ่ดูไม่สนใจเสรีภาพในการใช้เบราว์เซอร์ third-party บน iOS
lock-in ของบริษัทอื่นเป็นเรื่องแย่ แต่ที่น่าประทับใจคือ lock-in ของ Apple กลับมีฐานผู้ใช้ช่วยเผยแพร่อย่างแข็งขัน
วิธีของ Apple ใกล้เคียงกับเครื่องมือแยกแยะผู้ใช้ที่เป็นมนุษย์กับผู้ใช้ที่ไม่ใช่มนุษย์บนอุปกรณ์ Apple มากกว่า และไม่ได้เปิดให้บริการบล็อกเบราว์เซอร์หรือระบบปฏิบัติการตามอำเภอใจเหมือนข้อเสนอของ Google
ถ้าใช้อุปกรณ์ Apple อยู่แล้ว ก็ประมาณว่าไม่ต้องทำ CAPTCHA เพื่อ “ยืนยันว่าเป็นมนุษย์”
อ้างอิง: https://developer.apple.com/wwdc22/10077
ในทางกลับกัน Google ปล่อยให้คนเกลียด Google กลุ่มเล็ก ๆ ที่เสียงดังบั่นทอนชื่อเสียงไปเรื่อย ๆ แต่แทบไม่ทำ PR เพื่อควบคุม narrative เลย
ดูเหมือนยังเชื่อว่าเสียงสะท้อนของ “don’t be evil” เพียงครั้งเดียวจะยังดังก้องไปได้อีก 20 ปีให้หลัง
ตอน Microsoft ยัด IE มากับ Windows นั้นเป็นเรื่องเลวร้าย แต่พอ Apple ยัด Safari มาและกันเบราว์เซอร์คู่แข่งออก กลับถูกมองว่าเป็นสิ่งที่ดีที่สุดสำหรับลูกค้า
นี่อาจเป็นจุดที่อินเทอร์เน็ต แยกแขนง จริง ๆ ก็ได้ เป็นสิ่งที่ถูกคาดการณ์มาตั้งแต่ยุค 90
ฝั่งหนึ่งอาจเป็น เว็บองค์กร ที่ “สะอาด” ได้รับการอนุมัติจากผู้มีอำนาจ และทุกคนถูกตรวจสอบตัวตนมากเกินไป ส่วนอีกฝั่งอาจเกิดจักรวาล เกรย์เน็ต ที่หลวมกว่า รวมสื่อลามกและชุมชนแบบกระจายศูนย์ไว้ด้วยกัน
ถ้านักประดิษฐ์ซ่อมแซมทั้งหลายถูกผลักออกจากเครือข่ายองค์กรทั้งหมด นั่นก็อาจเป็นโอกาสที่น่าสนใจในการเริ่มต้นความฝันที่หายไปนานอีกครั้ง
ผมเคยจินตนาการว่ามีโครงสร้างส่วนบนทางสังคมคล้ายฟองสบู่ที่แทน “สังคม” เกิดขึ้นเหนืออินเทอร์เน็ต ตั้งแต่ยุค 90 ก็มีเวอร์ชันเล็ก ๆ อยู่แล้ว แต่เริ่มจริงจังขึ้นพร้อมการเติบโตของโซเชียลมีเดียอย่าง Myspace, Facebook, Twitter
ผมไม่คิดว่าเป็นเรื่องบังเอิญที่ “cancel culture” ตามมาไม่นาน เพราะเมื่อเกิดพื้นที่สาธารณะเสมือนจริงขึ้นแล้ว ประเด็นก็กลายเป็นว่าใครหรืออะไรมีสิทธิอยู่ในนั้น
เป็นท่าทีแบบ “ในที่สุดก็จะได้ทดสอบทักษะที่ผู้คนล้อเลียนผมมานานเสียที”
ปัญหาคือทั้งสองกรณีต่างเพิกเฉยต่อคนส่วนใหญ่ที่จะต้องทนทุกข์ภายใต้ระเบียบใหม่ คนที่จะหลุดออกจากสวนปิดล้อมของบริษัทแล้วไปสู่ทางด่วนข้อมูลเสรีได้นั้นคงมีน้อยมาก
เหลือเพียงเสียงสะท้อนเลือนรางของเว็บองค์กรที่ถูกเก็บรักษาผ่านเกรย์เน็ต และนักโบราณคดีดิจิทัลพยายามขุดค้น “ความลับ” แห่งภูมิปัญญาที่สูญหายซึ่งซ่อนอยู่ในเว็บองค์กร
คงมีใครสักคนเขียนไว้แล้ว แต่ดูเข้าท่าดี
ในสภาพแวดล้อมที่บ้านซึ่งคลาวด์สาธารณะมาบรรจบกับการใช้งานส่วนตัว เช่น tunnel ของ Cloudflare Access สำหรับใช้งานส่วนตัวกับ tenant ธุรกิจ MS365 ก็ต้องการอยู่บ้าง
แต่ไม่อยากให้มันแตะต้องประสบการณ์ท่องเว็บส่วนตัวหรือสภาพแวดล้อมเบราว์เซอร์ส่วนตัวเลยเด็ดขาด
ตอนนี้ความต้องการเหล่านี้แทบจะขัดแย้งกันเอง และเทคโนโลยีก็หลุดออกจากถุงไปแล้ว
ความฝันไซเบอร์พังก์ยุค 90 นั้นเท่ดี แต่ดูเหมือนจะละเลยความจริงทางกายภาพที่ว่า หากจะเชื่อมต่อกับ “เน็ต” ก็ต้องผ่านคอขวดที่เรียกว่าผู้ให้บริการอินเทอร์เน็ตเสมอ
ท้ายที่สุดแล้ว มีอุปสรรคที่แก้ไม่ได้ต่อระดับที่อินเทอร์เน็ตจะเป็นปฏิปักษ์ต่อระบบได้
อาจจะผิดก็ได้ แต่ Web Attestation อาจเป็นเหมือนคำพิพากษาประหารสำหรับการที่ อุปกรณ์ Linux ซึ่งไม่ใช่ Android หรือ Chrome OS จะใช้งานเว็บในฐานะไคลเอนต์ที่เท่าเทียมกันได้
Linux เป็นแพลตฟอร์มที่หลากหลายและแฮ็กได้ง่ายเกินไปสำหรับการยืนยันตัวตนระยะไกลให้ทำงานได้อย่างเสถียร สุดท้ายจึงน่าจะถูกกันออกไปทั้งหมด
อาจมีข้อยกเว้นเฉพาะดิสโทรไม่กี่ตัวที่ “ได้รับพร” แต่ดิสโทรแบบนั้นก็จะถูกอุตสาหกรรมควบคุม และห่างไกลจากจิตวิญญาณของ Linux ไปมาก
จะติดตัวจัดประเภทป้องกันสแปมของแทบทุกเว็บไซต์ และถ้าจะเข้าพื้นที่ที่มีการป้องกัน ก็ต้องแก้ CAPTCHA 3–5 ครั้ง
Wikipedia ก็ปิดกั้นการแก้ไขเช่นกัน: https://meta.wikimedia.org/wiki/Talk:Apple_iCloud_Private_Re...
ในเมื่อดูเหมือนตัวเองไม่มีแรงใจพอจะเลิกเว็บพวกนั้น บางทีการที่อีกฝั่งช่วยบล็อกไม่ให้โหลดคอนเทนต์ให้ก็คงเป็นสิ่งที่จำเป็นเสียมากกว่า
ตอนนี้พูดออกมาตรงนี้แล้ว ก็ไม่ใช่ความลับอีกต่อไป
https://github.com/jwise/28c3-doctorow/blob/master/transcrip...
พวกมันก็เป็นแพลตฟอร์มที่หลากหลายและแฮ็กได้มากพอจะดูไม่เพียงพอในอนาคตที่ต้องพิสูจน์ว่ามีฮาร์ดแวร์เฉพาะบางอย่างอยู่
มักได้ยินอยู่บ่อย ๆ ว่าดิสโทรไม่กี่ตัวที่ “ได้รับพร” จะถูกอุตสาหกรรมควบคุมจนจิตวิญญาณของ Linux หายไป แต่ไม่ค่อยได้ยินคำอธิบายชัด ๆ ว่ามันจะเป็นแบบนั้นได้อย่างไร
Linux เกิดขึ้นเพราะ UNIX ที่ถูกอุตสาหกรรมควบคุม และถ้าพรากจิตวิญญาณนั้นไปจาก Linux มันก็จะถูกฟอร์กเป็นโปรเจกต์ชุมชนอื่น
ตราบใดที่ไม่ถอดไลเซนส์ GPL ออก Linux ก็จะยังรักษา “จิตวิญญาณของ Linux” ไว้จนกว่าจะไม่มีใครใช้มันเลย
ผมไม่เห็นด้วยกับข้ออ้างที่ว่าเพราะ Safari ไม่ใช่เบราว์เซอร์หลักที่ครองตลาด จึงไม่อันตรายเท่าข้อเสนอของ Google
จริง ๆ แล้วไม่ว่าจะ Apple ทำหรือ Google ทำก็แย่พอกัน และ Apple เลือกทางที่น่าผิดหวังอย่างยิ่ง
แม้ Google จะดันเรื่องนี้ แต่ถ้า Apple ปฏิเสธ ก็ยากที่จะบังคับใช้ได้จริง แม้ตัวเลขจะไม่สูงเท่า Chrome แต่ก็ใหญ่พอจนไม่สามารถตัด iDevice ทั้งหมดทิ้งได้
บริษัทที่สำคัญจริง ๆ มีแค่สามรายคือ Apple, Google, Microsoft
น่าเสียดายที่ครั้งนี้มันไม่อาจช่วยหยุดหายนะอีกอย่างหนึ่งได้
เพราะอย่างนั้นผมจึงกังวลกับกฎหมายที่บังคับให้ Apple เปิดให้ sideloading ด้วย ผมชอบแนวคิดที่ผู้คนควบคุมระบบของตัวเอง แต่ในทางปฏิบัติกลัวว่ามันจะกลายเป็นตะปูตัวสุดท้ายที่ตอกให้ Google ควบคุมเว็บได้ทั้งหมดไปจนถึงปลายทางฝั่งไคลเอนต์
ทุกครั้งที่ผมชี้ว่าฟีเจอร์ที่พวกเขาทำไม่รองรับหลายเบราว์เซอร์ พวกเขาจะพูดเหมือนกันหมดว่าให้เปลี่ยนจาก Firefox ไปใช้ Chrome
ผมไม่เคยได้ยินใครบอกให้เปลี่ยนไปใช้ Safari เพื่อให้บางอย่างทำงานได้เลย แค่นี้ก็บอกอะไรได้มากแล้ว
บน iOS ดูเหมือนว่าจะปิดฟีเจอร์นี้ได้
ไปที่ Settings เลือกบัญชีผู้ใช้ด้านบนสุด เข้า “Password & Security” แล้วเลื่อนลงไปถึง Advanced จากนั้นปิด “Automatic Verification”
https://blog.cloudflare.com/how-to-enable-private-access-tok...
https://support.apple.com/en-us/HT213449
System Settings -> iCloud Settings(ชื่อผู้ใช้) -> Password & Security -> Automatic Verification
ถ้า Chrome ปล่อย WEI ออกมา Chromium fork หลายตัวก็คงทำให้ปิดได้เช่นกัน ต่อให้ Chrome ไม่ทำให้ก็ตาม และคุณก็ใช้ Firefox ได้
ปัญหาคือเมื่อธนาคาร หน่วยงานภาษี หรือบริการสตรีมมิงที่คุณชอบเริ่มบังคับใช้ฟีเจอร์นี้
ประเด็นหลักคือการที่ ผู้ใช้ทั่วไปจำนวนมาก มีฟีเจอร์นี้อยู่แล้วนั่นเอง
ผมสังเกตเรื่องนี้จริง ๆ และเคยคิดจะเขียนบล็อกด้วย แต่เหตุผลเดียวที่มันดูไม่เป็นปัญหาคือมันถูกนำไปใช้เฉพาะบนแพลตฟอร์มของ Apple ทำให้บริการต่าง ๆ ไม่มีวิธีใช้สิ่งนี้เพื่อจำกัดผู้ใช้จริง ๆ
มันเป็นแค่องค์ประกอบเพิ่มเติมที่ผู้คนสามารถใช้เป็นสัญญาณอีกอย่างหนึ่งได้
ในทางตรงกันข้าม ข้อเสนอของ Google สนใจจะผลักดันสิ่งนี้ให้เป็น ฟีเจอร์ที่เปิดอยู่ตลอดเวลา อย่างชัดเจน
คำอธิบายที่ว่ากรณีใช้งานอย่าง “การพิสูจน์ความสมบูรณ์ของแพลตฟอร์มแบบเด็ดขาด” ตอนนี้พึ่งพาการทำ fingerprint ฝั่งไคลเอนต์ แท้จริงแล้วคือข้ออ้างว่าการพิสูจน์แบบเด็ดขาดที่มีเอนโทรปีจำกัดจะมาแทนการทำ fingerprint ที่ล่วงล้ำ และในระยะยาวจะเปิดทางสู่แนวปฏิบัติที่เป็นมิตรต่อความเป็นส่วนตัวมากขึ้น
ข้อเท็จจริงที่ว่า Apple เป็นรายแรกที่นำไปใช้ พิสูจน์ได้เพียงอย่างเดียวว่าคนที่คาดหวังว่า Apple จะมาช่วยเรานั้นไร้เดียงสา
ประเด็นนี้น่าสนใจมากจริง ๆ และก็น่าจะก่อให้เกิดความแตกแยกได้
มีกรณีใช้งานมากมายมหาศาลบนเว็บที่ผู้ใช้ต้องการรู้ว่ากำลังสื่อสารกับสแต็กฮาร์ดแวร์และซอฟต์แวร์ที่ “เชื่อถือได้” หรือไม่
ตลอดหลายปีที่ผ่านมา เราออกแบบและสร้างระบบโดยตั้งสมมติฐานว่าแทบไม่มีความเชื่อมั่นในสแต็กเลย ซึ่งเพิ่มความซับซ้อนและต้นทุนอย่างมหาศาล จำกัดฟังก์ชัน และทำให้ทุกอย่างยากกว่ามากเมื่อเทียบกับกรณีที่สามารถตั้งสมมติฐานได้ว่าสแต็กนั้นเชื่อถือได้
ในขณะเดียวกัน อย่างที่กำลังถูกชี้ให้เห็นกันมากในตอนนี้ เมื่อมีการผูกโยงกับการผูกขาดของบริษัทเทคโนโลยียักษ์ใหญ่ แนวคิดเรื่อง ความเชื่อถือ ก็กลายเป็นเรื่องยากมาก
ด้านหนึ่ง ในโลกนี้มีบริษัทเพียงไม่กี่แห่งที่สามารถดำเนินทีมเทคโนโลยีขนาดใหญ่เพื่อรับมือกับผู้ก่อภัยคุกคามอย่างต่อเนื่องได้ ดังนั้นก็มีประเด็นว่า ถ้าเราสามารถเชื่อถือคำมั่นด้านความปลอดภัยที่พวกเขาให้ไว้ได้ก็คงดี หากคำมั่นนั้นเชื่อถือได้จริง มันก็ดีกว่าคำมั่นใด ๆ ที่บุคคลคนหนึ่งจะให้ได้เกี่ยวกับซอฟต์แวร์และแพลตฟอร์มของตนเอง
แต่อีกด้านหนึ่ง เมื่อมองในความหมายเชิงอุดมคติแบบแฮกเกอร์ คำว่า “ได้รับความเชื่อถือ” ก็อ่านได้ว่า “ได้รับการรับรองโดยผู้ผูกขาด” และ “อาจมีแบ็กดอร์ของหน่วยงานรัฐท้องถิ่น” ซึ่งพาเราไหลลงไปอีกขั้นสู่อนาคตเทคโนโลยีแบบฟาสซิสต์ที่เต็มไปด้วยการควบคุม ขาดนวัตกรรม และท้ายที่สุดถูกครอบงำโดยผู้เล่นเพียงไม่กี่ราย
สุดท้ายแล้ว ผมคิดว่าโซลูชันที่มีโอกาสสำเร็จต้องไม่ใช่แบบอิงรีจิสทรี แต่ต้องรวมถึง เทคโนโลยีการรับรองฮาร์ดแวร์แบบเปิด ที่เชื่อถือได้ ต้องสามารถสร้างการพิสูจน์แบบโลคัลที่แข็งแกร่งและตรวจสอบได้อย่างอิสระ
ผมรู้จักบริษัทเทคโนโลยีอยู่ไม่กี่แห่งที่กำลังจัดการปัญหานี้ในฝั่งซิลิคอน แต่มันเป็นปัญหาที่ยากมาก และก็ยังไม่แน่ชัดว่าตอนนี้มีความต้องการมากพอให้พวกเขาอยู่รอดหรือไม่
โดยส่วนตัวแล้ว ตอนนี้ผมเลือกเปิดสิ่งนี้ไว้ใน Safari แล้วรอดูไปอีก 1–2 ปีข้างหน้า
เทคโนโลยี DRM ก็ถูกพูดถึงด้วยคำแบบนี้เช่นกัน แต่เป้าหมายไม่ใช่การมอบความเชื่อถือให้ผู้ใช้ หากเป็นการมอบความเชื่อถือให้ผู้พัฒนาหรือเจ้าของคอนเทนต์
เห็นได้ชัดว่านี่อาจไม่ใช่เรื่องของความเชื่อถือจริง ๆ
ต้องเลือกว่าจะรับประโยชน์จากระบบของรัฐหรือไม่ และคุ้มค่ากับต้นทุนที่ต้องรับหรือเปล่า
ปัญหาของระบบส่วนใหญ่แบบนี้คือมันจัดการ กรณียกเว้น ไม่ได้เลย
มันทำงานได้ดีสำหรับประชากร 99% แต่ปล่อยให้อีก 1% ที่เหลือไปซวยเอาเอง
เหมือนกับเวลาคุณอยากเข้าที่ทำงานหลังเลิกงาน แค่จะไปหยิบกุญแจรถที่ลืมไว้ แต่หุ่นยนต์กลับปฏิเสธไม่ให้เข้า
ระบบถูกออกแบบมาให้ปลอดภัย จึงไม่สามารถพูดโน้มน้าวหุ่นยนต์ได้ ถ้าเป็นคน โดยปกติแล้วคงคุยกันเพื่อโน้มน้าวและหาทางออกที่ใช้ได้ง่ายกว่ามาก
สุดท้ายคนสายเทคโนโลยีก็มักพยายามแก้ด้วยเทคโนโลยี “ถ้ามีปัญหา เดี๋ยวฉันแก้เอง ดูทักษะฉันตอน DJ เปิดเพลงไปด้วยสิ”
เรื่องอย่างบัญชีธนาคารถูกแฮ็กเพียงเพราะมีคนพูดเก่งและแต่งเรื่องที่ดูน่าเชื่อเพื่อโน้มน้าวผู้คุมประตูที่เป็นมนุษย์ได้ ก็เกิดขึ้นแบบนั้น
ถ้ามันเป็นวิธีที่บอกได้ว่า “ใช่ คนนี้เป็นคนจริง” ก็อาจมีประโยชน์ แต่สิ่งนี้เป็นเพียงการพิสูจน์ของระบบ จึงไม่มีทางรู้ได้ว่าจะกันผู้ประสงค์ร้ายได้หรือไม่ และจะถูกเข้าใจผิดหรือนำไปใช้ผิดเหมือนระบบอื่น ๆ อย่าง CORS หรือเปล่า
ข้อสรุปเชิงตรรกะของระบบนี้คือ “ถ้ามีระบบปกติ ก็เป็นผู้ใช้ปกติ ถ้าไม่มีก็ไม่ใช่”
เข้าใจจุดยืนของทั้งสองฝ่ายในระดับหนึ่ง
ถ้ามองเจตนาของคนอื่นในแง่ดี เว็บที่เต็มไปด้วยมนุษย์ที่ระบุตัวตนได้และตัวแทนที่พวกเขาอนุมัติ อาจเป็นพื้นที่เว็บในอุดมคติที่ “สะอาด” ที่สุดเท่าที่เราจะเห็นได้
เว็บที่เต็มไปด้วยบัญชีปลอมและ link farm ไม่ใช่อุดมคติ
จุดหมายปลายทางที่ชัดที่สุดของกระแสนี้คือ บัตรประจำตัวดิจิทัลที่ออกโดยรัฐบาล ซึ่งใช้พิสูจน์ตัวตนและทำหน้าที่ล็อกอินด้วย
ถ้าหรี่ตามอง ก็อาจเห็นว่านี่เป็นเหมือนก้าวหนึ่งที่พาไปสู่ตรงนั้น
นี่คืออุดมคติแบบยุค 70 ที่กลายเป็นจริงหรือ? ไม่ใช่ แต่ผมมองว่าเป็นการประนีประนอมที่มีเหตุผลอยู่บ้าง
แล้วถ้าเชื่อรัฐบาลไม่ได้ล่ะ? นั่นน่าจะเป็นปัญหาที่อินเทอร์เน็ตแบบไหนก็แก้ไม่ได้ เป็นปัญหาของโลกจริง
สำหรับผม มันฟังเหมือนเว็บที่ ถูกทำให้ปลอดเชื้อ มากกว่า
ถ้าลองมองข้ามไปชั่วคราวว่าท้ายที่สุดมนุษย์ก็จะหาวิธีเลี่ยงระบบนั้นได้ และสมมติว่ามันกลายเป็นพื้นที่เว็บที่ “สะอาด” ที่สุดจริง ๆ นั่นก็เท่ากับตั้งสมมติฐานว่าผู้บริโภคต้องการสิ่งนั้น
ในโลกของแอปแบบเนทีฟ มี App Store การควบคุมแบบล็อกดาวน์ และตัวตนของแอปอยู่แล้ว แต่เว็บก็ยังครองการค้าขาย และดูเหมือนจะแข็งแกร่งขึ้นด้วยซ้ำจากกรณีอย่าง Figma
ถ้าอย่างนั้น เสียงเรียกร้องเว็บที่ “ถูกชำระล้าง” แบบนี้อยู่ที่ไหน? อย่างน้อยฝั่งผู้บริโภคก็ดูไม่เหมือนมีความต้องการแบบนั้นเลย
ทำไมจึงต้องมีการพิสูจน์ตัวตนที่แข็งแรงเกินเหตุขนาดนี้? ถ้าจำเป็นจริง อินเทอร์เน็ตทำงานมาได้อย่างไรจนถึงตอนนี้?
แต่ในความเป็นจริงตอนนี้ไม่มีใครเสนอสิ่งนั้นเลย วิธีของ Apple หรือ Google ต่างก็ยังไปไม่ถึงใกล้ ๆ สิ่งที่พวกเขาบอกว่าจะทำคือการรับประกัน “ความสมบูรณ์” ของแพลตฟอร์ม
แล้วความสมบูรณ์แบบไหนกันแน่? ในตัวอย่างบอกว่าแสดงให้เห็นว่าผู้ใช้กำลังรันเว็บไคลเอนต์บนอุปกรณ์ Android ที่ปลอดภัย
กล่าวคือ ไม่ได้บอกว่าผู้ใช้เป็นบุคคลเดียวไม่ซ้ำ และไม่ได้ให้ตัวระบุที่ใช้ประโยชน์ได้ของบุคคลนั้น ในตัวอย่างนี้และในกรณีของ Apple สิ่งที่บอกมีเพียงว่าอุปกรณ์ไม่ได้ถูก root หรือ jailbreak
จริง ๆ แล้วแนวคิดนี้มีประโยชน์ได้แค่ในฐานะส่วนหนึ่งของเกมแมวไล่จับหนูที่ใหญ่กว่าเท่านั้น เช่นเดียวกับการคุ้มครองลิขสิทธิ์ remote attestation ก็ถูกจำกัดด้วยสิ่งที่มันพิสูจน์ได้จริง
การห้ามบันทึกด้วยกล้องวิดีโอในโรงภาพยนตร์ทำได้ยาก และสุดท้ายก็มีขั้นกลางมากมายที่อาศัยข้อเท็จจริงว่าภาพยนตร์คือชุดภาพต่อเนื่องกับเฟรมของตัวอย่าง PCM ฉันใด ต่อให้อุปกรณ์มีราคาแพง ก็ไม่อาจห้ามใครบางคนรวบรวมอุปกรณ์หลายเครื่องมาทำงานได้ฉันนั้น
มีคนจำนวนมากที่มีอุปกรณ์ Android เป็นกอง ๆ เพื่อหลอกระบบอยู่แล้ว และในบางกรณีซื้อได้เครื่องละ 50 ดอลลาร์ จึงไม่ใช่อุปสรรคที่มีความหมาย
สุดท้ายมันมีผลเพียงเพิ่มต้นทุนและความซับซ้อนในการเดินบอต และถ้าดันจุดคุ้มทุนให้สูงพอ ในทางทฤษฎีก็อาจเรียกว่าชนะได้ แต่เพราะกำไรจากสแปมและการฉ้อโกงสูงเกินไป เรื่องนั้นจึงจะไม่เกิดขึ้น
แม้รับมือกันมาหลายปี ก็ยังไม่เฉียดใกล้เลย และเงินที่ไหลอยู่ในอุตสาหกรรมการหลอกระบบแบบนี้มากพอจะรับภาระต้นทุนนั้นได้เหลือเฟือ
ต่อให้ผสมบัตรประจำตัวของรัฐบาลเข้ามาก็ไม่ต่างกัน เบื้องหลังการทำสแปมแทบทั้งหมดมีคนจริงอยู่ ดังนั้นแม้จะได้รับหลักฐานแบบ blind ว่าใครสักคนเป็นพลเมือง สิ่งที่รู้เกี่ยวกับคนคนนั้นก็ยังแทบไม่มี
ถ้าจะช่วยได้ คงต้องไม่ใช่การพิสูจน์ว่าเป็นเป้าหมายที่ชอบธรรม แต่ต้องเป็นการได้รับ ID เฉพาะตัวของแต่ละคนจริง ๆ
และถ้านั่นคือจุดจบของอินเทอร์เน็ต พูดตรง ๆ การทดลองทั้งหมดนี้ก็ไม่คุ้มค่าเลย
จะเสียบเมาส์หรือคีย์บอร์ดปลอมเพื่อป้อนอินพุตโดยตรงก็ได้
ฮาร์ดแวร์ความปลอดภัย ดูเหมือนไม่มีข้อดี สำหรับคนที่แพร่ข้อมูลเท็จในระดับหนึ่ง มันยังไม่เป็นแม้แต่ลูกระนาดชะลอความเร็ว
แค่ทำให้ผู้ไม่ประสงค์ดีที่มือใหม่มาก ๆ หรือทำแบบเบา ๆ ลำบากขึ้นนิดหน่อย และจำกัดอย่างหนักต่อคนที่สร้างเบราว์เซอร์ได้ รวมถึงผู้ใช้ Linux หรือคนที่ใช้อุปกรณ์ที่ไม่ถูกเชื่อถือ เช่นคนที่ปิด Trusted Boot
ไม่รู้ว่ายังจำ AllAdvantage ได้ไหม
มันเป็นบริการราวช่วงเปลี่ยนศตวรรษที่จ่ายเงินให้ผู้ใช้เพื่อแสดงโฆษณาบนเดสก์ท็อป แต่จะจ่ายเฉพาะตอนที่กำลังใช้พีซีจริง ๆ
ผู้คนหลอกมันด้วยอุปกรณ์ขยับเมาส์ และเกิดการแข่งขันด้านอาวุธเล็ก ๆ ขึ้น
เทคโนโลยีนี้คงเป็นของในฝันสำหรับพวกเขา สามารถรู้ได้ว่าคำขอมาจากเบราว์เซอร์จริงหรือมาจากสคริปต์ และยังอาจปิดการพิสูจน์ได้หากมีการจำลองอินพุตด้วยไดรเวอร์ที่ไม่น่าเชื่อถือ หรือถ้าเบราว์เซอร์ถูกทำให้ทำงานอัตโนมัติ
เป็นเทคโนโลยีที่น่ารังเกียจจริง ๆ
สิ่งนี้ใกล้เคียงกับการผสานหมวดหมู่ผลิตภัณฑ์ด้านความปลอดภัยที่ได้รับความนิยมมากเข้ากับตัวเบราว์เซอร์เองอย่างแนบแน่น
วันนี้คุณสามารถยืนจุดยืนเชิงปรัชญาและปฏิเสธทุกเว็บไซต์ที่ใช้ reCAPTCHA/hCAPTCHA ได้ และพรุ่งนี้ก็สามารถปฏิเสธทุกเว็บไซต์ที่ใช้ PAT ได้