กลับไปบล็อก

การจำลองลายนิ้วมือบนมือถือ: ความต่างของพารามิเตอร์จากเดสก์ท็อป

การจำลองลายนิ้วมือบนมือถือทำให้เบราว์เซอร์เดสก์ท็อปแสดงตัวเป็นอุปกรณ์มือถือ หน้าจอ รุ่นอุปกรณ์ เซ็นเซอร์และการสัมผัส เครือข่ายและผู้ให้บริการ รวมถึงตัวระบุ UA/App ต้องสอดคล้องกัน เพื่อให้สภาพแวดล้อมดูสมเหตุสมผลเมื่อถูกตรวจสอบ

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

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

มือถือและเดสก์ท็อปต่างกันตรงไหน

สิ่งที่เห็นชัดที่สุดคือหน้าจอ อุปกรณ์มือถือมี logical resolution และความกว้างของ viewport ต่างจากเดสก์ท็อปมาก และแม้เป็นรุ่นเดียวกัน usable viewport ก็อาจเปลี่ยนตามเวอร์ชันระบบ หากค่าหน้าจอไม่สอดคล้อง การปรับค่าอื่นต่อก็ยังดูผิดธรรมชาติ

ชั้นที่สองคือรุ่นอุปกรณ์และระดับฮาร์ดแวร์ แพลตฟอร์มอาจอ้างอิงรุ่นเพื่อประเมินระดับของอุปกรณ์ แล้วเลือกว่าจะส่งหน้าเว็บหรือสื่อเวอร์ชันใดให้ รุ่น, pixel ratio, หน่วยความจำ และพารามิเตอร์กราฟิกควรสัมพันธ์กัน การใช้ชื่อรุ่นระดับสูงร่วมกับลักษณะฮาร์ดแวร์ระดับล่างเป็นความขัดแย้งในตัวเอง

เซ็นเซอร์และลักษณะการสัมผัสเป็นส่วนที่มักถูกมองข้าม โทรศัพท์จริงมี gyroscope และ accelerometer ส่วน touch events อาจมีข้อมูลแรงกด พื้นที่สัมผัส และ multi-touch ซึ่งเบราว์เซอร์เดสก์ท็อปไม่มีเป็นค่าเริ่มต้น หากเปลี่ยนเพียง UA ให้เป็นของมือถือ การตรวจ touch events ก็อาจเห็นความไม่ตรงกันได้ ชั้นนี้จึงต้องทำให้ sensor readings และรูปแบบ touch events สมเหตุสมผล ไม่ใช่แค่เปิดสวิตช์บางตัว

ประเภทเครือข่ายและผู้ให้บริการก็เป็นส่วนหนึ่งของ fingerprint อุปกรณ์มือถือมักใช้เครือข่ายเซลลูลาร์ และหน้าเว็บอาจอ่านชื่อผู้ให้บริการ ประเภทการเชื่อมต่อ หรือแม้แต่ข้อมูลที่เกี่ยวกับสัญญาณได้ หาก environment ระบุว่าอยู่กับผู้ให้บริการรายหนึ่งในประเทศหนึ่ง แต่ outbound connection ใช้ data-center IP การผสมแบบนี้พบได้น้อยในอุปกรณ์จริงและควรตรวจแยก

ชั้นสุดท้ายคือ user agent และตัวระบุอุปกรณ์ และสำหรับหลายคนนี่เป็นชั้นเดียวที่ถูกเปลี่ยน UA ต้องสอดคล้องกับรุ่นอุปกรณ์ เวอร์ชันระบบ และเวอร์ชันเบราว์เซอร์ นอกจากนี้ WebView identifier ภายใน App กับ identifier ของเบราว์เซอร์ปกติก็เป็นคนละอย่าง แพลตฟอร์มอาจใช้ข้อมูลนี้เพื่อดูว่าการเข้าชมเปิดจาก App หรือจากเบราว์เซอร์โดยตรง หากนำสองแบบมาปะปนกัน ก็อาจเห็นร่องรอยว่า environment ถูกประกอบขึ้น

ควรตรวจความสอดคล้องอย่างไร

หลังตั้งค่าพารามิเตอร์แล้ว ควรตรวจตามลำดับคงที่ เพราะปัญหาในชั้นต้นมักทำให้ดูเหมือนเป็นปัญหาในชั้นถัดไป

เริ่มจาก device identity: ตรวจว่า operating system, รุ่นอุปกรณ์, resolution และ pixel ratio ที่หน้า test อ่านได้ตรงกับ configuration หรือไม่ และรุ่นกับ OS version ใน UA สอดคล้องกันหรือไม่ จากนั้นตรวจ time zone และ language ทั้งสองควรตรงกับ target market ของบัญชี และ geolocation กับ outbound region ก็ควรอยู่ในพื้นที่เดียวกัน ความขัดแย้งระหว่างข้อมูลเหล่านี้เป็นสัญญาณที่พบได้บ่อย ต่อไปตรวจเครือข่าย: outbound IP เป็น residential หรือ data-center, ข้อมูลผู้ให้บริการตรงกับการถือครอง IP หรือไม่ และ WebRTC รั่ว address ที่ไม่เข้ากับ environment หรือไม่ สุดท้ายตรวจ behavioral capabilities: touch events, sensor readings และ font set ดูเหมือนของอุปกรณ์มือถือจริงหรือไม่

หากมีบางรายการไม่ตรง ควรหาก่อนว่าพารามิเตอร์ใดขัดกับภาพรวม แทนที่จะสร้าง environment ใหม่ซ้ำ ๆ การ rebuild ไม่ได้แก้ความขัดแย้งภายในระหว่างพารามิเตอร์

อีกประเด็นที่ควรทราบคือ หากหน้า third-party detection แสดงความผิดปกติ ไม่ได้แปลว่า environment ผิดเสมอไป แต่ละ test site เก็บข้อมูลต่างวิธีกัน บางแห่งใช้ scripts อ่าน browser characteristics บางแห่งดู request headers ดังนั้น environment เดียวกันจึงอาจได้ผลต่างกันในแต่ละเว็บ Browser extensions อาจเปลี่ยนข้อมูลที่หน้าเว็บอ่านได้ และ IP database ที่อัปเดตช้าอาจระบุตำแหน่ง residential IP ผิด การเลือก test site ที่อัปเดตสม่ำเสมอและมีชื่อเสียงดีเป็น baseline เพียงหนึ่งแห่งมักมีประโยชน์กว่าการเทียบหลายเว็บตลอดเวลา

การจำลองมือถือแทนอุปกรณ์จริงไม่ได้

บางสถานการณ์ยังต้องใช้อุปกรณ์จริง เช่น การทดสอบที่ต้องการข้อมูลเซ็นเซอร์จริง กล้อง หรือความสามารถเต็มของ gyroscope; ขั้นตอน risk control ที่แพลตฟอร์มต้องการความเป็นอุปกรณ์จริงสูงและตรวจภายใน App; และการยืนยันที่เกี่ยวกับการชำระเงินจริงหรือเครือข่ายผู้ให้บริการจริง นอกจากนี้ฟังก์ชันบางอย่างมีเฉพาะใน native client และใช้บน web ไม่ได้ ดังนั้น simulated environment ก็ครอบคลุมไม่ได้

แบ่งงานได้แบบนี้: mobile scenarios ที่ web รองรับให้ใช้ simulated environment ส่วนการตรวจระดับ hardware และ App ให้ใช้อุปกรณ์จริง ทั้งสองแนวทางเสริมกัน ไม่ได้แทนกัน

คำถามที่พบบ่อย

เปลี่ยนแค่ UA แล้วผ่านการตรวจได้หรือไม่ โดยทั่วไปยาก UA เป็นพารามิเตอร์ที่เปลี่ยนแยกได้ง่ายมาก และก็ cross-check ได้ง่ายเช่นกัน หาก resolution, fonts, language, time zone และ touch capability ไม่ตรงกัน ก็เห็นความไม่สอดคล้องได้ง่าย

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

ด้าน compliance ต้องระวังอะไร ใช้เฉพาะเพื่อทดสอบบัญชีที่คุณดูแลและงานของธุรกิจคุณเอง อย่าใช้เพื่อปลอม device identity เพื่อหลบเลี่ยง platform verification และอย่าใช้กับกิจกรรมฉ้อโกง

สรุป

การจำลองลายนิ้วมือบนมือถือไม่ได้เกี่ยวกับพารามิเตอร์ตัวใดตัวหนึ่ง แต่คือการทำให้พารามิเตอร์ทั้งชุดสอดคล้องกับ device identity และ target market หน้าจอ รุ่น เซ็นเซอร์ เครือข่าย และ UA ต้องสมเหตุสมผลแยกกันและไม่ขัดกัน ควรแยกการจัดการ mobile และ desktop environments ให้บัญชีหนึ่งใช้ device profile ที่คงที่ในระยะยาว และใช้ outbound connection แยกที่ตรงกับภูมิภาค เครื่องมือจัดการ environment อย่าง PurpleMark สามารถผูก device และ system parameters, proxy และ start page ไว้ตอนสร้าง environment และคืนค่าเดิมเมื่อเปิดใช้งานแต่ละครั้ง เพื่อลดการตั้งค่าใหม่ซ้ำ ๆ