Tạo dữ liệu kiểm thử cho Anti-fraud: Sinh device fingerprint tự nhiên và bất thường có kiểm soát

Khi xây dựng hệ thống anti-fraud hoặc quản trị rủi ro, bước quan trọng nhất sau khi viết xong một rule là kiểm tra xem nó có thực sự hoạt động không. Cụ thể, khi nhận một tập thông số thiết bị (device fingerprint), hệ thống có phân biệt đúng giữa user bình thường và thiết bị đáng ngờ hay không?

Bài toán khó nhất ở đây là dữ liệu thật rất khó thu thập với số lượng đủ lớn, đặc biệt là dữ liệu từ các thiết bị "xấu" mà ta cần bắt. Khi team tự tạo (construct) dữ liệu test thủ công, ta thường vô tình sinh ra những tổ hợp "không tưởng", khiến rule học sai bản chất vấn đề. Bài viết này chia sẻ một hướng tiếp cận thực tế hơn: lấy "hồ sơ thiết bị" làm đơn vị sinh dữ liệu, thay vì random từng tham số độc lập.

Các tham số trong device fingerprint không đứng độc lập

Một đoạn JavaScript đọc device fingerprint trên trình duyệt thật thường thu thập ít nhất 5 nhóm thông số: Canvas hash, WebGL renderer, timezone, locale và font list. Điểm mấu chốt là trên một thiết bị bình thường, các thông số này có mối tương quan chặt chẽ với nhau. Ví dụ, một profile Windows 11 thực tế sẽ trông như thế này:

• GPU: Intel Iris Xe Graphics
• Driver version: 31.0.101.4512
• WebGL renderer: ANGLE (Intel Iris Xe Graphics, Vulkan 1.3)
• Timezone: Asia/Ho_Chi_Minh (UTC+7)
• Locale: vi-VN
• Độ phân giải: 1920x1080 (DPR: 1)
• Fonts: Segoe UI, Calibri, Arial, Tahoma

Những cặp tương quan này hoàn toàn có cơ sở kỹ thuật:

• GPU model đi đôi với driver version. Một dòng GPU chỉ chạy được những bản driver nằm trong dải hỗ trợ nhất định.
• Độ phân giải phải khớp với phần cứng. Màn 1920x1080 thường có DPR = 1, trong khi Mac Retina có DPR = 2.
• Timezone và locale thường đồng hành. User ở Việt Nam thường dùng Asia/Ho_Chi_Minh và vi-VN.
• Font list phản ánh hệ điều hành: Windows có Segoe UI, macOS có San Francisco, Linux có font riêng.

Nói cách khác, một thiết bị thật là một tập hợp các tham số tự nhất quán (self-consistent). Mỗi giá trị đều giải thích được bằng cùng một cấu hình phần cứng và phần mềm.

Cái bẫy của việc random từng tham số

Cách nhanh nhất để tạo dữ liệu test là gán ngẫu nhiên giá trị cho từng trường. Nhưng đây chính là cái bẫy.

Khi random độc lập, xác suất để ra một tổ hợp "tồn tại trong thực tế" là cực thấp. Hầu hết bản ghi sinh ra sẽ là những tổ hợp không tưởng, ví dụ:

• WebGL renderer báo là NVIDIA RTX 4090, nhưng trường GPU lại ghi Intel.
• Timezone là America/New_York, nhưng danh sách locale chỉ có vi-VN.

Hậu quả tồi tệ hơn: rule anti-fraud, thay vì học "tín hiệu rủi ro thực sự", sẽ học cách bắt "sự thiếu nhất quán". Nói cách khác, rule sẽ thành: "Nếu các tham số không khớp nhau thì nghi ngờ". Điều này khiến hệ thống bị overfit vào một dấu hiệu quá dễ thấy.

Trong thực tế, các thiết bị gian lận tinh vi thường được tạo ra rất cẩn thận và hoàn toàn tự nhất quán (self-consistent anomalies). Ngược lại, một user thật có thể có cấu hình hơi lệch chuẩn (ví dụ người Việt sống ở Mỹ vẫn giữ locale vi-VN). Nếu rule chỉ bắt "sự không nhất quán", nó sẽ bỏ lọt kẻ xấu và chặn nhầm (false positive) người thật.

Sinh dữ liệu theo đơn vị "hồ sơ thiết bị"

Hướng tiếp cận đúng là coi "hồ sơ thiết bị" là đơn vị sinh dữ liệu nhỏ nhất. Mỗi hồ sơ là một cấu hình hoàn chỉnh, trong đó các tham số tự nhất quán với nhau. Sau đó, ta mới tạo ra nhiều hồ sơ và kiểm soát sự biến thiên trên những chiều mong muốn.

Cụ thể, ta không nói "hãy random GPU". Ta nói "hãy tạo 20 hồ sơ thuộc family GPU Intel, nhưng mỗi hồ sơ dùng một bản driver khác nhau trong dải hỗ trợ". Hoặc "giữ nguyên timezone HCMC, nhưng đổi locale thành en-US hoặc zh-CN". Những thay đổi này là có chủ đích và có thể giải thích, không phải nhiễu ngẫu nhiên.

Để hình dung, một bộ hồ sơ sinh ra theo cách này có thể gồm các biến thể sau:

• Hồ sơ A (chuẩn): GPU family Intel Iris Xe, driver 31.0.101.x, timezone HCMC, locale vi-VN. Kỳ vọng: bình thường.
• Hồ sơ B (đổi driver): Intel Iris Xe, driver 31.0.102.x, HCMC, vi-VN. Kỳ vọng: bình thường.
• Hồ sơ C (đổi locale): Intel Iris Xe, 31.0.101.x, HCMC, en-US. Kỳ vọng: bình thường (lệch nhẹ).
• Hồ sơ D (rủi ro): Intel Iris Xe, 31.0.101.x, HCMC + NY + Tokyo, vi-VN. Kỳ vọng: đáng ngờ.

Hai loại dữ liệu bắt buộc phải có mặt trong bộ test:

• Bất thường tự nhất quán: Hồ sơ hoàn toàn khớp nhau về kỹ thuật, nhưng đại diện cho một cấu hình rủi ro (ví dụ: cùng một thiết bị xuất hiện với hàng chục timezone khác nhau qua các phiên). Rule phải bắt được nó mà không cần dựa vào "sự vênh" giữa các tham số.
• Bình thường không nhất quán: User thật có cấu hình lệch chuẩn (timezone và locale không khớp) nhưng hoàn toàn vô hại. Rule không được chặn nhầm (false positive).

Chỉ khi vượt qua cả hai bài test này, ta mới có thể tin rule đang bắt "rủi ro thực sự" chứ không phải bắt "sự không hoàn hảo của dữ liệu".

Dùng BitBrowser làm nguồn sinh hồ sơ tự nhất quán

Để triển khai cách tiếp cận trên, ta cần một công cụ có thể tạo ra những hồ sơ thiết bị vừa đa dạng, vừa tự nhất quán. Trong quá trình làm dự án, team mình thường dùng BitBrowser như một nguồn sinh dữ liệu test (test data generator) thay vì tự viết script random.

Mỗi profile trong BitBrowser bản chất là một hồ sơ thiết bị tự nhất quán: GPU, driver, timezone, locale, font và các giá trị Canvas/WebGL được sinh ra sao cho khớp với nhau theo đúng một cấu hình phần cứng giả định. Tính nhất quán được đảm bảo ngay từ đầu, thay vì phải code tay để ghép nối.

Điểm hữu ích nhất với dev team là khả năng lập trình (programmability). Thông qua Local API, ta có thể:

• Tạo hàng loạt (batch) profile với các tham số được kiểm soát, không cần tạo thủ công.
• Export device fingerprint của từng profile ra định dạng JSON để đưa thẳng vào pipeline kiểm thử.
• Bind proxy cho từng profile để mô phỏng các phiên kết nối từ nhiều IP khác nhau (yếu tố quan trọng khi test các rule dựa trên IP và timezone).

Khi đã có tập hợp profile này, ta có thể chạy rule anti-fraud lên chúng như một bộ regression test: mỗi lần sửa rule, chạy lại tập profile để đảm bảo tỷ lệ catch rate và false positive rate không tệ đi. Với gói free 10 profile, team hoàn toàn có thể dựng prototype để validate ý tưởng trước khi mở rộng quy mô.

Tóm lại

Dữ liệu test cho anti-fraud không nên là các tham số random độc lập, vì điều đó sinh ra quá nhiều tổ hợp không tưởng, khiến rule bị overfit vào "sự thiếu nhất quán" thay vì "rủi ro thực sự". Cách làm đúng là sinh theo đơn vị hồ sơ thiết bị: mỗi hồ sơ tự nhất quán nội bộ, và sự biến thiên giữa các hồ sơ được kiểm soát có chủ đích. Với các công cụ có khả năng lập trình như BitBrowser API, việc tạo ra những hồ sơ này trở nên tự động hóa, giúp team xây dựng được bộ regression test vững chắc mà không cần đụng đến dữ liệu thật của người dùng.