Header X-Browser-Validation ใหม่ของ Chrome ก่อให้เกิดความกังวลเรื่องการต่อต้านการแข่งขัน

ทีมชุมชน BigGo
Header X-Browser-Validation ใหม่ของ Chrome ก่อให้เกิดความกังวลเรื่องการต่อต้านการแข่งขัน

Google Chrome ได้เพิ่ม HTTP headers ใหม่หลายตัวอย่างเงียบ ๆ โดยมีหนึ่งตัวที่ก่อให้เกิดความกังวลอย่างมากเกี่ยวกับการแข่งขันของเบราว์เซอร์และเสรีภาพของผู้ใช้ ส่วนเพิ่มเติมที่ถกเถียงกันมากที่สุดคือ header x-browser-validation ซึ่งมี hash ที่เข้ารหัสด้วย base64 ที่ดูเหมือนจะถูกออกแบบมาเพื่อตรวจสอบความถูกต้องของเบราว์เซอร์

ส่วนหัว Chrome ใหม่

  • x-browser-channel: "stable"
  • x-browser-copyright: "Copyright 2025 Google LLC. All rights reserved."
  • x-browser-validation: Base64-encoded SHA-1 hash
  • x-browser-year: "2025"

การวิศวกรรมย้อนกลับเผยให้เห็นกลไกที่เรียบง่ายแต่น่ากังวล

นักวิจัยด้านความปลอดภัยได้ทำการวิศวกรรมย้อนกลับระบบการตรวจสอบของ Chrome สำเร็จแล้ว และพบว่าใช้วิธีการที่ตรงไปตรงมา เบราว์เซอร์จะรวม API key เฉพาะแพลตฟอร์มกับ user agent string แล้วทำการ hash ข้อมูลนี้โดยใช้ SHA-1 และเข้ารหัสด้วย base64 แม้ว่าการใช้งานทางเทคนิคจะเรียบง่าย แต่ผลกระทบที่ตามมาทำให้หลายคนในชุมชนเทคโนโลยีเป็นห่วง

การเลือกใช้ SHA-1 สำหรับการ hashing ทำให้ผู้เชี่ยวชาญด้านความปลอดภัยงงงวย เนื่องจากมีทางเลือกที่แข็งแกร่งกว่าอย่าง SHA-256 ที่มีอยู่และทำงานได้ดีกว่าบนฮาร์ดแวร์สมัยใหม่ อย่างไรก็ตาม เนื่องจาก collision resistance ไม่ใช่สิ่งสำคัญสำหรับกรณีการใช้งานนี้ hash function รุ่นเก่าก็ตอบสนองวัตถุประสงค์ในการปิดบังได้อย่างเพียงพอ

กระบวนการสร้างการตรวจสอบความถูกต้อง

  1. รวม API key เฉพาะแพลตฟอร์มเข้ากับ user agent string แบบเต็ม
  2. แฮชข้อมูลที่รวมกันโดยใช้อัลกอริทึม SHA-1
  3. เข้ารหัสผลลัพธ์แฮช 20 ไบต์ในรูปแบบ base64
  4. รวมไว้เป็นค่า header ของ x-browser-validation

ความกลัวเรื่องการต่อต้านการแข่งขันสะท้อนการต่อสู้ทางกฎหมายในอดีต

Headers ใหม่เหล่านี้ได้ปลุกความทรงจำเกี่ยวกับระบบ DRM ของเกมคอนโซลในประวัติศาสตร์ โดยเฉพาะระบบป้องกันที่อิงตามเครื่องหมายการค้าของ Nintendo ผู้เชี่ยวชาญด้านกฎหมายชี้ไปที่คดี Sega v. Accolade เป็นแนวทางที่แสดงว่าการปฏิบัติที่เข้มงวดเช่นนี้อาจไม่สามารถยืนหยัดได้ในศาล โดยเฉพาะเมื่อพวกเขาจำกัดการทำงานร่วมกัน

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

จังหวะเวลาดูเหมือนจะน่าสงสัยเป็นพิเศษ เนื่องจากมาหลังจากที่ Google แพ้คดีต่อต้านการผูกขาดเมื่อเร็ว ๆ นี้ นักวิจารณ์โต้แย้งว่าสิ่งนี้อาจถูกใช้เพื่อเลือกปฏิบัติต่อเบราว์เซอร์ที่ไม่ใช่ Chrome แม้ว่านั่นจะไม่ใช่เจตนาที่แถลงไว้ก็ตาม

ผลกระทบต่อการแข่งขันของเบราว์เซอร์และการเลือกของผู้ใช้

ระบบการตรวจสอบสร้างสถานการณ์ที่น่ากังวลหลายประการ ผู้ใช้ Firefox, Safari หรือเบราว์เซอร์อื่น ๆ ที่ปลอมแปลง user agent ของ Chrome เพื่อหลีกเลี่ยงการลงโทษด้านประสิทธิภาพของ Google ตอนนี้สามารถถูกตรวจพบได้ง่ายและอาจถูกบล็อก สิ่งนี้ปิดทางเลี่ยงที่ผู้ใช้หลายคนพึ่งพาเพื่อเข้าถึงบริการของ Google ด้วยฟังก์ชันการทำงานเต็มรูปแบบ

แม้ว่าระบบจะถูกวิศวกรรมย้อนกลับและสามารถปลอมแปลงได้ในทางทฤษฎี แต่การเปลี่ยนแปลง Manifest V3 ของ Google จำกัดความสามารถของ extensions ในการแก้ไข headers แบบไดนามิกใน Chrome สิ่งนี้สร้างสถานการณ์ที่ไม่สมมาตรซึ่งผู้ใช้ Chrome มีตัวเลือกน้อยลงในการหาทางเลี่ยงการเลือกปฏิบัติที่อาจเกิดขึ้น

คีย์ API เฉพาะแพลตฟอร์ม

แพลตฟอร์ม คีย์ API
Windows AlzaSyA2KlwBX3mkFo300m9LUFYQhpqLoa_BNhE
Linux AlzaSyBqJZh-7pA44blAaAkH6490hUFOWX0KCYM
macOS AlzaSyDr2UxVnv_U85AbhhY8XSHSlavUWODC-SY

ผลกระทบในวงกว้างต่อเสรีภาพของเว็บ

Header x-browser-validation แสดงถึงอีกก้าวหนึ่งสู่สิ่งที่นักวิจารณ์เรียกว่า client attestation - ระบบที่ตรวจสอบไม่เพียงแต่สิ่งที่ผู้ใช้อ้างว่ากำลังใช้งาน แต่สิ่งที่พวกเขากำลังใช้งานจริง ๆ สิ่งนี้เชื่อมโยงกับความกังวลในวงกว้างเกี่ยวกับข้อเสนอ Web Environment Integrity (WEI) ที่อาจเปลี่ยนแปลงพื้นฐานของการที่เบราว์เซอร์โต้ตอบกับเว็บไซต์

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

อ้างอิง: Chrome X-Browser-Validation Header Reverse Engineering & Generator