navigator.cpuPerformance trong Chrome 152: tín hiệu mới để phát hiện chống phát hiện và thu thập dữ liệu

Ngày 25 tháng 8 năm 2026, Chrome 152 đã đến với kênh ổn định trên Windows, Mac, Linux, ChromeOS và Android — và mang đến thuộc tính navigator.cpuPerformance. Một số từ 0 đến 4 mà trang web đọc đồng bộ, không cần quyền truy cập và không tốn một chu kỳ tính toán nào. Nó được thiết kế như một gợi ý cho các cuộc gọi video và phát trực tiếp: thiết bị yếu nhận 240p mà không làm mờ nền, thiết bị mạnh nhận 1080p với hiệu ứng. Hai tuần sau khi phát hành, ngành công nghiệp thu thập dữ liệu đang thảo luận về điều khác: các hệ thống chống bot đã có một tín hiệu rẻ và ổn định về phần cứng mà trình duyệt của bạn đang chạy.

Trình duyệt trả về điều gì

Thuộc tính này không trả về gigahertz hay mô hình bộ xử lý, mà là "giỏ" hiệu suất. Theo tài liệu giải thích của WICG, có bốn cấp độ cộng với không:

• 0 — không thể phân loại thiết bị;
• 1 — gần như không phù hợp cho các tác vụ nặng;
• 2 — yếu, nhưng vẫn hoạt động;
• 3 — thoải mái cho các kịch bản thông thường;
• 4 — hiệu suất cao, có dư cho đa nhiệm.

Thông số kỹ thuật cấm tiết lộ nhà cung cấp, tên mô hình và số lượng lõi, yêu cầu HTTPS và đặt mục tiêu bảo mật: mỗi giỏ phải bao phủ một phần đáng kể các thiết bị trên internet — khoảng hàng trăm mô hình CPU khác nhau, để giá trị không thu hẹp đối tượng xuống còn vài đơn vị.

Thực tế triển khai trong Chromium lại đơn giản hơn so với thông số kỹ thuật. Trong phân tích của Zyte, cho thấy rằng phân loại chủ yếu dựa vào số lượng lõi logic và bảng tăng giảm đã được mã hóa: tần số không được tính đến, mặc dù thông số kỹ thuật cho phép điều đó. Tăng cấp nhận được từ AMD Ryzen, lõi Intel Gracemont, Apple silicon và Intel Core Ultra; giảm cấp — Intel Atom và bộ xử lý thời kỳ Core 2. Sự gán ghép thô trông như sau: máy đơn lõi và cực kỳ yếu nằm trong cấp độ đầu tiên, hai đến bốn lõi cho cấp độ thứ hai, bốn đến mười lõi hoặc chip tiết kiệm năng lượng hiện đại — cấp độ thứ ba, và tám lõi trở lên trên Core Ultra, Apple M-series và mọi thứ từ mười lõi trở lên — cấp độ thứ tư.

Tại sao đây là tín hiệu phát hiện, chứ không chỉ là một byte entropy khác

Giá trị tự nó là yếu: năm tùy chọn — khoảng 2,3 bit entropy, ít hơn so với ngôn ngữ giao diện. Mối nguy hiểm nằm ở ba thuộc tính khác.

Nó miễn phí. Để đo tốc độ thực thi JS thực tế bằng thời gian, script phát hiện cần chiếm CPU trong hàng chục mili giây, và điều này có thể thấy rõ trong profiler. Ở đây — việc đọc thuộc tính đồng bộ, không tốn chi phí, không để lại dấu vết.

Nó ổn định. Giá trị không phụ thuộc vào tải của máy trong thời điểm kiểm tra: đây là loại phần cứng, không phải mức sử dụng hiện tại. Giữa các phiên, khởi động lại và thay đổi IP, nó vẫn giữ nguyên — tức là có thể được sử dụng như một phần của định danh hồ sơ lâu dài.

Nó được kiểm tra tính nhất quán. Đây là điều chính. Các động cơ chống bot hiện đại hiếm khi cấm dựa trên một trường duy nhất — họ tìm kiếm các mâu thuẫn nội bộ trong tập hợp. Thiết bị tuyên bố cấp độ bốn phải xác nhận điều đó bằng navigator.hardwareConcurrency hợp lý, navigator.deviceMemory hợp lý, chuỗi GPU-renderer hiện đại và tốc độ thực thi JS tương ứng. Hồ sơ trả về cấp độ 4 và đồng thời thực hiện benchmark như một máy ảo hai lõi sẽ bị phát hiện bởi kiểm tra chéo đơn giản.

Riêng biệt, điều này tạo ra một ranh giới gần như hoàn thiện giữa "trung tâm dữ liệu" và "người dùng thật": một instance đám mây điển hình trên hai vCPU trung thực báo cáo cấp độ đầu tiên, trong khi máy tính xách tay và điện thoại tiêu dùng sống trong cấp độ thứ ba và thứ tư. Đối với một scraper chạy trên VPS rẻ tiền ở chế độ headless và đồng thời giả mạo là Chrome thông thường trên Windows, đây là sự kết hợp không thuận lợi.

Điều này khác gì so với hardwareConcurrency, vốn đã có từ lâu

Câu hỏi hợp lý: số lượng lõi mà trang web đã đọc trước đây thông qua navigator.hardwareConcurrency, và dung lượng bộ nhớ — thông qua navigator.deviceMemory. Điều gì đã thay đổi?

Sự liên kết đã thay đổi. hardwareConcurrency là một số thô, và đã bị thay thế từ lâu và ở khắp mọi nơi: đặt tám thay vì ba mươi hai, và vấn đề được giải quyết. cpuPerformance là một giá trị phụ thuộc, được tính toán bởi chính trình duyệt dựa trên bảng đã được mã hóa. Khi trong tập hợp xuất hiện hai trường, một trường được tính toán từ trường khác, bất kỳ chỉnh sửa một chiều nào cũng sẽ làm đứt mối liên hệ giữa chúng. Đặt bốn lõi, nhưng cấp độ vẫn là bốn — theo logic thực hiện, sự kết hợp này yêu cầu hoặc là Apple silicon, hoặc là Core Ultra, hoặc là mười lõi; có nghĩa là, hoặc là số lượng lõi sai, hoặc là chuỗi GPU sai, và bộ phát hiện chỉ cần nhận thấy sự không khớp, không cần phải tìm hiểu xem đâu là sự dối trá.

Chính vì vậy mà các danh sách kiểm tra cũ "các trường nào cần thay thế trong hồ sơ" đã lỗi thời không chỉ ở một mục, mà ở cả các khối: câu hỏi đúng bây giờ không phải là "cái gì cần thay thế", mà là "cấu hình phần cứng nào nhất quán mà chúng ta có được tổng thể".

Ai bị ảnh hưởng nhiều nhất

Chỉ dành riêng cho Chromium — và đây không phải là một tình huống giảm nhẹ. WebKit đã có lập trường "chống" đối với API này, Mozilla chưa công bố lập trường công khai, vì vậy thuộc tính này có khả năng sẽ không có trong Safari và Firefox. Nhưng phần lớn tự động hóa sản xuất — Playwright, Puppeteer, nodriver, Patchright, các trình duyệt đại lý — được xây dựng dựa trên Chromium. Điều này có nghĩa là tín hiệu đến đúng vào ngách mà nó ít được mong đợi nhất.

Điều mâu thuẫn này ảnh hưởng nặng nề đến việc giả lập các hồ sơ di động. Nếu hồ sơ chống phát hiện giả mạo là smartphone Android, và cpuPerformance dưới nó trả về "4", vì trình duyệt thực sự chạy trên máy tính để bàn với Ryzen, — đây không phải là một sai sót nhỏ, mà là một cặp tín hiệu mâu thuẫn. Điều tương tự với các kịch bản farm, nơi hàng chục hồ sơ với các "thiết bị" khác nhau sống trên một máy chủ và do đó cung cấp cùng một cấp độ.

Điều này thay đổi điều gì cho ngăn xếp phân tích

Một vài hệ quả thực tiễn cho những ai chạy trình duyệt headless hàng loạt.

• Các container kế thừa từ host. Trình duyệt trong docker thấy các lõi của máy chủ, không phải giới hạn cgroup, — có nghĩa là, mười container trên một máy chủ lớn sẽ cho ra mười cấp độ tối đa giống nhau. Sự đa dạng của các hồ sơ mà bạn đã cố gắng tạo ra trong user-agent không tồn tại ở cấp độ phần cứng.
• VPS rẻ giờ đây dễ nhận biết hơn. Hai vCPU — đó là cấp độ đầu tiên, và cấp độ đầu tiên trên Chrome máy tính để bàn dưới Windows hiếm khi gặp ở người thật. Trước đây, một máy chủ yếu chỉ đơn giản là chậm; giờ đây nó còn bị đánh dấu.
• Tín hiệu miễn phí cho trang web. Các kiểm tra nặng như benchmark thời gian mà các trang web chọn lọc thực hiện vì chúng tốn thời gian của người dùng. Việc đọc thuộc tính không tốn gì, vì vậy nó sẽ được thêm vào bộ công cụ cơ bản ngay cả những trang web trước đây chỉ giới hạn ở độ tin cậy IP và tiêu đề.
• Nó sẽ nằm cạnh Compute Pressure. Trong ghi chú phát hành của Chrome, họ đề xuất kết hợp API mới với Compute Pressure API — tức là sự kết hợp "loại phần cứng cộng với tải quan sát được" được dự định như một kịch bản tiêu chuẩn, và các bot chống không cần phải phát minh ra điều gì.

Riêng biệt, cần xem xét lại giả định rằng chỉ cần một lần xây dựng hồ sơ "tốt" và tái sử dụng nó trong nhiều năm. Các trình duyệt thêm các thuộc tính như vậy mà không thông báo cho người dùng cuối: giữa việc phát hành Chrome 152 và các phân tích công khai đầu tiên đã trôi qua hàng tuần, trong đó các hồ sơ đã bình tĩnh cung cấp trường mới mà không nghi ngờ gì. Kiểm tra tập hợp các trường có ý nghĩa một lần trong mỗi chu kỳ phát hành, chứ không phải một lần mỗi năm.

Phải làm gì trên thực tế

1. Ghi lại giá trị hiện tại. Trong bảng điều khiển hồ sơ: navigator.cpuPerformance, navigator.hardwareConcurrency, navigator.deviceMemory và chuỗi renderer WebGL. Ghi lại theo bốn trường, không phải từng trường một — bạn sẽ bị kiểm tra chính xác theo cặp.
2. So sánh cấp độ với huy hiệu hồ sơ. Huy hiệu di động — cấp độ một đến ba, máy tính xách tay giá rẻ — cấp độ hai đến ba, máy tính để bàn flagship — cấp độ bốn. Cấp độ 4 dưới dạng Android cũ hoặc cấp độ 1 dưới dạng MacBook trên M-series đều đáng nghi ngờ như nhau.
3. Đừng sửa thuộc tính trực tiếp. Thay thế thông qua Object.defineProperty sẽ bị phát hiện qua dấu vết của việc ghi đè getter và sự không khớp với tốc độ thực thi thực tế. Nếu phải thay đổi, thì ở cấp độ xây dựng trình duyệt hoặc thông qua các cơ chế tích hợp.
4. Nhớ về việc ghi đè hợp pháp. Chrome cho phép người dùng điều chỉnh trong cài đặt (Performance → Speed → Override CPU performance tier), và cho các quản trị viên — chính sách doanh nghiệp. Điều này hữu ích để biết từ cả hai phía: giá trị có thể không chỉ là "thật", mà còn được thiết lập bằng tay, và việc ghi đè giống nhau trên một nhóm hồ sơ sẽ trở thành một dấu hiệu.
5. Phân tán hồ sơ trên các phần cứng khác nhau. Nếu tất cả các hồ sơ của bạn đều nằm trên một máy chủ, cấp độ của chúng sẽ giống nhau — bất kể chúng mô phỏng thiết bị nào. Đây là trường hợp mà một đội xe gồm nhiều máy với cấu hình khác nhau sẽ giải quyết vấn đề một cách trung thực, trong khi một bản vá thì không.

Chi tiết hơn về tín hiệu liền kề cùng loại — trong phân tích dấu vết theo dung lượng bộ nhớ của thiết bị, và về các trình duyệt stealth, mà hoạt động với những thuộc tính như vậy ngay từ đầu, có benchmark nodriver, Camoufox và Patchright.

Ở đây có proxy không

Nói thẳng ra: proxy không sửa được dấu vết của trình duyệt. cpuPerformance được tính toán ở phía khách hàng, và không có IP nào có thể thay đổi nó. Nhưng chống bot đưa ra quyết định dựa trên tổng số lớp, và chính tại giao điểm của các lớp thường xảy ra sự thất bại.

Chuỗi điển hình mà các thiết lập rẻ tiền gặp phải như sau: IP từ một mạng lưu trữ nổi tiếng, cấp độ đầu tiên của bộ xử lý, dấu hiệu headless trong JS — ba tín hiệu độc lập, mỗi tín hiệu riêng lẻ đều có thể chấp nhận được, nhưng khi kết hợp lại chúng tạo thành một phán quyết rõ ràng. Việc loại bỏ lớp mạng khỏi tổng số này rẻ hơn và đáng tin cậy hơn so với việc chiến đấu với các trường của trình duyệt: với IP dân cư, yêu cầu trông giống như lưu lượng của một nhà cung cấp dịch vụ internet thông thường, và giả thuyết "trung tâm dữ liệu" sẽ tự động biến mất khỏi bộ phát hiện. Đối với các huy hiệu di động, logic cũng giống nhau — proxy di động phải hỗ trợ huy hiệu di động, nếu không thì sự mâu thuẫn chỉ chuyển từ bộ xử lý sang mạng.

Tóm tắt

Chrome 152 không chỉ thêm một dấu vết mới, mà còn thêm một dòng mới vào bảng kiểm tra chéo. Hai bit nhỏ tự nó không tiết lộ ai cả — điều tiết lộ là sự không nhất quán: thiết bị được tuyên bố phải khớp với loại bộ xử lý, dung lượng bộ nhớ, card đồ họa, tốc độ thực thi và mạng mà yêu cầu đến. Việc kiểm tra hồ sơ trong tuần này nên bắt đầu từ một dòng trong bảng điều khiển và câu hỏi "liệu loại phần cứng này có thực sự tồn tại đối với người mà chúng ta đang giả mạo?".