การลด 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 และกลไกอื่นๆ ได้ดีขึ้น

Why do we need reduced UA and 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 Client Hints มาจากแหล่งที่มาเดียวกัน ดังนั้นรูปแบบตรรกะเดียวกันจึงควรใช้งานได้

เช่น หากเลือกรูปแบบนี้ในสตริง 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

สําหรับ Use Case ที่เจาะจงฮาร์ดแวร์ คุณสามารถขอชื่อรุ่นอุปกรณ์ผ่านคำแนะนำ Sec-CH-UA-Model ที่มีแฮชสูง

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

BoringSSL (ซึ่งเป็นเวอร์ชันแยกของ 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 หรือไม่

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

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