การลด User Agent คืออะไร

การลด User Agent (UA) จะลดข้อมูลระบุตัวตนที่แชร์ในสตริง User Agent ซึ่งอาจใช้สำหรับการสร้างลายนิ้วมือแบบพาสซีฟ ตอนนี้การเปลี่ยนแปลงเหล่านี้พร้อมให้บริการแก่ผู้ใช้ทั่วไปแล้ว คำขอทรัพยากรทั้งหมดจึงมีส่วนหัว User-Agent ที่ลดลง ด้วยเหตุนี้ ค่าที่ส่งคืนจากอินเทอร์เฟซ Navigator บางรายการจึงลดลง ซึ่งรวมถึง navigator.userAgent, navigator.appVersion และ navigator.platform

นักพัฒนาเว็บควรตรวจสอบโค้ดของเว็บไซต์เพื่อดูการใช้งานสตริง User-Agent หากเว็บไซต์ของคุณอาศัยการแยกวิเคราะห์สตริง User-Agent เพื่ออ่านรุ่นอุปกรณ์ เวอร์ชันแพลตฟอร์ม หรือเวอร์ชันเบราว์เซอร์แบบเต็ม คุณจะต้องใช้ API ของคำแนะนำสำหรับไคลเอ็นต์ของ User-Agent

คำแนะนำสำหรับไคลเอ็นต์ User Agent (UA-CH)

คำแนะนำไคลเอ็นต์ User-Agent อนุญาตให้เข้าถึง ชุดข้อมูล User-Agent ทั้งหมด แต่เฉพาะในกรณีที่เซิร์ฟเวอร์ประกาศอย่างชัดเจนว่า ต้องการข้อมูลบางอย่างโดยเฉพาะ

การนำข้อมูลผู้ใช้ที่เปิดเผยโดยไม่ได้ตั้งใจออกจะช่วยให้เราวัดและลดปริมาณข้อมูลที่เปิดเผยโดยเจตนาผ่านส่วนหัวของคำขอ, JavaScript API และกลไกอื่นๆ ได้ดีขึ้น

เหตุใดเราจึงต้องลด UA และ UA-CH

ในอดีต สตริง User-Agent จะออกอากาศสตริงข้อมูลขนาดใหญ่เกี่ยวกับเบราว์เซอร์ ระบบปฏิบัติการ และเวอร์ชันของผู้ใช้ทุกครั้งที่มีคำขอ HTTP ซึ่งเป็นปัญหาด้วยเหตุผล 2 ประการ ดังนี้

  • ความละเอียดและรายละเอียดที่มากเกินไปอาจนำไปสู่การระบุตัวตนของผู้ใช้ได้
  • ความพร้อมใช้งานของข้อมูลนี้โดยค่าเริ่มต้นอาจนำไปสู่การติดตามอย่างลับๆ

UA และ UA-CH ที่ลดลงช่วยปรับปรุงความเป็นส่วนตัวของผู้ใช้ด้วยการแชร์เฉพาะข้อมูลพื้นฐานโดยค่าเริ่มต้น

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

นอกจากนี้ เมื่อเวลาผ่านไป สตริง User-Agent ก็ยาวขึ้นและซับซ้อนมากขึ้น ซึ่งทำให้การแยกวิเคราะห์สตริงมีแนวโน้มที่จะเกิดข้อผิดพลาด UA-CH ให้ข้อมูลที่มีโครงสร้างและเชื่อถือได้ ซึ่งตีความได้ง่ายกว่า โค้ดที่มีอยู่ซึ่งแยกวิเคราะห์สตริง UA ไม่ควร หยุดทำงาน (แม้ว่าจะแสดงข้อมูลน้อยลง) และคุณจะต้องย้ายข้อมูลไปยัง UA-CH หากเว็บไซต์ต้องการข้อมูลไคลเอ็นต์ที่เฉพาะเจาะจง

UA และ UA-CH ที่ลดลงทำงานอย่างไร

ต่อไปนี้เป็นตัวอย่างสั้นๆ เกี่ยวกับวิธีการทำงานของสตริง User-Agent ที่ลดลงและ UA-CH ดูตัวอย่างแบบเจาะลึกเพิ่มเติมได้ที่การปรับปรุงความเป็นส่วนตัวของผู้ใช้และประสบการณ์ของนักพัฒนาแอปด้วยคำแนะนำสำหรับไคลเอ็นต์ของ User Agent

ผู้ใช้เปิดเบราว์เซอร์และป้อน example.com ในแถบที่อยู่

  1. เบราว์เซอร์จะส่งคำขอเพื่อโหลดหน้าเว็บ

    1. เบราว์เซอร์จะรวมส่วนหัว User-Agent ไว้กับสตริง User Agent ที่ลดลง เช่น User-Agent: Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.0.0 Mobile Safari/537.36

    2. เบราว์เซอร์จะรวมข้อมูลเดียวกันนั้นไว้ในส่วนหัวคำแนะนำไคลเอ็นต์ User-Agent เริ่มต้น เช่น

      Sec-CH-UA: "Chrome"; v="98"
Sec-CH-UA-Mobile: ?1
Sec-CH-UA-Platform: "Android"

  2. เซิร์ฟเวอร์สามารถขอให้เบราว์เซอร์ส่งคำแนะนำไคลเอ็นต์เพิ่มเติม เช่น รุ่นอุปกรณ์ โดยใช้ส่วนหัวการตอบกลับ Accept-CH เช่น Accept-CH: Sec-CH-UA, Sec-CH-UA-Mobile, Sec-CH-UA-Platform, Sec-CH-UA-Model

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

    Sec-CH-UA: "Chrome"; v="93"
Sec-CH-UA-Mobile: ?1
Sec-CH-UA-Platform: "Android"
Sec-CH-UA-Model: "Pixel 2"

คำแนะนำสำหรับไคลเอ็นต์ที่สำคัญ

หากต้องการชุดคำแนะนำไคลเอ็นต์ที่เฉพาะเจาะจงในคำขอเริ่มต้น คุณสามารถใช้ส่วนหัวการตอบกลับ Critical-CH ได้ ค่า Critical-CH ต้องเป็นชุดย่อยของค่าที่ Accept-CH ร้องขอ

เช่น คำขอเริ่มต้นอาจรวมคำขอสำหรับ Device-Memory และ Viewport-Width โดยระบบจะถือว่า Device-Memory มีความสำคัญ

GET / HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
Content-Type: text/html
Accept-CH: Device-Memory, Viewport-Width
Vary: Device-Memory, Viewport-Width
Critical-CH: Device-Memory

หากเบราว์เซอร์ต้องการคำแนะนำที่สำคัญ (Critical-CH) เพื่อแสดงหน้าเว็บอย่างถูกต้อง เซิร์ฟเวอร์จะขอข้อมูลเพิ่มเติมนี้ได้โดยใช้ส่วนหัว Accept-CH จากนั้นเบราว์เซอร์จะส่งคำขอใหม่สำหรับหน้าเว็บ รวมถึงคำแนะนำที่สำคัญได้

กล่าวโดยสรุปคือ Accept-CH จะขอค่าทั้งหมดที่คุณต้องการสำหรับหน้าเว็บ ส่วน Critical-CH จะขอเฉพาะค่าที่จำเป็นต้องมีเมื่อโหลดเพื่อโหลดหน้าเว็บอย่างถูกต้อง โปรดดูข้อมูลเพิ่มเติมในข้อกำหนดความน่าเชื่อถือของคำแนะนำไคลเอ็นต์

ตรวจหาอุปกรณ์แท็บเล็ตด้วย UA-CH API

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

อย่างไรก็ตาม ข้อมูลที่เบราว์เซอร์ระบุสำหรับทั้งสตริง User-Agent และคำแนะนำสำหรับไคลเอ็นต์ User-Agent มาจากแหล่งที่มาเดียวกัน ดังนั้นตรรกะในรูปแบบเดียวกัน จึงควรใช้งานได้

เช่น หากเลือกรูปแบบนี้ในสตริง UA

  • รูปแบบโทรศัพท์: 'Android' + 'Chrome/[.0-9]* Mobile'
  • รูปแบบแท็บเล็ต: 'Android' + 'Chrome/[.0-9]* (?!Mobile)'

คุณอาจตรวจสอบอินเทอร์เฟซส่วนหัว UA-CH เริ่มต้นที่ตรงกันได้ดังนี้

  • รูปแบบโทรศัพท์: Sec-CH-UA-Platform: "Android", Sec-CH-UA-Mobile: ?1
  • รูปแบบแท็บเล็ต: Sec-CH-UA-Platform: "Android", Sec-CH-UA-Mobile: ?0

หรืออินเทอร์เฟซ JavaScript ที่เทียบเท่า

  • รูปแบบโทรศัพท์: navigator.userAgentData.platform === 'Android' && navigator.userAgentData.mobile === true
  • รูปแบบแท็บเล็ต: navigator.userAgentData.platform === 'Android' && navigator.userAgentData.mobile === false

สําหรับกรณีการใช้งานเฉพาะฮาร์ดแวร์ คุณขอชื่อรุ่นอุปกรณ์ได้ผ่านคำแนะนำSec-CH-UA-Modelที่มีเอนโทรปีสูง

ฉันจะใช้และทดสอบ UA ที่ลดลงได้อย่างไร

เริ่มต้นด้วยตรวจสอบโค้ดของเว็บไซต์ เพื่อดูอินสแตนซ์และการใช้งานสตริง User-Agent หากเว็บไซต์ของคุณอาศัยการแยกวิเคราะห์สตริง User-Agent เพื่ออ่านรุ่นอุปกรณ์ เวอร์ชันแพลตฟอร์ม หรือเวอร์ชันเบราว์เซอร์แบบเต็ม คุณจะต้องใช้ API ของ UA-CH

เมื่ออัปเดตเป็น UA-CH API แล้ว คุณควรทดสอบเพื่อให้แน่ใจว่าได้รับข้อมูลที่คาดไว้จาก User-Agent การทดสอบมี 3 วิธี โดยแต่ละวิธีจะมีความซับซ้อนเพิ่มขึ้น

ความพร้อมใช้งานที่ปรับขนาดสำหรับการลด User-Agent หมายถึงสตริง UA ที่ลดลงอย่างสมบูรณ์ ซึ่งจัดส่งในอุปกรณ์ Chrome ทั้งหมด การลดขนาดเริ่มขึ้นพร้อมกับการเผยแพร่ Chrome เวอร์ชันย่อยในไตรมาสที่ 2 ปี 2022

ทดสอบสตริงที่กำหนดเองในเครื่อง

หากต้องการทดสอบเว็บไซต์โดยใช้สตริง User-Agent ที่กำหนดเองเพื่อจำลอง อุปกรณ์ต่างๆ ให้เปิด Chrome ด้วย --user-agent="Custom string here"แฟล็กบรรทัดคำสั่ง ดูข้อมูลเพิ่มเติมเกี่ยวกับ แฟล็กบรรทัดคำสั่งได้ที่นี่

หรือจะใช้โปรแกรมจำลองอุปกรณ์ในเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome ก็ได้

แปลงสตริงในโค้ดของเว็บไซต์

หากคุณประมวลผลสตริง user-agent ของ Chrome ที่มีอยู่แล้วในโค้ดฝั่งไคลเอ็นต์หรือฝั่งเซิร์ฟเวอร์ คุณสามารถแปลงสตริงนั้นเป็นรูปแบบใหม่เพื่อทดสอบความเข้ากันได้ คุณสามารถทดสอบได้โดยการลบล้างและแทนที่สตริง หรือ สร้างเวอร์ชันใหม่และทดสอบควบคู่กันไป

การรองรับคำแนะนำไคลเอ็นต์และคำแนะนำที่สำคัญ

มี Client Hints เริ่มต้น 3 รายการ ที่ส่งคืนไปยังเซิร์ฟเวอร์ ได้แก่ ชื่อเบราว์เซอร์และเวอร์ชันหลัก บูลีน ที่ระบุว่าเบราว์เซอร์อยู่ในอุปกรณ์เคลื่อนที่หรือไม่ และชื่อระบบปฏิบัติการ โดยจะส่งหลังจากแฮนด์เชคโปรโตคอล Transport Layer Security (TLS) ซึ่งพร้อมใช้งานและ รองรับในเบราว์เซอร์ของคุณอยู่แล้ว

อย่างไรก็ตาม อาจมีบางครั้งที่คุณต้องดึงข้อมูลสำคัญเพื่อให้เว็บไซต์แสดงผล

เพิ่มประสิทธิภาพคำแนะนำที่สำคัญ

แฮนด์เชคของ TLS เป็นขั้นตอนแรกในการสร้าง การเชื่อมต่อที่ปลอดภัยระหว่างเบราว์เซอร์กับเว็บเซิร์ฟเวอร์ ส่วนหัวการตอบกลับ Critical-CH ได้รับการออกแบบมาเพื่อบอกเบราว์เซอร์ให้ลองส่งคำขออีกครั้งทันทีหากคำขอแรก ถูกส่งโดยไม่มีคำแนะนำที่สำคัญ

แผนภาพลำดับสำหรับ Client Hints ที่มีคำแนะนำที่สำคัญ
เมื่อเซิร์ฟเวอร์ขอคำแนะนำที่สำคัญ ไคลเอ็นต์จะลองส่งคำขอแรกสำหรับหน้าเว็บที่มีคำแนะนำที่สำคัญอีกครั้ง ในตัวอย่างนี้ มีการขอคำแนะนำสำหรับ Sec-CH-UA-Model 2 ครั้ง ครั้งแรกเป็นคำแนะนำไคลเอ็นต์ที่มี Accept-CH และอีกครั้งเป็นคำแนะนำที่สำคัญที่มี Critical-CH

หากต้องการเพิ่มประสิทธิภาพคำแนะนำที่สำคัญ (ส่วนหัว Critical-CH) คุณต้องสกัดกั้นการแฮนด์เชคนี้และระบุโมเดลสำหรับคำแนะนำไคลเอ็นต์ ขั้นตอนเหล่านี้อาจซับซ้อนและต้องใช้ความรู้ขั้นสูง

ACCEPT_CHเฟรม HTTP/2 และ HTTP/3 รวมกับส่วนขยาย TLS ALPS เป็นการเพิ่มประสิทธิภาพระดับการเชื่อมต่อเพื่อส่งค่ากำหนด Client Hint ของเซิร์ฟเวอร์ ให้ทันคำขอ HTTP แรก ซึ่งต้องมีการกำหนดค่าที่ซับซ้อน และเราขอแนะนำให้ใช้การกำหนดค่านี้กับข้อมูลที่สำคัญจริงๆ เท่านั้น

BoringSSL (ซึ่งเป็น Fork ของ OpenSSL) ช่วยให้คุณทำงานกับฟีเจอร์ทดลองของ Google ใน Chromium ได้ ปัจจุบัน ALPS ใช้งานได้ใน BoringSSL เท่านั้น

หากต้องการใช้คำแนะนำที่สำคัญ โปรดดูคำแนะนำเกี่ยวกับ ความน่าเชื่อถือและการเพิ่มประสิทธิภาพของคำแนะนำที่สำคัญ

คำถามที่พบบ่อย

ระบบจะส่งคำแนะนำที่ระบุผ่านส่วนหัว Accept-CH นานเท่าใด

ระบบจะส่งคำแนะนำที่ระบุผ่านส่วนหัว Accept-CH เป็นระยะเวลาของเซสชันเบราว์เซอร์หรือจนกว่าจะมีการระบุชุดคำแนะนำอื่น

UA-CH ใช้ได้กับ HTTP/2 และ HTTP/3 ไหม

UA-CH ใช้ได้กับการเชื่อมต่อทั้ง HTTP/2 และ HTTP/3

โดเมนย่อย (และ CNAME) ต้องมีหน้าเว็บระดับบนสุด Permissions-Policy เพื่อเข้าถึง UA-CH ที่มีเอนโทรปีสูงไหม

ระบบจะจํากัด UA-CH ที่มีเอนโทรปีสูงในส่วนหัวของคําขอสําหรับคําขอแบบข้ามต้นทาง โดยไม่คํานึงถึงวิธีที่กําหนดต้นทางนั้นในฝั่ง DNS การมอบสิทธิ์ต้อง จัดการผ่าน Permissions-Policy สำหรับทรัพยากรย่อยแบบข้ามต้นทาง หรือรับผ่าน JavaScript ที่เรียกใช้ในบริบทแบบข้ามต้นทาง

การลด User-Agent ส่งผลต่อการตรวจหาบอทอย่างไร

การเปลี่ยนแปลงสตริง User-Agent ของ Chrome ไม่ส่งผลโดยตรงต่อสตริง User-Agent ที่บ็อตเลือกส่ง

บ็อตอาจเลือกที่จะอัปเดตสตริงของตนเองเพื่อให้สอดคล้องกับข้อมูลที่ Chrome ส่ง แต่การเลือกใช้ดังกล่าวขึ้นอยู่กับการตัดสินใจของบ็อตเอง Chrome ยังคงส่งรูปแบบ User-Agent เดียวกัน และบ็อต ที่ต่อท้ายตัวระบุของตนเองไว้ท้ายสตริง User-Agent ของ Chrome จะยังคงทำเช่นนั้นได้

หากมีข้อกังวลเกี่ยวกับบอทที่เฉพาะเจาะจง คุณอาจต้องติดต่อเจ้าของโดยตรงเพื่อสอบถามว่ามีแผนที่จะเปลี่ยนสตริง User-Agent หรือไม่

มีส่วนร่วมและแชร์ความคิดเห็น

ดูข้อมูลเพิ่มเติม