เบราว์เซอร์ฟิงเกอร์ปรินต์

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

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

เหตุใดการเก็บลายนิ้วมือจึงขัดขวางความเป็นส่วนตัวของผู้ใช้

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

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

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

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

ควรทำ

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

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

วิธีการทํางานของลายนิ้วมือ

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

หมายเหตุ: การพิมพ์ลายนิ้วมือแบบแอบแฝงและแบบแอ็กทีฟ

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

สิ่งที่ไม่ควรทำ: การวัดความสามารถในการลายนิ้วมือ

การวัดทางเทคนิคสำหรับปริมาณข้อมูลที่จุดข้อมูลเหล่านี้ให้แต่ละจุดเรียกว่าเอนโทรปี และมีการวัดเป็นหน่วยบิต ฟีเจอร์ซึ่งมีค่าที่เป็นไปได้หลายแบบ (เช่น รายการแบบอักษรที่ติดตั้งไว้) อาจมีส่วนในการสร้างบิตจำนวนมาก โดยรวม แม้ว่าบางอย่างที่ไม่มีประสิทธิภาพในการแยกความแตกต่างมากนัก (เช่น ระบบปฏิบัติการที่คุณใช้อยู่) อาจเพิ่มเพียงแค่ ไม่กี่รายการ HTTP Almanac จะอธิบายว่าการเก็บลายนิ้วมือที่มีอยู่ได้อย่างไร ไลบรารีจะดำเนินการเป็นระบบอัตโนมัติในการรวมการตอบกลับจาก API ต่างๆ จำนวนมากไว้ใน "แฮช" ซึ่งอาจระบุเฉพาะ ผู้ใช้กลุ่มเล็กๆ หรืออาจแค่กลุ่มเดียว Maud Nalpas กล่าวถึงเรื่องนี้อย่างละเอียดใน วิดีโอ YouTube นี้ แต่กล่าวสั้นๆ ก็คือ สมมติว่าคุณได้เห็น รายชื่อเพื่อนของคุณพร้อมเพลงโปรด อาหารโปรด และภาษาที่พวกเขาพูด... แต่มีชื่อของพวกเขา ลบแล้ว รายการของบุคคลใดบุคคลหนึ่งมีแนวโน้มที่จะระบุตัวบุคคลนั้นๆ ได้อย่างไม่ซ้ำกันท่ามกลางเพื่อนของคุณ หรืออย่างน้อยก็ช่วยจำกัดรายการให้เหลือเพียงไม่กี่คน นี่คือวิธีการทํางานของลายนิ้วมือ รายการสิ่งที่คุณชอบจะกลายเป็น "แฮช" การใช้แฮชดังกล่าวช่วยให้การระบุผู้ใช้ว่าเป็นบุคคลเดียวกันในเว็บไซต์ 2 แห่งที่ไม่เกี่ยวข้องกันง่ายขึ้น ซึ่งเป็นเป้าหมายของการติดตามเพื่อหลีกเลี่ยงความต้องการของผู้ใช้ในเรื่องความเป็นส่วนตัว

เบราว์เซอร์ใช้มาตรการใดบ้างเพื่อป้องกันการระบุตัวตน

ที่สำคัญ ผู้ให้บริการเบราว์เซอร์ทราบถึงวิธีการต่างๆ ที่หลากหลายสำหรับเว็บไซต์ (หรือบุคคลที่สามที่รวมอยู่ในเว็บไซต์) เพื่อคำนวณลายนิ้วมือที่ไม่ซ้ำกันสำหรับผู้ใช้ หรือสำหรับบิตข้อมูลต่างๆ ที่นำมาสร้างความแตกต่างให้กับความแตกต่างดังกล่าว ของลายนิ้วมือนั้น วิธีการบางอย่างเหล่านี้จะระบุอย่างชัดเจนและจงใจ เช่น สตริง User Agent ของเบราว์เซอร์ ซึ่งมักจะระบุเบราว์เซอร์ ระบบปฏิบัติการ และเวอร์ชันที่ใช้อยู่ (จึงช่วยแยกความแตกต่างระหว่างคุณกับเราในกรณีที่คุณและเราใช้เบราว์เซอร์คนละรุ่นกัน) บางวิธีไม่ได้จงใจสร้างขึ้นมาเพื่อลายนิ้วมือแต่กลับกลายเป็นได้ เช่น รายการแบบอักษร หรืออุปกรณ์วิดีโอและเสียงที่มีในเบราว์เซอร์ (เบราว์เซอร์ไม่จําเป็นต้องใช้ ให้ดูรายชื่ออุปกรณ์เหล่านั้นตามชื่อ) และบางคนก็สร้างขึ้นเพื่อเป็นผู้ร่วมให้ข้อมูลสำหรับลายนิ้วมือ หลังการเปิดตัว เช่น การแสดงภาพพิกเซลจริงของการลบรอยหยักของแบบอักษรในองค์ประกอบ Canvas ยังมีอีกหลายวิธี และความแตกต่างแต่ละอย่างของเบราว์เซอร์คุณกับเบราว์เซอร์ของฉันจะเพิ่มข้อมูลความผันผวน และอาจช่วยระบุความแตกต่างระหว่างคุณกับฉัน และระบุตัวตนของบุคคลแต่ละคนได้อย่างเฉพาะเจาะจงมากที่สุดในเว็บไซต์ต่างๆ https://amiunique.org มีรายการฟีเจอร์ที่อาจช่วยสร้างลายนิ้วมือได้ (แต่ไม่ใช่รายการที่ครอบคลุมทั้งหมด) ซึ่งรายการนี้ยาวขึ้นเรื่อยๆ (เนื่องจากมีผลประโยชน์ทางการเงินมหาศาลในการระบุลายนิ้วมือของผู้ใช้ แม้ว่าผู้ใช้จะไม่ต้องการหรืออาจไม่คาดคิดก็ตาม)

ไม่รองรับ API บางรายการที่มีประสิทธิภาพ

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

เกตเวย์สิทธิ์ของผู้ใช้

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

การเพิ่มความคาดเดาไม่ได้

แนวทางที่ 3 ซึ่งใช้ในบางกรณีคือผู้ให้บริการเบราว์เซอร์จะ "สร้างความสับสน" ให้กับคำตอบจาก API เพื่อให้มีความละเอียดน้อยลงและระบุตัวตนได้น้อยลง สิ่งนี้อธิบายไว้ว่าเป็นส่วนหนึ่งของกลไกการตอบสนองแบบสุ่มในโมดูลข้อมูลเนื่องจาก คุณสามารถทำได้เมื่อรวบรวมข้อมูลจากผู้ใช้ เพื่อหลีกเลี่ยงการรวบรวมข้อมูลที่ระบุตัวตนโดยไม่ได้ตั้งใจ ผู้ให้บริการเบราว์เซอร์สามารถใช้แนวทางนี้กับข้อมูล API ที่พร้อมให้บริการแก่เว็บแอปและบุคคลที่สามได้ด้วย ตัวอย่างของข้อมูลนี้ ได้แก่ API การกำหนดเวลาที่แม่นยำมากซึ่งใช้ในการวัดประสิทธิภาพหน้าเว็บจาก window.performance.now() เบราว์เซอร์จะทราบค่าเหล่านี้อย่างแม่นยำในระดับไมโครวินาที แต่ค่าที่แสดงผลจะลดความแม่นยำโดยปัดเศษเป็นขอบเขต 20 ไมโครวินาทีที่ใกล้ที่สุดเพื่อหลีกเลี่ยงการใช้ค่าเหล่านี้ในการพิมพ์ลายนิ้วมือ (และเพื่อความปลอดภัยเพื่อหลีกเลี่ยงการโจมตีตามเวลาด้วย) เป้าหมายของเราคือการทำให้ API ยังคงมีประโยชน์ แต่ทำให้การตอบกลับระบุตัวตนได้น้อยลง กล่าวโดยละเอียดคือเพื่อให้ "ภูมิคุ้มกันหมู่" โดยทำให้อุปกรณ์ของคุณดูเหมือนอุปกรณ์ของคนอื่นมากกว่าที่จะมีลักษณะเฉพาะตัว Safari แสดงการกําหนดค่าระบบเวอร์ชันที่เข้าใจง่ายเพื่อเหตุผลนี้

การบังคับใช้งบประมาณความเป็นส่วนตัว

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

ใช้สภาพแวดล้อมการทดสอบแบบกว้าง

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

ควรทำ

• ดูข้อมูลวิเคราะห์และกลุ่มเป้าหมายของคุณเองเพื่อเป็นแนวทางในการเลือกเบราว์เซอร์ที่คุณควรให้ความสำคัญเมื่อทำการทดสอบ
• ชุดเบราว์เซอร์ที่ดีที่จะทดสอบ ได้แก่ Firefox, Chrome, Edge, Safari บนเดสก์ท็อป, Chrome และ Samsung Internet บน Android และ Safari ใน iOS ซึ่งช่วยให้แน่ใจว่าคุณได้ทดสอบเครื่องมือแสดงผลหลักๆ ทั้ง 3 แบบ (Gecko ใน Firefox, หน้าต่างๆ ของ Blink ใน Chrome, Edge และ Samsung Internet และ Webkit ใน Safari) และทั้งแพลตฟอร์มอุปกรณ์เคลื่อนที่และเดสก์ท็อป
• หากเว็บไซต์อาจใช้งานในอุปกรณ์ที่ไม่ค่อยเป็นที่นิยมด้วย เช่น แท็บเล็ต สมาร์ทวอทช์ หรือคอนโซลเกม ให้ทดสอบในเว็บไซต์นั้นด้วย แพลตฟอร์มฮาร์ดแวร์บางแพลตฟอร์มอาจล้าหลังกว่าอุปกรณ์เคลื่อนที่และเดสก์ท็อปสำหรับการอัปเดตเบราว์เซอร์ ซึ่งหมายความว่า API บางรายการอาจไม่มีการใช้งานหรือไม่พร้อมใช้งานในเบราว์เซอร์บนแพลตฟอร์มเหล่านั้น
• ทดสอบกับเบราว์เซอร์อย่างน้อย 1 ตัวโดยอ้างว่าความเป็นส่วนตัวของผู้ใช้เป็นแรงจูงใจ รวมเวอร์ชันก่อนเผยแพร่และเวอร์ชันทดสอบที่กำลังจะมาถึง ของเบราว์เซอร์ที่ใช้กันทั่วไปมากที่สุดซึ่งคุณสามารถเป็นไปได้และหากยังพร้อมใช้งาน โปรดไปที่ตัวอย่างเทคโนโลยีของ Safari Canary ของ Chrome, เวอร์ชันเบต้าของ Firefox ซึ่งจะช่วยให้คุณมีโอกาสระบุการหยุดทำงานของ API และการเปลี่ยนแปลงที่ส่งผลกับเว็บไซต์ของคุณมากที่สุดก่อนที่การเปลี่ยนแปลงเหล่านั้นจะมีผล ผู้ใช้ของคุณ ในทำนองเดียวกัน โปรดรับผิดชอบต่อ ผู้ใช้ สภาพแวดล้อมการทำงาน และอ้างอิง ข้อมูลวิเคราะห์ที่คุณมีอยู่ หาก ฐานผู้ใช้มีโทรศัพท์ Android รุ่นเก่าจำนวนมาก อย่าลืมรวมโทรศัพท์เครื่องดังกล่าวในการทดสอบ คนส่วนใหญ่ไม่มี ฮาร์ดแวร์ที่รวดเร็ว และรุ่นล่าสุดที่ทีมพัฒนาทำ
• ทดสอบโดยใช้ทั้งโปรไฟล์ปกติและในโหมดไม่ระบุตัวตน/การท่องเว็บแบบส่วนตัว เป็นไปได้ว่าคุณได้ให้ สิทธิ์ที่จำเป็นในโปรไฟล์ส่วนตัวของคุณ ทดสอบว่าจะเกิดอะไรขึ้นหากคุณปฏิเสธการให้สิทธิ์เว็บไซต์สำหรับคำถามใดๆ
• ทดสอบหน้าเว็บของคุณอย่างชัดแจ้งในการป้องกันด้วยลายนิ้วมือของ Firefox การดำเนินการดังกล่าวจะแสดงกล่องโต้ตอบสิทธิ์ หากหน้าเว็บพยายามฟิงเกอร์ปรินต์ หรือจะแสดงข้อมูลที่สับสนสำหรับ API บางรายการ ซึ่งจะช่วยให้คุณยืนยันได้ว่าบุคคลที่สามที่อยู่ในบริการของคุณใช้ข้อมูลที่ระบุตัวตนได้หรือไม่ หรือบริการของคุณขึ้นอยู่กับการใช้งานหรือไม่ เกี่ยวกับเรื่องนี้ จากนั้นคุณก็พิจารณาว่าการจงใจทำความสับสนนั้นทำให้การทำตามที่ต้องการนั้นยากขึ้นหรือไม่ คุณควรลอง แก้ไขตามนั้นเพื่อรับข้อมูลจากแหล่งที่มาอื่น ไม่นำข้อมูลนั้นไปใช้ หรือใช้ข้อมูลแบบละเอียดน้อยลง
• ดังที่ได้กล่าวไว้ในโมดูลบุคคลที่สามก่อนหน้านี้ การตรวจสอบความเกี่ยวข้องของบุคคลที่สามเพื่อดูว่าบุคคลที่สามเหล่านั้นใช้เทคนิคการพิมพ์ลายนิ้วมือหรือไม่ก็เป็นสิ่งสําคัญเช่นกัน การเก็บลายนิ้วมือแบบแพสซีฟนั้นตรวจพบได้ยาก (และ หากบุคคลที่สามทำบนเซิร์ฟเวอร์ของตนไม่ได้) แต่โหมดเก็บลายนิ้วมืออาจแสดงเทคนิคการเก็บฟิงเกอร์ปรินต์บางอย่าง และมองหาการใช้ navigator.userAgent หรือการสร้างออบเจ็กต์ <canvas> ที่ไม่คาดคิดอาจช่วยเปิดเผยวิธีการบางอย่าง ที่สมควรได้รับการตรวจสอบเพิ่มเติม นอกจากนี้ คุณควรมองหาการใช้คําว่า "การจับคู่แบบมีแนวโน้ม" ในเอกสารทางการตลาดหรือทางเทคนิคที่อธิบายถึงบุคคลที่สาม ซึ่งบางครั้งอาจบ่งบอกถึงการใช้เทคนิคการพิมพ์ลายนิ้วมือ

เครื่องมือทดสอบข้ามเบราว์เซอร์

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

อย่างไรก็ตาม เมื่อไซต์ได้รับการตรวจสอบแล้ว การทดสอบ API เพื่อยืนยันว่าไม่มีข้อผิดพลาดใดๆ ในเบราว์เซอร์รุ่นใหม่ (หรือใน "เบต้า" ที่กำลังจะมาถึง และ "ดูตัวอย่าง" เป็นแบบอัตโนมัติได้ และควรเป็นส่วนหนึ่งของชุดทดสอบที่มีอยู่แล้วเป็นหลัก สิ่งที่ต้องพิจารณาเกี่ยวกับเครื่องมือทดสอบอัตโนมัติเมื่อทำงานกับความครอบคลุมของ API คือเบราว์เซอร์ส่วนใหญ่ให้คุณควบคุมระดับการใช้งาน API และฟีเจอร์ต่างๆ ได้ Chrome ดำเนินการผ่านสวิตช์บรรทัดคำสั่งเช่นเดียวกับ Firefox และการเข้าถึงสิ่งเหล่านี้ในการตั้งค่าเครื่องมือทดสอบจะช่วยให้คุณทำการทดสอบบางอย่างได้ด้วยการปิดหรือเปิด API (ดูตัวอย่างวิธีเพิ่ม Flag ของเบราว์เซอร์เมื่อเปิดได้จาก ปลั๊กอิน browser-launch ของ Cypress และพารามิเตอร์ launch.args ของ Puppeteer)

ใช้สตริง User Agent เท่านั้นสําหรับข้อมูลคร่าวๆ

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

Mozilla/5.0 (Linux; Android 6.0.1; SGP771 Build/32.2.A.0.253; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/52.0.2743.98 Safari/537.36

ส่วนหนึ่งของสิ่งที่กล่าวอ้างว่านี่คือ Mozilla/5.0 ซึ่งเป็นเบราว์เซอร์ที่ปล่อยออกมาในช่วงเวลาเดียวกับที่นักบินอวกาศคนแรก ขึ้นสถานีอวกาศนานาชาติมากว่า 2 ทศวรรษแล้ว สตริง User Agent คือแหล่งสมบูรณ์ของเอนโทรปีสำหรับการเก็บลายนิ้วมือ แน่นอนว่า ผู้ผลิตเบราว์เซอร์ได้ตรึงส่วนหัวของ User Agent ไปแล้วหรือกำลังทำงาน เพื่อลดเรื่องการใช้ลายนิ้วมือ ในการทำเช่นนั้น นี่เป็นอีกตัวอย่างหนึ่งของการเปลี่ยนแปลงข้อมูลที่ API มีให้โดยไม่ต้องนํา API ออกทั้งหมด การส่งส่วนหัว User Agent ที่ว่างเปล่าจะทำให้เว็บไซต์จำนวนนับไม่ถ้วนหยุดทำงานซึ่งถือว่ามีส่วนหัวนั้นอยู่ ดังนั้น โดยทั่วไปแล้ว เบราว์เซอร์กำลังทำอะไร คือการนำรายละเอียดบางส่วนออก แล้วคงรายละเอียดส่วนใหญ่ไว้เหมือนเดิม (คุณสามารถดูสิ่งนี้เกิดขึ้นได้ใน Safari, Chrome, และ Firefox) การป้องกันนี้ การเก็บลายนิ้วมือโดยละเอียดนั้นหมายความว่าคุณจะไม่เชื่อว่าส่วนหัวของ User Agent จะมีความถูกต้องอีกต่อไปและหากคุณ การทำเช่นนั้นจึงเป็นเรื่องสำคัญที่จะต้องหาแหล่งข้อมูลอื่นๆ

โปรดทราบว่าข้อมูลใน User Agent จะไม่หายไปทั้งหมด แต่จะมีความละเอียดน้อยลงหรือบางครั้งอาจไม่ถูกต้องเนื่องจากระบบอาจรายงานตัวเลขเก่าๆ ที่ไม่เปลี่ยนแปลง เช่น Firefox, Safari และ Chrome ทั้งหมด หมายเลขเวอร์ชัน macOS ที่รายงานเป็น 10 (ดูการอัปเดตเกี่ยวกับการลดสตริง User Agent เพื่อทราบการสนทนาเพิ่มเติมที่นี่) โปรดดูรายละเอียดที่แน่นอนเกี่ยวกับวิธีที่ Chrome วางแผนจะลดข้อมูลในสตริง User Agent ที่การลด User Agent แต่สรุปแล้ว คุณคาดว่าหมายเลขเวอร์ชันของเบราว์เซอร์ที่รายงานจะมีเฉพาะเวอร์ชันหลัก (ดังนั้นหมายเลขเวอร์ชันจะมีลักษณะเป็น 123.0.0.0 แม้ว่าเบราว์เซอร์จะเป็นเวอร์ชัน 123.10.45.108 ก็ตาม) และเวอร์ชันระบบปฏิบัติการจะไม่มีรายละเอียดและจะหยุดอยู่ที่ตัวเลือกจำนวนไม่มากนักซึ่งไม่มีการเปลี่ยนแปลง Chrome ในจินตนาการในเวอร์ชัน 123.45.67.89 ที่ทำงานอยู่ในจินตนาการ "Windows 20" จะรายงานหมายเลขเวอร์ชันเป็น:

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

ข้อมูลหลักที่คุณต้องการ (เวอร์ชันของเบราว์เซอร์) ยังใช้งานได้อยู่ ได้แก่ Chrome 123 ใน Windows แต่บริษัทในเครือ (สถาปัตยกรรมชิป, เวอร์ชัน Windows, เวอร์ชัน Safari ที่กำลังเลียนแบบ, เวอร์ชันย่อยของเบราว์เซอร์) จะไม่สามารถใช้ได้อีกหลังจากการระงับ

เปรียบเทียบกับ User Agent ของ Chrome "ปัจจุบัน" ในแพลตฟอร์มอื่น

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36

และจะเห็นได้ว่าสิ่งเดียวที่แตกต่างกันคือหมายเลขเวอร์ชัน Chrome (104) และตัวระบุแพลตฟอร์ม

ในทํานองเดียวกัน สตริง User Agent ของ Safari จะแสดงแพลตฟอร์มและหมายเลขเวอร์ชันของ Safari รวมถึงแสดงเวอร์ชันระบบปฏิบัติการใน iOS ด้วย แต่ข้อมูลอื่นๆ ทั้งหมดจะหยุดอยู่ ดังนั้น Safari เวอร์ชัน 1234.5.67 ในจินตนาการที่ทำงานบน macOS 20 ในจินตนาการอาจให้ User Agent เป็น

Mozilla/5.0 (Macintosh; **Intel Mac OS X 10_20_0**) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.1 Safari/605.1.15

และใน iOS 20 ที่สมมติขึ้น อาจเป็นดังนี้

Mozilla/5.0 (iPhone; CPU **iPhone OS 20_0** like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/**20.0 Mobile/15E148 Safari/605.1.15**

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

การเปลี่ยนแปลง User Agent ที่รายงานทำให้เกิดการถกเถียงกันอย่างดุเดือด https://github.com/WICG/ua-client-hints#use-cases summarisesสรุปข้อโต้แย้งและเหตุผลบางส่วนของการเปลี่ยนแปลง และ Rowan Merewood มีชุดสไลด์ที่มีกลยุทธ์บางอย่างสำหรับการเปลี่ยนไปใช้วิธีอื่นแทนการใช้ User Agent เพื่อความแตกต่าง ในบริบทของข้อเสนอเกี่ยวกับ UA Client Hints ที่อธิบายไว้เพิ่มเติม

การทดสอบข้อบกพร่อง

การทดสอบแบบ Fuzzing เป็นคําที่มาจากแนวทางปฏิบัติด้านความปลอดภัย ซึ่งมีการเรียก API ด้วยค่าที่ไม่คาดคิด โดยหวังว่า API จะจัดการค่าที่ไม่คาดคิดเหล่านั้นได้ไม่ดีและแสดงปัญหาด้านความปลอดภัย นักพัฒนาเว็บควรคุ้นเคยกับCross-site Scripting (XSS) ซึ่งจะต้องมีการเพิ่มสคริปต์ที่เป็นอันตรายลงในหน้าเว็บ ซึ่งมักจะเป็นเพราะหน้าเว็บไม่ได้ Escape HTML ที่แทรกไว้อย่างถูกต้อง (ดังนั้นคุณจึงทำการค้นหา ที่มีข้อความ <script>) นักพัฒนาซอฟต์แวร์แบ็กเอนด์จะรู้จักการแทรก SQL ซึ่งการค้นหาฐานข้อมูลที่ไม่ตรวจสอบอินพุตของผู้ใช้อย่างถูกต้องจะแสดงให้เห็นถึงปัญหาด้านความปลอดภัย (ซึ่งเห็นได้ชัดโดย xkcd กับ Little Bobby Tables) การทดสอบแบบ Fuzz หรือการทดสอบ Fuzz เหมาะที่จะใช้กับการพยายามป้อนข้อมูลที่ไม่ถูกต้องหรือคาดไม่ถึงหลายรายการไปยัง API โดยอัตโนมัติ และตรวจสอบผลลัพธ์เพื่อหาการรั่วไหลของข้อมูล ปัญหาขัดข้อง หรือการจัดการที่ไม่ถูกต้องอื่นๆ นี่เป็นตัวอย่างของการจงใจให้ข้อมูลที่ไม่ถูกต้อง แต่ตรงนี้กำลังจะเสร็จสิ้น ป้องกันล่วงหน้าโดยเบราว์เซอร์ (โดยการทำให้ User Agent จงใจไม่ถูกต้อง) เพื่อกระตุ้นให้นักพัฒนาแอปหยุดพึ่งพาข้อมูลดังกล่าว

ควรทำ

• ตรวจสอบโค้ดเบสเพื่อดูว่ามีการพึ่งพาสตริง User Agent หรือไม่ (การค้นหา navigator.userAgent มีแนวโน้มที่จะพบรายการที่มากที่สุดในโค้ดฝั่งไคลเอ็นต์ และโค้ดแบ็กเอนด์มีแนวโน้มที่จะมองหา User-Agent เป็นส่วนหัว) รวมถึงตรวจสอบรายการที่ขึ้นต่อกัน
• หากคุณพบการใช้ในโค้ดของคุณเอง ให้ตรวจหาว่าโค้ดนั้นใช้ตรวจสอบอะไร และหาวิธีอื่นในการแยกแยะความแตกต่างดังกล่าว (หรือค้นหาทรัพยากร Dependency ทดแทน หรือดำเนินการกับอัปสตรีมทรัพยากร Dependency โดยยื่นปัญหาหรือตรวจสอบการอัปเดต) บางครั้ง การแยกความแตกต่างของเบราว์เซอร์เป็นสิ่งจำเป็นเพื่อหลีกเลี่ยงปัญหาข้อบกพร่อง แต่ User Agent จะไม่ใช้วิธีนี้ในการดำเนินการดังกล่าวมากขึ้นเรื่อยๆ
• ขอให้ปลอดภัย หากคุณใช้เฉพาะค่าหลักของแบรนด์ เวอร์ชันหลัก และแพลตฟอร์ม ข้อมูลเหล่านี้จะยังคงใช้งานได้และถูกต้องในสตริง User-Agent
• MDN อธิบายวิธีที่ดีในการหลีกเลี่ยงการพึ่งพาสตริง User Agent ("การ Sniffing เบราว์เซอร์") ซึ่งวิธีหลักคือการตรวจหาฟีเจอร์
• หากคุณต้องใช้สตริง User Agent ในทางใดทางหนึ่ง (แม้ว่าจะใช้ค่าหลัก 2-3 ค่าที่ยังมีประโยชน์อยู่) ก็ถือเป็น แนวคิดในการทดสอบกับ User-agent ที่กำลังจะเปิดตัว โดยจะอยู่ในเบราว์เซอร์รุ่นใหม่ คุณสามารถทดสอบกับเบราว์เซอร์เวอร์ชันที่กำลังจะเปิดตัวได้โดยใช้รุ่นเบต้าหรือรุ่นตัวอย่างเทคโนโลยี แต่คุณยังตั้งค่าสตริง User Agent ที่กําหนดเองสําหรับการทดสอบได้ด้วย คุณสามารถลบล้างสตริง User Agent ใน Chrome, Edge, Firefox และ Safari เมื่อทําการพัฒนาในเครื่อง เพื่อตรวจสอบว่าโค้ดของคุณจัดการกับค่า User Agent ต่างๆ ที่คุณอาจได้รับจากผู้ใช้อย่างไร

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

แนวทางหลักในการระบุข้อมูลนี้คือคำแนะนำสำหรับไคลเอ็นต์ของ User Agent แม้ว่าเบราว์เซอร์บางรุ่นจะไม่รองรับ เบราว์เซอร์ที่รองรับจะส่งส่วนหัว 3 รายการ ได้แก่ Sec-CH-UA ซึ่งระบุแบรนด์และเบราว์เซอร์เวอร์ชัน Sec-CH-UA-Mobile ซึ่งระบุว่าคำขอมาจากอุปกรณ์เคลื่อนที่หรือไม่ และ Sec-CH-UA-Platform ซึ่งระบุชื่อระบบปฏิบัติการ (การแยกวิเคราะห์ส่วนหัวเหล่านี้จะง่ายน้อยกว่าเพราะเป็น ส่วนหัวที่มีโครงสร้างแทนที่จะเป็นสตริงธรรมดา ซึ่งถูกบังคับใช้โดยเบราว์เซอร์ที่ส่ง "หลอก" ซึ่งจะได้รับการจัดการอย่างไม่ถูกต้องหากไม่มีการแยกวิเคราะห์อย่างเหมาะสม นี่คือ อย่างก่อนหน้านี้ ตัวอย่างของ “การทดสอบ Fuzz ” มีการดำเนินการล่วงหน้าโดยเบราว์เซอร์ นักพัฒนาแอปที่ใช้ข้อมูลนี้ต้องจัดการ อย่างเหมาะสม เนื่องจากข้อมูลถูกออกแบบมาให้การแยกวิเคราะห์ที่ไม่เหมาะสมหรือแบบ Lazy Loading จะให้ผลลัพธ์ที่ไม่ดี เช่น การแสดงแบรนด์ที่ไม่มี หรือมีสตริงที่ไม่ถูกต้อง) โชคดีที่ข้อมูลนี้ยังพร้อมใช้โดยเบราว์เซอร์ไปยัง JavaScript โดยตรงในฐานะ navigator.userAgentData ซึ่งในเบราว์เซอร์ที่รองรับอาจมีลักษณะดังนี้

{
  "brands": [
    {
    "brand": " Not A;Brand",
    "version": "99"
    },
    {
    "brand": "Chromium",
    "version": "96"
    },
    {
    "brand": "Google Chrome",
    "version": "96"
    }
  ],
  "mobile": false
}