User-Agent (UA) ช่วยลดข้อมูลระบุตัวตนที่แชร์ในสตริง User-Agent ซึ่งอาจใช้สำหรับการทำลายนิ้วมือแบบแพสซีฟ เมื่อเปิดตัวการเปลี่ยนแปลงเหล่านี้สำหรับเวอร์ชันสำหรับผู้ใช้ทั่วไปแล้ว คำขอทรัพยากรทั้งหมดจะมีส่วนหัว User-Agent
ที่ลดลง ด้วยเหตุนี้ ค่าที่แสดงผลจากอินเทอร์เฟซ Navigator
บางรายการจึงลดลง ซึ่งรวมถึง navigator.userAgent
, navigator.appVersion
และ navigator.platform
นักพัฒนาเว็บควรตรวจสอบโค้ดของเว็บไซต์เพื่อใช้งานสตริง User-Agent หากเว็บไซต์ใช้การแยกวิเคราะห์สตริง User-Agent เพื่ออ่านรุ่นอุปกรณ์ เวอร์ชันแพลตฟอร์ม หรือเวอร์ชันเบราว์เซอร์แบบเต็ม คุณจะต้องใช้ User-Agent Client Hints API
คำแนะนำสำหรับไคลเอ็นต์ 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
ลงในแถบที่อยู่
เบราว์เซอร์จะส่งคำขอโหลดหน้าเว็บ
- เบราว์เซอร์มีส่วนหัว
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
เบราว์เซอร์มีข้อมูลเดียวกันนี้ในส่วนหัวคำแนะนำไคลเอ็นต์ User-Agent เริ่มต้น เช่น
Sec-CH-UA: "Chrome"; v="98" Sec-CH-UA-Mobile: ?1 Sec-CH-UA-Platform: "Android"
- เบราว์เซอร์มีส่วนหัว
เซิร์ฟเวอร์ขอให้เบราว์เซอร์ส่งคําแนะนําเกี่ยวกับไคลเอ็นต์เพิ่มเติม เช่น รุ่นอุปกรณ์ ที่มีส่วนหัวการตอบกลับ
Accept-CH
ได้ ตัวอย่างเช่นAccept-CH: Sec-CH-UA, Sec-CH-UA-Mobile, Sec-CH-UA-Platform, Sec-CH-UA-Model
เบราว์เซอร์จะใช้นโยบายและการกำหนดค่าของผู้ใช้เพื่อกำหนดข้อมูลที่ได้รับอนุญาตให้กลับไปยังเซิร์ฟเวอร์ในส่วนหัวของคำขอที่ตามมา เช่น
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
สำหรับกรณีการใช้งานเฉพาะฮาร์ดแวร์ คุณขอชื่อรุ่นอุปกรณ์ได้ผ่านคำแนะนำ 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"
ดูข้อมูลเพิ่มเติมเกี่ยวกับแฟล็กบรรทัดคำสั่งที่นี่
หรือใช้โปรแกรมจำลองอุปกรณ์ใน Chrome DevTools
แปลงสตริงในโค้ดของเว็บไซต์
หากประมวลผลสตริง user-agent
ของ Chrome ที่มีอยู่ในโค้ดฝั่งไคลเอ็นต์หรือฝั่งเซิร์ฟเวอร์ คุณจะเปลี่ยนสตริงนั้นเป็นรูปแบบใหม่เพื่อทดสอบความเข้ากันได้ ซึ่งคุณจะทดสอบได้โดยการลบล้างและแทนที่สตริง หรือสร้างเวอร์ชันใหม่แล้วทดสอบควบคู่กัน
การสนับสนุนสำหรับเคล็ดลับไคลเอ็นต์และคำแนะนำที่สำคัญ
มีคำแนะนำไคลเอ็นต์เริ่มต้น 3 รายการที่ส่งคืนไปยังเซิร์ฟเวอร์ ซึ่งได้แก่ ชื่อเบราว์เซอร์และเวอร์ชันหลัก บูลีนที่ระบุว่าเบราว์เซอร์อยู่บนอุปกรณ์เคลื่อนที่หรือไม่ รวมถึงชื่อระบบปฏิบัติการ ซึ่งจะส่งหลังจากแฮนด์เชคโปรโตคอล Transport Layer Security (TLS) ซึ่งส่วนขยายเหล่านี้มีอยู่แล้ว และรองรับในเบราว์เซอร์ของคุณแล้ว
อย่างไรก็ตาม อาจมีบางครั้งที่คุณต้องการดึงข้อมูลสำคัญเพื่อให้เว็บไซต์แสดงผล
เพิ่มประสิทธิภาพคำแนะนำสำคัญ
แฮนด์เชค TLS เป็นขั้นตอนแรกในการสร้างการเชื่อมต่อที่ปลอดภัยระหว่างเบราว์เซอร์กับเว็บเซิร์ฟเวอร์ หากไม่มีการแทรกแซง เราออกแบบส่วนหัวการตอบกลับ Critical-CH ให้บอกเบราว์เซอร์ให้ลองส่งคำขออีกครั้งทันทีหากมีการส่งคำขอแรกโดยไม่มีคำแนะนำที่สำคัญ
หากต้องการเพิ่มประสิทธิภาพคำแนะนำที่สำคัญ (ส่วนหัว Critical-CH
)
คุณต้องสกัดกั้นแฮนด์เชคนี้ และระบุโมเดลสำหรับ Client Hints ขั้นตอนเหล่านี้อาจซับซ้อนและต้องอาศัยความรู้ขั้นสูง
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 หรือไม่
มีส่วนร่วมและแชร์ความคิดเห็น
- ช่วงทดลองใช้จากต้นทาง: แชร์ความคิดเห็นเกี่ยวกับช่วงทดลองใช้จากต้นทางที่ผ่านมา
- การสาธิต: ลองใช้การสาธิตการลด User-Agent
- GitHub: อ่านคำอธิบาย UA-CH ถามคำถามและติดตามการสนทนา
- การสนับสนุนนักพัฒนาแอป: ถามคำถามและเข้าร่วมการสนทนาเกี่ยวกับที่เก็บการสนับสนุนนักพัฒนาแอป Privacy Sandbox
ดูข้อมูลเพิ่มเติม
- การปรับปรุงความเป็นส่วนตัวของผู้ใช้และประสบการณ์ของนักพัฒนาซอฟต์แวร์: ภาพรวมสำหรับนักพัฒนาเว็บ
- ย้ายข้อมูลจากสตริง UA ไปยัง UA-CH: บทแนะนำสำหรับนักพัฒนาเว็บ
- เจาะลึกข้อมูลเกี่ยวกับ Privacy Sandbox