Chuyển đến nội dung
Quay lại bài kiểm tra fingerprintPhương pháp · cách tính điểm · giới hạn

Cách bài kiểm tra fingerprint trình duyệt hoạt động

Cách bài audit của Clearcote so sánh các tín hiệu trình duyệt, tính điểm, xử lý bằng chứng thu được qua mạng, và tránh biến dữ liệu bị thiếu hoặc mang tính ngữ cảnh thành một kết quả đạt sai.

Bài kiểm tra fingerprint trình duyệt đo lường điều gì

Bài audit đo tính nhất quán: các hệ thống con độc lập của trình duyệt có đưa ra những câu trả lời tương thích với nhau về cùng một máy hay không. Nó có thể so sánh JavaScript với CSS, trang chính với một worker hoặc iframe, dòng trình duyệt được khai báo với các API chỉ engine đó mới có, và GPU được báo cáo với pipeline render đã thực sự tạo ra hình ảnh.

Điều này khác với việc đo độ hiếm. Một thiết bị bất thường nhưng nhất quán từ bên trong vẫn có thể đạt. Một danh tính trông rất phổ biến vẫn có thể trượt khi hai bề mặt mâu thuẫn với nhau. Vì thế, phần lớn các phép kiểm tra không cần baseline từ tập người dùng; chính trình duyệt cung cấp cả hai vế của phép so sánh.

Cách tính điểm nhất quán

Điểm số là tỷ lệ các phép kiểm tra có tính điểm và áp dụng được mà cho kết quả khớp nhau. Nó không phải xác suất khách truy cập là người thật, không phải tỷ lệ phát hiện, và cũng không phải sự đảm bảo rằng một phiên tự động hóa là vô hình. Điểm 92 nghĩa là 92 phần trăm các phép so sánh có tính điểm và được áp dụng là nhất quán.

Các phát hiện mang tính ngữ cảnh bị loại trừ, vì môi trường bình thường cũng có thể tạo ra chúng: công cụ trợ năng, extension, remote desktop, trình duyệt được quản lý bằng policy, các cơ chế bảo vệ quyền riêng tư và phần cứng bị thiếu đều làm thay đổi các bề mặt quan sát được. Những phép kiểm tra không chạy được sẽ được báo là chưa đo, và không bao giờ được tính là đạt.

Vì sao một số phép đo cần thăm dò qua mạng

JavaScript không thể đọc TLS ClientHello, thứ tự frame HTTP/2, các tham số transport của QUIC hay địa chỉ public mà WebRTC sử dụng. Những thông tin đó nằm ở tầng thấp hơn runtime của trang. Muốn đo chúng, cần có một server báo lại những gì thực sự đi qua đường truyền.

Bài audit mở hai kết nối tới tls.clearcotelabs.com để so sánh các TLS handshake độc lập. Bài kiểm tra rò rỉ WebRTC của nó liên hệ với stun.l.google.com, nghĩa là Google sẽ thấy IP đang kết nối, rồi so sánh địa chỉ đó với địa chỉ phục vụ bài audit. Nếu một trong hai dịch vụ không truy cập được, kết quả tương ứng sẽ là chưa đo, chứ không phải sạch.

Thu thập dữ liệu và kho dữ liệu nghiên cứu

Khi chạy bài audit, một profile trình duyệt sẽ được gửi đến Clearcote để phân tích nội bộ. Thông báo xin đồng ý trên công cụ liệt kê các trường dữ liệu trước khi bắt đầu chạy. Kho dữ liệu nghiên cứu riêng biệt lưu một bản ghi cấu hình ở mức thô hơn, dùng để nghiên cứu độ bao phủ và dương tính giả; đây không phải cơ sở dữ liệu chống gian lận hay đánh giá uy tín tài khoản.

Toàn bộ thông tin về thời hạn lưu trữ, việc xóa dữ liệu và công bố chi tiết đến từng trường nằm trong chính sách quyền riêng tư của bài audit. Tách riêng chính sách đó giúp bài kiểm tra vẫn ngắn gọn mà không che giấu những gì rời khỏi trình duyệt.

Những gì một bài kiểm tra trình duyệt công khai không thể xác lập

Một trang công khai không thể thấy tuổi của profile trên toàn cục, lịch sử duyệt web xuyên site, uy tín tài khoản, cookie riêng tư trên các origin khác, hay các mô hình rủi ro phía server mà các hệ thống chống bot thương mại sử dụng. Dữ liệu hành vi có thể cho thấy nhịp thời gian máy móc hoặc phép nội suy hoàn hảo, nhưng một tương tác ngắn không phải là một bộ phân loại hành vi đã được huấn luyện.

Vì vậy, điểm cao chỉ nên được hiểu theo nghĩa hẹp: các phép đo đã chạy không phát hiện ra nhiều mâu thuẫn nội tại. Nó không nói lên điều gì chắc chắn về uy tín, ý định, lịch sử tài khoản, hay mọi tín hiệu mà một hệ thống phát hiện đang chạy thực tế có thể kết hợp.

Có một trường hợp đáng nói thẳng ra, vì đó là trường hợp hay bị hiểu sai nhất. Mọi phép kiểm tra trong nhóm automation đều có thể đạt mà phiên vẫn bị phân loại là tự động hóa. Trong một bài teardown đã công bố về một agent thương mại đang được triển khai thực tế, một payload thu được từ trình duyệt điều khiển qua DevTools protocol đã bị gắn nhãn là bot webdriver kèm phát hiện developer tools — trong khi chính payload đó báo mọi flag automation đều là false, và chỉ khác một cửa sổ bình thường ở mã định danh phiên, giá trị đồng hồ và một trường network-timing. Server đã dựa vào yếu tố nào thì không thể suy ngược từ phía client, và trang này cố ý không thêm một dòng cho thứ nó không đo được. Kết luận trung thực là việc có mặt của một debugging protocol được quyết định bên ngoài các giá trị mà một trang có thể đọc, nên một mục automation sạch chỉ có nghĩa là những bề mặt cụ thể đó sạch, không có nghĩa là kết nối không bị quan sát.

Cũng chính bài teardown đó là lý do trang này báo cáo nhiều lần đo thay vì chấm điểm chúng. Các payload thu được giống hệt nhau, gửi lại cho cùng một vendor cách nhau một tuần, nhận về kết luận tampering và anti-detect khác nhau đáng kể — do model drift, lịch sử replay, hoặc cả hai, chưa tách bạch được. Điểm tuyệt đối từ một hệ thống phát hiện đang chạy thực tế sẽ trôi dạt theo thời gian; chỉ những chênh lệch đo so với một nhóm đối chứng trong cùng phiên mới có ý nghĩa. Điều đó cũng áp dụng cho chính con số của trang này, và đó là lý do lần chạy báo cáo mức độ ổn định của các câu trả lời từ trình duyệt của bạn, thay vì coi một lượt chạy đạt là chân lý tuyệt đối.