User-Agent อธิบาย: จากสตริง UA และลายนิ้วมือของเบราว์เซอร์สู่ Client Hints

เปิดแผงเครือข่ายในเครื่องมือสําหรับนักพัฒนาซอฟต์แวร์ของเบราว์เซอร์ แล้วคุณจะพบส่วนหัว User-Agent เกือบทุกครั้ง ดูเหมือนการแนะนําสั้น ๆ : เบราว์เซอร์ใดกําลังส่งคําขอระบบปฏิบัติการใดและเวอร์ชันใดที่อ้างว่าเป็น

นั่นทําให้การปฏิบัติต่อส่วนหัวเป็นรหัสอุปกรณ์เป็นเรื่องน่าดึงดูดใจ หรือสันนิษฐานว่าการเปลี่ยนบรรทัดเดียวสามารถเปลี่ยนเบราว์เซอร์ให้เป็นอุปกรณ์อื่นได้ แนวคิดทั้งสองถูกต้องเพียงบางส่วนเท่านั้น

สตริง User-Agent หรือ UA คือข้อมูลความเข้ากันได้ที่ประกาศโดยไคลเอ็นต์ ไม่ใช่ข้อมูลประจําตัวที่เชื่อถือได้ และไคลเอ็นต์สามารถแก้ไขได้ กระนั้นมันก็ไม่ได้ดํารงอยู่อย่างโดดเดี่ยว ไซต์สามารถเปรียบเทียบ UA กับ Client Hints, JavaScript API, คุณสมบัติหน้าจอ, แบบอักษร, Canvas, WebGL, บริบทเครือข่าย และพฤติกรรม คําถามที่เป็นประโยชน์จึงไม่ใช่แค่ว่า UA สามารถเปลี่ยนแปลงได้หรือไม่ แต่มีบทบาทอย่างไรในพื้นผิวที่สังเกตได้ทั้งหมดของเบราว์เซอร์

บทความนี้ใช้มาตรฐาน HTTP และการวิจัยลายนิ้วมือของเบราว์เซอร์เพื่อตอบคําถามสี่ข้อ:

1. เหตุใดสตริง UA จึงดูเหมือนโบราณคดีของเบราว์เซอร์
2. UA สามารถให้ข้อมูลระบุตัวตนได้มากน้อยเพียงใด และเราควรตีความงานวิจัยอย่างไร
3. เหตุใดการเปลี่ยนเฉพาะ UA จึงสร้างความไม่สอดคล้องกันที่ชัดเจนยิ่งขึ้น
4. UA Reduction และ User-Agent Client Hints เปลี่ยนแปลงอะไรไปจริงๆ

ในบทความนี้ UA หมายถึงส่วนหัวของคําขอ HTTP User-Agent เป็นหลัก เรายังหารือเกี่ยวกับ navigator.userAgent และ navigator.userAgentData ใน JavaScript อินเทอร์เฟซเหล่านี้มีความเกี่ยวข้องกัน แต่ไม่เหมือนกันอย่างถาวรในทุกเบราว์เซอร์และบริบท

1. User-Agent คืออะไร?

มาตรา 10.1.5 ของ RFC 9110 กําหนด User-Agent เป็นฟิลด์ที่มีข้อมูลเกี่ยวกับตัวแทนผู้ใช้ที่สร้างคําขอ ไวยากรณ์แบบง่ายคือ:

User-Agent = product *( RWS ( product / comment ) )
product    = token [ "/" product-version ]

ในภาษาธรรมดา สตริงจะขึ้นต้นด้วยชื่อผลิตภัณฑ์และอาจมีเวอร์ชัน สามารถติดตามผลิตภัณฑ์หรือความคิดเห็นเพิ่มเติมได้ มาตรฐานนี้ตระหนักถึงการใช้งาน เช่น วิธีแก้ปัญหาการทํางานร่วมกัน การวินิจฉัย และการวิเคราะห์ แต่ยังแนะนําให้การใช้งานไม่เปิดเผยรายละเอียดที่ไม่จําเป็น: UA ที่ยาวขึ้นและเฉพาะเจาะจงมากขึ้นจะเพิ่มทั้งขนาดคําขอและความเสี่ยงในการพิมพ์ลายนิ้วมือ

UA เดสก์ท็อป Chromium ที่ทันสมัยอาจมีลักษณะดังนี้:

Mozilla/5.0 (Windows NT 10.0; Win64; x64)
AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/145.0.0.0 Safari/537.36

การแยกสตริงตามช่องว่างจะแสดงชื่อหลายชื่อที่ดูเหมือนไม่เกี่ยวข้องกับ Chrome:

โทเค็น	ความหมายโดยทั่วไปในปัจจุบัน	2022 การอ่านผิดที่พบบ่อย
Mozilla/5.0	โทเค็นความเข้ากันได้ในอดีต	Uka Token เบราว์เซอร์ต้องเป็น Firefox หรือผลิตภัณฑ์ Mozilla
Windows NT 10.0	หมวดหมู่แพลตฟอร์ม Windows UA ที่ลดลงไม่สามารถแยกแยะ Windows 10 จาก 11 ได้อย่างน่าเชื่อถือ คอมพิวเตอร์ต้องเรียกใช้ Windows 10
Win64; x64	เบาะแสว่านี่คือ Windows 64 บิตบนสถาปัตยกรรม x86-64	พิสูจน์ให้เห็นถึงโมเดล CPU ทางกายภาพที่แน่นอน
AppleWebKit/537.36	โทเค็นความเข้ากันได้ของเอ็นจิ้น	Synology Inc. Chrome ยังคงใช้การใช้งานที่สมบูรณ์ของ Safari
KHTML, like Gecko	ภาษาที่เข้ากันได้ในอดีต	ทั้ง KHTML และ Gecko กําลังทํางานอยู่
Chrome/145.0.0.0	ตระกูล Chrome/Chromium และรุ่นหลัก ส่วนประกอบเวอร์ชันที่ต่ํากว่าอาจลดลง	เผยให้เห็นเวอร์ชันแพตช์ที่แม่นยํา
Safari/537.36	โทเค็นที่เก็บไว้เพื่อความเข้ากันได้กับเว็บไซต์เก่า	Ukraina เบราว์เซอร์ต้องเป็น Safari

UA กลายเป็นคําฟุ่มเฟือยเนื่องจากเว็บไซต์ยุคแรก ๆ มักจะแตกแขนงตามชื่อเบราว์เซอร์ เบราว์เซอร์ใหม่ต้องอ้างสิทธิ์ความเข้ากันได้กับผลิตภัณฑ์รุ่นเก่าเพื่อรับหน้าที่ถูกต้อง การประกาศเหล่านี้สะสมเมื่อเวลาผ่านไป ทําให้เกิดบันทึกทางประวัติศาสตร์ที่ไม่สามารถอ่านได้ตามตัวอักษร

กฎข้อแรกของการแยกวิเคราะห์ UA จึงง่าย: เป็นโปรโตคอลความเข้ากันได้ ไม่ใช่คําอธิบายอุปกรณ์ที่เข้มงวด

2. ทําไมเว็บไซต์ถึงยังใช้ UA?

UA ไม่ได้ใช้สําหรับการติดตามเท่านั้น การใช้งานที่ถูกต้องตามกฎหมาย ได้แก่

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

ปัญหาเริ่มต้นเมื่อการดมกลิ่น UA เปลี่ยนจากทางเลือกที่เข้ากันได้แคบไปเป็นความสามารถในการคาดเดาตามชื่อผลิตภัณฑ์ โค้ดอาจเห็น Chrome และสมมติว่ามี API เฉพาะอยู่ สมมติฐานนั้นอาจล้มเหลวใน WebView แบบฝัง, เบราว์เซอร์ที่ได้มาจาก Chromium, เบราว์เซอร์ที่มีนโยบายองค์กร, UA ที่ค้าง หรือไคลเอ็นต์ที่เปลี่ยนส่วนหัว

ลําดับการดําเนินงานที่แข็งแกร่งยิ่งขึ้นคือ:

1. ทดสอบ API หรือพฤติกรรมที่จําเป็นโดยตรงเมื่อใดก็ตามที่สามารถตรวจจับความสามารถได้
2. เมื่อหลีกเลี่ยงการระบุเบราว์เซอร์ไม่ได้ ให้ใช้ตัวแยกวิเคราะห์ที่รักษาไว้แทนนิพจน์ทั่วไปเฉพาะกิจ
3. จัดเก็บเฉพาะหมวดหมู่หยาบที่ผลิตภัณฑ์ต้องการอย่างแท้จริง
4. จัดเตรียมทางเลือกสําหรับแบรนด์ที่ไม่รู้จัก เวอร์ชันที่ไม่รู้จัก และฟิลด์ที่ขาดหายไป

3. UA เป็นลายนิ้วมือของเบราว์เซอร์หรือไม่?

แม่นยํายิ่งขึ้น UA คือ อินพุตหนึ่งครั้งไปยังลายนิ้วมือของเบราว์เซอร์ ซึ่งโดยปกติแล้วไม่ใช่ลายนิ้วมือที่สมบูรณ์

ลายนิ้วมือของเบราว์เซอร์ไม่จําเป็นต้องมีหมายเลขซีเรียลที่เป็นความลับ มันวัดคอลเลกชันของแอตทริบิวต์ที่ค่อนข้างเสถียรและแตกต่างที่เปิดเผยโดยเบราว์เซอร์ UA ให้เบาะแสเกี่ยวกับตระกูลเบราว์เซอร์ เวอร์ชัน และแพลตฟอร์ม ขนาดหน้าจอ แบบอักษร เขตเวลา Canvas WebGL AudioContext และอินเทอร์เฟซอื่นๆ จะเพิ่มข้อมูลเพิ่มเติม

การสํารวจโดย Laperdrix และเพื่อนร่วมงาน Browser Fingerprinting: A Survey กล่าวถึงเทคนิคเหล่านี้ว่าเป็นรูปแบบหนึ่งของการรับรู้แบบไร้สัญชาติ ไซต์ไม่จําเป็นต้องเขียน Cookie ก่อน สามารถพยายามเชื่อมโยงการเข้าชมจากแอตทริบิวต์ที่เบราว์เซอร์เปิดเผย "ไร้สัญชาติ" ไม่ได้หมายความว่าเซิร์ฟเวอร์ไม่เก็บอะไรเลย หมายความว่าเนื้อหาการจดจําไม่ได้ขึ้นอยู่กับตัวระบุฝั่งไคลเอ็นต์แบบถาวร

1. ผลลัพธ์ 10 บิตของกระดาษหมายถึงอะไร?

ในการศึกษา Panopticlick ปี 2010 How Unique Is Your Web Browser? Peter Eckersley วิเคราะห์ลายนิ้วมือของเบราว์เซอร์ประมาณ 470,000 รายการ หนังสือพิมพ์รายงานว่า:

• ลายนิ้วมือที่สมบูรณ์มีค่าเฉลี่ยประมาณ 18.1 บิต ของข้อมูลระบุตัวตนในตัวอย่างนั้น
• พูดโดยสัญชาตญาณ ลายนิ้วมือโดยเฉลี่ยเกิดขึ้นประมาณหนึ่งครั้งในเบราว์เซอร์ 286,777 ตัว
• ตารางรายงานประมาณ 10.0 บิต ของข้อมูลเฉลี่ยสําหรับสตริง UA เพียงอย่างเดียว
• ในบรรดาเบราว์เซอร์ที่เปิดใช้งาน Flash หรือ Java 94.2% ของลายนิ้วมือที่สมบูรณ์นั้นไม่ซ้ํากัน

ข้อมูลตนเองมักเขียนเป็น:

I(x) = -log₂ P(x)

หาก UA ใดหนึ่งเกิดขึ้นด้วยความน่าจะเป็น 1/1024 ในประชากรการสังเกตจะให้ข้อมูล 10 บิต นี่ ไม่ได้ หมายความว่า UA มีค่าที่เป็นไปได้ 1,024 ค่า หรือระบุบุคคลที่ไม่ซ้ํากัน อธิบายว่าการสังเกตขจัดความไม่แน่นอนโดยเฉลี่ยมากน้อยเพียงใด

2. เหตุใดผลลัพธ์ในปี 2010 จึงไม่คงที่สําหรับเว็บในปัจจุบัน

ผลลัพธ์ยังคงมีความสําคัญ แต่ต้องมีคุณสมบัติอย่างน้อยสามประการ:

• ผู้เยี่ยมชมหน้าทดสอบความเป็นส่วนตัวไม่ใช่กลุ่มตัวอย่างแบบสุ่มของผู้ใช้อินเทอร์เน็ตทั้งหมด
• ความหลากหลายของเบราว์เซอร์ ปลั๊กอิน และเวอร์ชัน UA ในปี 2010 แตกต่างจากระบบนิเวศในปัจจุบันอย่างมาก
• UA Reduction พื้นผิวปลั๊กอินที่หดตัว และการป้องกันลายนิ้วมือได้เปลี่ยนการกระจายของแอตทริบิวต์ที่สังเกตได้

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

4. ทําไมการเปลี่ยนเพียง UA จึงย้อนกลับมาได้?

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

สมมติว่า UA อ้างว่าเป็นเบราว์เซอร์บนอุปกรณ์เคลื่อนที่ แต่หน้าเว็บไม่สังเกตเห็นจุดสัมผัส หน้าต่างที่คล้ายกับจอแสดงผลบนเดสก์ท็อปอย่างสม่ําเสมอ และ Client Hints ที่รายงานแพลตฟอร์มเดสก์ท็อป ข้อสังเกตใด ๆ อาจมีข้อยกเว้นที่ถูกต้องตามกฎหมาย ความขัดแย้งที่มั่นคงหลายอย่างร่วมกันยังคงสามารถสร้างรูปแบบที่จําแนกได้

เอกสารฉบับ Panopticlick ได้บันทึกกรณีที่เปรียบเทียบได้แล้ว: เบราว์เซอร์บางตัวอ้างว่าเป็น iPhone ในขณะที่รองรับ Flash และ UA Firefox บางตัวปรากฏควบคู่ไปกับคุณสมบัติการจัดเก็บข้อมูลที่มีเฉพาะใน Internet Explorer เท่านั้น การศึกษา FP-Scanner ปี 2018 ตรวจสอบปัญหานี้อย่างเป็นระบบ ส่วนขยายป้องกันลายนิ้วมือและเครื่องมือปลอมแปลงบางอย่างทําให้เกิดความไม่สอดคล้องกันระหว่างอินเทอร์เฟซ ทําให้เครื่องตรวจจับสามารถระบุแอตทริบิวต์ที่แก้ไขได้ และในบางกรณี อนุมานเบราว์เซอร์ดั้งเดิมหรือตระกูลระบบปฏิบัติการ

ไม่ใช่ทุกความไม่สอดคล้องกันที่เป็นอันตราย เดสก์ท็อประยะไกล เครื่องมือการช่วยสําหรับการเข้าถึง นโยบายองค์กร เลเยอร์ความเข้ากันได้ และฮาร์ดแวร์ที่ไม่ธรรมดา ล้วนสามารถสร้างชุดค่าผสมที่ผิดปกติได้ ระบบความเสี่ยงที่ระมัดระวังควรถือว่าความไม่สอดคล้องกันเป็นหลักฐานความน่าจะเป็น ไม่ใช่เหตุผลอัตโนมัติในการบล็อกผู้ใช้

สําหรับการจัดการโปรไฟล์เบราว์เซอร์ คุณสมบัติสามประการมีความสําคัญ:

• ความสอดคล้องภายใน: สัญญาณ UA, Client Hints, แพลตฟอร์ม, สถาปัตยกรรม, ระบบสัมผัส และหน้าจอไม่ควรขัดแย้งกันโดยตรง
• ความเสถียรเมื่อเวลาผ่านไป: โปรไฟล์ที่มีอายุการใช้งานยาวนานไม่ควรเปลี่ยนแปลงอย่างมากในทุกการเปิดตัวโดยไม่มีเหตุผล
• ความหลากหลายที่เป็นไปได้: โปรไฟล์อาจแตกต่างกัน แต่การผสมผสานที่สร้างขึ้นด้วยกลไกที่หายากไม่จําเป็นต้องปลอดภัยกว่าเสมอไป

การศึกษา FP-STALKER ยังแสดงให้เห็นว่าการเปลี่ยนแอตทริบิวต์ไม่ได้ป้องกันการเชื่อมโยงโดยอัตโนมัติ โมเดลสามารถใช้แอตทริบิวต์ที่เสถียรและการเปลี่ยนแปลงเวอร์ชันที่เป็นไปได้เพื่อเชื่อมต่อลายนิ้วมือก่อนหน้านี้และในภายหลัง

5. UA Reduction แก้ไขปัญหาอะไร?

UA แบบดั้งเดิมจะถูกส่งพร้อมกับคําขอเกือบทุกรายการ ปลายทางของบุคคลที่หนึ่งหรือบุคคลที่สามที่ได้รับคําขอสามารถอ่านได้แบบพาสซีฟ ยิ่งสตริงแม่นยํามากเท่าใด ผู้รับทุกคนก็จะได้รับข้อมูลที่แตกต่างมากขึ้นตามค่าเริ่มต้น

แผน User-Agent Reduction ของ Chromium จะลดความละเอียดเริ่มต้นนี้:

• เริ่มต้นด้วย Chrome 101 เวอร์ชันรองเดสก์ท็อป บิลด์ และแพตช์ลดลงเหลือ 0.0.0
• ระยะต่อมาเวอร์ชันระบบปฏิบัติการเดสก์ท็อปแบบรวม รายละเอียด CPU และข้อมูลอุปกรณ์ Android
• Android UA ที่ลดลงใช้ค่าแพลตฟอร์มและแบบจําลองแบบคงที่ เช่น Android 10; K
• เว็บไซต์ที่ต้องการรายละเอียดเพิ่มเติมอย่างแท้จริงสามารถขอ User-Agent Client Hints ได้

รูปแบบที่ลดลงสามารถสรุปได้ดังนี้:

Mozilla/5.0 (<unified platform information>)
AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/<major version>.0.0.0 Safari/537.36

การลดจะลดพื้นผิวการพิมพ์ลายนิ้วมือแบบพาสซีฟของ UA เดิม ไม่ได้กําจัดลายนิ้วมือของเบราว์เซอร์ เวอร์ชันหลัก แพลตฟอร์มกว้าง และสถานะมือถืออาจยังคงมองเห็นได้ ในขณะที่ API คุณสมบัติเครือข่าย และพฤติกรรมอื่นๆ ยังคงสามารถให้ข้อมูลได้

6. User-Agent Client Hints ทํางานอย่างไร?

กลไกทั่วไปถูกกําหนดไว้ใน RFC 8942 ในขณะที่ WICG User-Agent Client Hints draft อธิบายฟิลด์เฉพาะ UA วิธีการนี้แยกข้อมูลที่เคยอยู่ในสตริงที่ไม่มีโครงสร้างออกเป็นฟิลด์ที่มีโครงสร้าง โดยแยกแยะคําใบ้เอนโทรปีต่ําที่อาจส่งโดยค่าเริ่มต้นจากคําใบ้เอนโทรปีสูงที่ไซต์มักจะร้องขออย่างชัดเจน

การร้องขอเริ่มต้นแบบง่ายอาจมีลักษณะดังนี้:

GET /download HTTP/1.1
User-Agent: Mozilla/5.0 (...) Chrome/145.0.0.0 Safari/537.36
Sec-CH-UA: "Chromium";v="145", "Not_A Brand";v="99"
Sec-CH-UA-Mobile: ?0
Sec-CH-UA-Platform: "Windows"

หากเซิร์ฟเวอร์ต้องการสถาปัตยกรรมและบิตอย่างแท้จริงเพื่อเลือกตัวติดตั้ง เซิร์ฟเวอร์จะตอบสนองด้วย:

HTTP/1.1 200 OK
Accept-CH: Sec-CH-UA-Arch, Sec-CH-UA-Bitness
Vary: Sec-CH-UA-Arch, Sec-CH-UA-Bitness

เมื่อเบราว์เซอร์รองรับกลไกและตรงตามข้อกําหนดด้านความปลอดภัยและนโยบายคําขอในภายหลังอาจรวมถึง:

Sec-CH-UA-Arch: "x86"
Sec-CH-UA-Bitness: "64"

UA Client Hints ทั่วไป ได้แก่ :

สนาม	วัตถุประสงค์ทั่วไป	ระดับข้อมูล
Sec-CH-UA	รายการแบรนด์และรุ่นหลัก	โดยปกติเอนโทรปีต่ํา
Sec-CH-UA-Mobile	ลูกค้าชอบประสบการณ์มือถือหรือไม่ โดยปกติเอนโทรปีต่ํา
Sec-CH-UA-Platform	หมวดหมู่แพลตฟอร์มกว้าง	โดยปกติเอนโทรปีต่ํา
Sec-CH-UA-Arch	สถาปัตยกรรม CPU	เอนโทรปีสูง ขอเมื่อจําเป็น
Sec-CH-UA-Bitness	สถาปัตยกรรมบิตเนส	เอนโทรปีสูง ขอเมื่อจําเป็น
Sec-CH-UA-Platform-Version	เวอร์ชันแพลตฟอร์ม	เอนโทรปีสูง ขอเมื่อจําเป็น
Sec-CH-UA-Full-Version-List	เวอร์ชันเต็มสําหรับแบรนด์ที่รายงาน	2022 เอนโทรปีสูง ขอเมื่อจําเป็น
Sec-CH-UA-Model	รุ่นอุปกรณ์	เอนโทรปีสูง ขอเมื่อจําเป็น

รายละเอียดทางวิศวกรรมสามประการพลาดได้ง่าย

1. Client Hints ไม่ได้ถูกส่งโดยอัตโนมัติทั้งหมด

คําใบ้เอนโทรปีต่ําอาจปรากฏขึ้นตามค่าเริ่มต้น คําใบ้ที่มีเอนโทรปีสูงมักจะต้องการการตอบสนอง Accept-CH การนําทางเบื้องต้น ทรัพยากรย่อย นโยบายการอนุญาต การขนส่งที่ปลอดภัย และการสนับสนุนเบราว์เซอร์ ล้วนส่งผลต่อสิ่งที่มาถึง เซิร์ฟเวอร์ต้องอนุญาตให้ไม่มีฟิลด์ทางเลือกทุกช่อง

2. รายการแบรนด์จงใจทดสอบความทนทานของตัวแยกวิเคราะห์

Sec-CH-UA สามารถมีหลายยี่ห้อและยี่ห้อสังเคราะห์ที่ใช้ในการทดสอบความเข้ากันได้ รหัสต้องไม่ถือว่ารายการแรกเป็นชื่อผลิตภัณฑ์เสมอ และต้องไม่ล้มเหลวเมื่อมีแบรนด์ที่ไม่รู้จักปรากฏขึ้น แยกวิเคราะห์ฟิลด์ที่มีโครงสร้าง ละเว้นรายการที่คุณไม่รู้จัก และเว้นที่ว่างสําหรับแบรนด์ในอนาคต

3. การตอบสนองที่แตกต่างกันไปตามคําใบ้จําเป็นต้องมีการจัดการแคชที่ถูกต้อง

หากสถาปัตยกรรม แพลตฟอร์ม หรือคําใบ้อื่นเปลี่ยนการตอบสนอง ให้กําหนดค่า Vary หรือกลยุทธ์คีย์แคชที่เทียบเท่าให้ถูกต้อง มิฉะนั้น แคชที่ใช้ร่วมกันอาจแสดงเนื้อหาที่สร้างขึ้นสําหรับคลาสอุปกรณ์หนึ่งไปยังอีกคลาสหนึ่ง

7. Client Hints เป็นส่วนตัวมากกว่า UA แบบดั้งเดิมหรือไม่?

พวกเขาปรับปรุงวิธีการเปิดเผยข้อมูล แต่ไม่ได้ให้ภูมิคุ้มกันจากการพิมพ์ลายนิ้วมือ

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

อย่างไรก็ตาม สถาปัตยกรรม เวอร์ชันเต็ม เวอร์ชันแพลตฟอร์ม และรุ่นอุปกรณ์ยังคงสามารถเพิ่มความสามารถในการแยกแยะได้ RFC 8942 ถือว่าความเป็นส่วนตัวและประสิทธิภาพเป็นข้อจํากัดในการออกแบบอย่างชัดเจน นักพัฒนาควรถาม:

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

8. คําแนะนําทางวิศวกรรมสําหรับการจัดการ UA ฝั่งเซิร์ฟเวอร์

1. ห้ามใช้ UA เป็นหลักฐานยืนยันตัวตนหรืออํานาจ

UA สามารถรองรับตัวเลือกการนําเสนอและทางเลือกที่เข้ากันได้ ไม่ควรกําหนดข้อมูลประจําตัว การอนุญาต ความน่าเชื่อถือในการชําระเงิน หรือขอบเขตความปลอดภัย ค่าที่ควบคุมโดยไคลเอ็นต์ไม่สามารถทําหน้าที่เป็นข้อมูลประจําตัวของการควบคุมการเข้าถึงได้

2. ต้องการการตรวจจับความสามารถมากกว่ารายการเบราว์เซอร์

เมื่อส่วนหน้าต้องการ API ให้ทดสอบความสามารถนั้นโดยตรง:

if ('share' in navigator) {
  // Offer the system share feature.
} else {
  // Fall back to copying a link.
}

การตรวจจับความสามารถจะจัดการกับเบราว์เซอร์ที่ได้รับ คุณลักษณะการทดลอง นโยบายองค์กร และรุ่นในอนาคตได้ดีกว่ากฎ เช่น "เปิดใช้งานสิ่งนี้สําหรับ Chrome 145"

3. ยอมรับสถานะเดิม UA Client Hints และไม่รู้จัก

ในระหว่างการย้ายข้อมูล เซิร์ฟเวอร์อาจได้รับเฉพาะ UA เดิม ทั้ง UA และ Client Hints หรือทั้งสองรูปแบบที่ลดลงอย่างมาก โมเดลข้อมูลควรอนุญาตให้ unknown แทนที่จะเดาระบบปฏิบัติการหรือรุ่นอุปกรณ์ที่แน่นอนเพื่อเติมเต็มทุกฟิลด์

4. ลดความละเอียดของบันทึก

หากการวิเคราะห์ต้องการเฉพาะเดสก์ท็อปเทียบกับมือถือตระกูลเบราว์เซอร์และเวอร์ชันหลักอย่าเก็บสตริง UA ดิบและคําใบ้ที่มีเอนโทรปีสูงทั้งหมดไว้อย่างไม่มีกําหนด การลดขนาดข้อมูลช่วยลดความเสี่ยงด้านความเป็นส่วนตัวและป้องกันไม่ให้ไปป์ไลน์การวิเคราะห์ถือว่าการเปลี่ยนแปลงเล็กน้อยเป็นมิติที่มีความหมาย

5. ถือว่าความผิดปกติเป็นหลักฐาน ไม่ใช่คําตัดสิน

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

9. ควรกําหนดค่า UA ในสภาพแวดล้อมแบบหลายโปรไฟล์อย่างไร

สําหรับการทดสอบข้ามภูมิภาค การแสดงตัวอย่างโฆษณา การดําเนินการบัญชี และการแยกความเป็นส่วนตัว เป้าหมายไม่ควรเป็นการสร้าง UA ที่ผิดปกติที่สุด โปรไฟล์ควรอธิบายได้ เสถียร และเข้ากันได้กับสภาพแวดล้อมโดยรอบ

ตรวจสอบสิ่งต่อไปนี้ตามลําดับ:

1. เวอร์ชันเบราว์เซอร์: เวอร์ชันหลัก UA ควรมีความเป็นไปได้สําหรับเอ็นจิ้นจริงและความสามารถของมัน
2. ระบบปฏิบัติการ: แพลตฟอร์ม UA แพลตฟอร์ม Client Hints และหมวดหมู่แพลตฟอร์มที่มองเห็นได้ JavaScript ควรเข้ากันได้
3. สถาปัตยกรรมและบิต: UA Client Hints และสภาพแวดล้อมที่ปฏิบัติการได้ไม่ควรอ้างสิทธิ์ที่ขัดแย้งกันโดยตรง
4. ฟอร์มแฟคเตอร์ของอุปกรณ์: การประกาศบนอุปกรณ์เคลื่อนที่ควรสมเหตุสมผลควบคู่ไปกับการรองรับการสัมผัส วิวพอร์ต อัตราส่วนพิกเซล และรูปแบบการโต้ตอบ
5. บริบทภูมิภาค: ภาษา เขตเวลา ตําแหน่งทางภูมิศาสตร์ และพร็อกซีขาออกไม่จําเป็นต้องตรงกันทางกลไก แต่ควรเหมาะสมกับเวิร์กโฟลว์จริง
6. ความเสถียรของโปรไฟล์: เมื่อบัญชีหนึ่งหรือข้อมูลประจําตัวทดสอบนําโปรไฟล์ที่มีอายุการใช้งานยาวนานกลับมาใช้ใหม่ ให้หลีกเลี่ยงการเปลี่ยนแพลตฟอร์มและเวอร์ชันหลักโดยไม่มีเหตุผล

การแปลงโปรไฟล์ปัจจุบันของ PurpleMark จะแมประบบปฏิบัติการที่เลือกกับแพลตฟอร์ม UA และพยายามแยกเวอร์ชันเบราว์เซอร์จากโทเค็น Chrome/ หรือ CriOS/ ที่กําหนดค่าไว้ก่อน เมื่อไม่มีเวอร์ชันที่ใช้งานได้ จะได้ทางเลือกที่สมเหตุสมผลจากเวอร์ชันหลักของเครื่องยนต์ปัจจุบัน จุดประสงค์ไม่ใช่เพื่อปลอมแปลงสตริงที่แยกจากกัน แต่เพื่อวางการกําหนดค่า UA ภายในโมเดลโปรไฟล์เบราว์เซอร์ที่สอดคล้องกัน

การแยกโปรไฟล์และความสอดคล้องของพารามิเตอร์สามารถลดความสัมพันธ์ทางเทคนิคและอคติในการทดสอบได้ พวกเขาไม่สามารถรับประกันได้ว่าบัญชีจะไม่ถูกเชื่อมโยง และไม่ได้แทนที่กฎของแพลตฟอร์ม ข้อมูลบัญชี ข้อมูลการชําระเงิน หรือแนวทางปฏิบัติในการดําเนินงานที่มีความรับผิดชอบ ใช้ความสามารถเหล่านี้เพื่อการปกป้องความเป็นส่วนตัวที่ถูกต้องตามกฎหมาย การทดสอบที่ได้รับอนุญาต และกิจกรรมทางธุรกิจที่เป็นไปตามข้อกําหนดเท่านั้น

10. คําถามที่พบบ่อย

Q1: การเปลี่ยน UA เปลี่ยนเบราว์เซอร์เป็นเบราว์เซอร์อื่นหรือไม่?

ไม่ มันเปลี่ยนส่วนหนึ่งของสิ่งที่ลูกค้าประกาศ ไม่ได้แทนที่เอ็นจิ้น JavaScript ไปป์ไลน์การเรนเดอร์ สแต็กเครือข่าย หรือ Web API ที่รองรับ

Q2: เว็บไซต์สามารถอ่าน "UA จริง" ได้หรือไม่?

ไม่มี "UA จริง" ระดับฮาร์ดแวร์สากลที่ทุกเว็บไซต์สามารถเลี่ยงเบราว์เซอร์เพื่ออ่านได้ อย่างไรก็ตาม ไซต์สามารถเปรียบเทียบ Client Hints การทดสอบความสามารถ และสัญญาณลายนิ้วมืออื่นๆ ค้นหาการอ้างสิทธิ์ที่เข้ากันไม่ได้ และทําการอนุมานความน่าจะเป็น

Q3: UA ที่ลดลงสามารถแยกแยะ Windows 10 จาก Windows 11 ได้หรือไม่?

โดยปกติ UA มรดกที่ลดลงไม่สามารถทําได้อย่างน่าเชื่อถือเนื่องจากทั้งคู่อาจรายงาน Windows NT 10.0 เบราว์เซอร์ที่รองรับ UA Client Hints อาจให้ข้อมูลเวอร์ชันแพลตฟอร์มโดยละเอียดมากขึ้นหลังจากที่ไซต์ร้องขอ เซิร์ฟเวอร์ยังคงต้องจัดการฟิลด์ที่ขาดหายไปและความแตกต่างของการแมป

Q4: การปิดใช้งาน JavaScript หยุดการเปิดรับแสง UA หรือไม่

ไม่สมบูรณ์ HTTP User-Agent เป็นส่วนหัวของคําขอและสามารถส่งพร้อมกับคําขอหน้าเว็บก่อนที่ JavaScript หน้าจะทํางาน การปิดใช้งาน JavaScript จะลบพื้นผิวคอลเลกชันบางส่วน แต่ยังทําลายส่วนสําคัญของเว็บสมัยใหม่ด้วย

Q5: Client Hints จะแทนที่ User-Agent ทั้งหมดหรือไม่?

อย่าคิดว่าในระยะใกล้ ไคลเอนต์และเซิร์ฟเวอร์จํานวนมากยังคงขึ้นอยู่กับ UA เดิม ในขณะที่การสนับสนุน UA Client Hints แตกต่างกันไป ปฏิบัติต่อ Client Hints เป็นการปรับปรุงแบบก้าวหน้า: เลือกข้อมูลที่มีโครงสร้างเมื่อมี แต่คงไว้สําหรับ UA เดิมและสถานะที่ไม่รู้จัก

Q6: UA ที่สร้างขึ้นแบบสุ่มช่วยปรับปรุงการไม่เปิดเผยตัวตนหรือไม่?

ไม่จําเป็น. การสุ่มฟิลด์หนึ่งฟิลด์สามารถสร้างความขัดแย้งกับเวอร์ชัน แพลตฟอร์ม การสัมผัส และสัญญาณการแสดงผล สําหรับโปรไฟล์ที่มีอายุการใช้งานยาวนานการกําหนดค่าทั่วไปที่เสถียรและเข้ากันได้ภายในมักจะป้องกันได้มากกว่าการเปลี่ยนแปลงแบบสุ่มบ่อยครั้ง

11. สรุป

User-Agent ไม่ใช่ข้อมูลประจําตัวที่น่าเชื่อถือหรือสตริงที่ไม่เกี่ยวข้อง ตั้งอยู่ที่จุดตัดของความเข้ากันได้ของเว็บ ความเป็นส่วนตัว และการวิเคราะห์ความเสี่ยง สําหรับนักพัฒนา มันเป็นอินพุตความเข้ากันได้ที่มีภาระจากประวัติ สําหรับนักวิจัยการพิมพ์ลายนิ้วมือ เป็นคุณลักษณะที่มีข้อมูลทางสถิติที่วัดได้ สําหรับผู้จําหน่ายเบราว์เซอร์ เป็นพื้นผิวการเปิดรับแสงเริ่มต้นที่ต้องลดลง

แนวคิดหลักประกอบด้วยสามข้อความ:

• อย่าอ่าน UA ตามตัวอักษร มีโทเค็นความเข้ากันได้ในอดีตมากมาย
• อย่าประเมิน UA แยกจากกัน การรับรู้ในทางปฏิบัติมาจากการรวมกันของสัญญาณและวิวัฒนาการเมื่อเวลาผ่านไป
• อย่าคิดว่า Client Hints เป็นเพียง "ทุ่ง UA มากขึ้น" คุณค่าของพวกเขาอยู่ที่การเปิดเผยข้อมูลที่มีโครงสร้าง ขับเคลื่อนด้วยคําขอ และควบคุมได้

เมื่อระบบเปลี่ยนจากการระบุชื่อเบราว์เซอร์ไปสู่การทดสอบความสามารถที่ต้องการ และจากการรวบรวมรายละเอียดทั้งหมดที่มีอยู่ไปสู่การร้องขอเฉพาะสิ่งที่จําเป็น UA จะกลับสู่บทบาทที่เหมาะสม นั่นคือเบาะแสความเข้ากันได้ ไม่ใช่ความจริงของตัวตน

ข้อมูลอ้างอิงและมาตรฐาน

1. Peter Eckersley. How Unique Is Your Web Browser?. Privacy Enhancing Technologies Symposium, 2010.
2. Pierre Laperdrix, Nataliia Bielova, Benoit Baudry, Gildas Avoine. Browser Fingerprinting: A Survey. ACM Transactions on the Web, 2020.
3. Antoine Vastel, Pierre Laperdrix, Walter Rudametkin, Romain Rouvoy. FP-Scanner: The Privacy Implications of Browser Fingerprint Inconsistencies. USENIX Security Symposium, 2018.
4. Antoine Vastel, Pierre Laperdrix, Walter Rudametkin, Romain Rouvoy. FP-STALKER: Tracking Browser Fingerprint Evolutions. IEEE Symposium on Security and Privacy, 2018.
5. IETF. RFC 9110: HTTP Semantics, 2022.
6. IETF. RFC 8942: HTTP Client Hints, 2021.
7. WICG. User-Agent Client Hints, Draft Community Group Report.
8. Chromium. User-Agent Reduction.
9. Chrome for Developers. Improve user privacy and developer experience with User-Agent Client Hints.