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

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

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

เหตุผลที่ฟิงเกอร์ปรินต์เป็นอุปสรรคต่อความเป็นส่วนตัวของผู้ใช้

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

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

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

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

ควรทำ

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

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

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

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

ด้านข้าง: ฟิงเกอร์ปรินต์แบบแพสซีฟและแอ็กทีฟ

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

ยกเว้น: การวัดความสามารถในการเก็บลายนิ้วมือ

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

เบราว์เซอร์ป้องกันฟิงเกอร์ปรินต์อย่างไรบ้าง

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

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

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

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

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

เครื่องมือทดสอบในเบราว์เซอร์ต่างๆ

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

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

ใช้สตริง 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 สรุป สรุปข้อโต้แย้งและเหตุผลบางอย่างสำหรับการเปลี่ยนแปลง และ Rowan Merewood มีสไลด์พร้อมกลยุทธ์บางอย่างในการย้ายข้อมูลจากการใช้ User Agent เพื่ออธิบายความแตกต่างเพิ่มเติม ในข้อคิดของข้อเสนอ UA

ฝอยคลุม

Fuzzing เป็นคำศัพท์จากแนวทางปฏิบัติด้านความปลอดภัย โดยจะมีการเรียกใช้ 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 ทดแทน หรือทำงานกับอัปสตรีมของทรัพยากร Dependency ด้วยการแจ้งปัญหาหรือตรวจสอบการอัปเดตจากเอเจนซี) บางครั้งจำเป็นต้องมีการแยกความแตกต่างของเบราว์เซอร์เพื่อแก้ไขข้อบกพร่อง แต่ User Agent จะกลายเป็นวิธีดำเนินการนี้เพิ่มขึ้นเรื่อยๆ เมื่อหยุดการทำงาน
• คุณอาจปลอดภัย หากคุณใช้เฉพาะค่าหลักของแบรนด์ เวอร์ชันหลัก และแพลตฟอร์ม ค่าเหล่านี้จะยังใช้ได้อยู่และถูกต้องแล้วในสตริง User Agent
• MDN อธิบายวิธีที่ดีในการหลีกเลี่ยงการพึ่งพาสตริง User Agent ("การดักจับเบราว์เซอร์") ซึ่งเป็นวิธีหลักในการตรวจหาฟีเจอร์
• หากคุณพึ่งพาสตริง User Agent ในทางใดทางหนึ่ง (แม้ว่าจะใช้ค่าหลักที่ยังมีประโยชน์อยู่) เราขอแนะนำให้ทดสอบกับ User Agent ที่กำลังจะมีขึ้นซึ่งจะเป็นเวอร์ชันใหม่ของเบราว์เซอร์ คุณสามารถทดสอบด้วยเบราว์เซอร์เวอร์ชันที่กำลังจะเปิดตัวด้วยตนเองโดยใช้บิลด์เบต้าหรือเทคโนโลยีตัวอย่าง หรือตั้งค่าสตริง User Agent ที่กำหนดเองสำหรับการทดสอบได้ด้วย คุณลบล้างสตริง User Agent ใน Chrome, Edge, Firefox และ Safari ได้เมื่อพัฒนาซอฟต์แวร์ในเครื่อง เพื่อตรวจสอบวิธีจัดการโค้ดกับค่า User Agent ที่แตกต่างกันที่คุณอาจได้รับจากผู้ใช้

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

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