การเก็บลายนิ้วมือ

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

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

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

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

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

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

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

ควรทำ

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

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

วิธีการทำงานของการเก็บลายนิ้วมือ

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

สิ่งที่ยกเว้น: การเก็บลายนิ้วมือแบบแพสซีฟและแบบแอ็กทีฟ

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

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

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

เบราว์เซอร์ทำอะไรต่อฟิงเกอร์ปรินต์

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

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

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

เกตเวย์การให้สิทธิ์จากผู้ใช้

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

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

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

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

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

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

ทั้งหมดนี้จะส่งผลต่อวิธีสร้างแอปและบริการของคุณ มีคำตอบและแนวทางที่หลากหลาย ในเบราว์เซอร์และแพลตฟอร์มต่างๆ ในพื้นที่นี้ ซึ่งหมายความว่าการทดสอบงานในสภาพแวดล้อมต่างๆ ที่หลากหลายจะเป็นงานที่สำคัญ ซึ่งแน่นอนว่าเป็นเรื่องสำคัญมาก แต่ก็พอจะเดาได้ว่าการแสดงผล HTML หรือ CSS จะคงที่สำหรับ เครื่องมือการแสดงผลที่กำหนด ไม่ว่าเครื่องมือนั้นจะอยู่ในเบราว์เซอร์หรือแพลตฟอร์มใด (และด้วยเหตุนี้ จึงอาจน่าดึงดูดใจที่จะทดสอบแค่ในเบราว์เซอร์เดียวหรือแพลตฟอร์มเดียว เบราว์เซอร์ที่ใช้การกะพริบ เป็นต้น) ซึ่งแน่นอนว่าไม่ใช่กรณีการใช้ 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 บางรายการ ซึ่งจะช่วยให้คุณยืนยันได้ว่าบุคคลที่สามที่อยู่ในบริการของคุณใช้ข้อมูลที่ระบุตัวตนได้หรือไม่ หรือบริการของคุณขึ้นอยู่กับการใช้งานหรือไม่ เกี่ยวกับเรื่องนี้ จากนั้นคุณก็พิจารณาว่าการจงใจทำความสับสนนั้นทำให้การทำตามที่ต้องการนั้นยากขึ้นหรือไม่ คุณควรลอง แก้ไขตามนั้นเพื่อรับข้อมูลจากแหล่งที่มาอื่น ไม่นำข้อมูลนั้นไปใช้ หรือใช้ข้อมูลแบบละเอียดน้อยลง
• ตามที่ได้กล่าวไปแล้วในโมดูลของบุคคลที่สาม การตรวจสอบบุคคลที่สามเป็นสิ่งสำคัญเช่นกัน ทรัพยากร Dependency เพื่อดูว่ามีการใช้เทคนิคการเก็บลายนิ้วมือหรือไม่ การเก็บลายนิ้วมือแบบแพสซีฟนั้นตรวจพบได้ยาก (และ เป็นไปไม่ได้ถ้าบุคคลที่สามทำในเซิร์ฟเวอร์ของตน) แต่โหมดเก็บลายนิ้วมืออาจแสดงเทคนิคฟิงเกอร์ปรินต์บางอย่าง และมองหาการใช้ navigator.userAgent หรือการสร้างออบเจ็กต์ <canvas> ที่ไม่คาดคิดอาจช่วยเปิดเผยวิธีการบางอย่าง ที่สมควรได้รับการตรวจสอบเพิ่มเติม นอกจากนี้ คุณยังควรมองหาการใช้คำว่า "การจับคู่ความน่าจะเป็น" ในด้านการตลาดหรือ ข้อมูลทางเทคนิคที่อธิบายบุคคลที่สาม ซึ่งบางครั้งอาจบ่งบอกถึงการใช้เทคนิคฟิงเกอร์ปรินต์

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

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

อย่างไรก็ตาม เมื่อไซต์ได้รับการตรวจสอบแล้ว การทดสอบ API เพื่อยืนยันว่าไม่มีข้อผิดพลาดใดๆ ในเบราว์เซอร์รุ่นใหม่ (หรือใน "เบต้า" ที่กำลังจะมาถึง และ "ดูตัวอย่าง" เป็นแบบอัตโนมัติได้ และควรเป็นส่วนหนึ่งของชุดทดสอบที่มีอยู่แล้วเป็นหลัก บางสิ่ง กับเครื่องมือทดสอบอัตโนมัติ เมื่อทำงานร่วมกับ ความครอบคลุมแพลตฟอร์ม API ก็คือเบราว์เซอร์ส่วนใหญ่อนุญาตให้ ควบคุมว่าจะใช้ API และฟีเจอร์ใดได้บ้าง Chrome จะทำงานผ่านสวิตช์บรรทัดคำสั่ง เช่นเดียวกับ Firefox และมีสิทธิ์เข้าถึงฟีเจอร์เหล่านี้ในเครื่องมือทดสอบ การตั้งค่าจะทําให้คุณเรียกใช้การทดสอบบางอย่างโดยปิดหรือเปิด API ได้ (ดู เช่น Cypress's browser-launchปลั๊กอิน พารามิเตอร์launch.args ของ nd 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 เพื่อแยกความแตกต่าง ในบริบทของข้อเสนอ Client Hints ของ UA ที่ได้อธิบายเพิ่มเติมไปแล้ว

เบลอ

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

ควรทำ

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

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

ข้อเสนอหลักอย่างหนึ่งในการแจ้งข้อมูลนี้คือ User-Agent Client Hints แม้ว่าจะมีการสนับสนุนในบางเบราว์เซอร์เท่านั้น เบราว์เซอร์ที่สนับสนุนจะส่งส่วนหัวสามรายการ: 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
}