Mở bảng điều khiển Network trong các công cụ dành cho nhà phát triển của trình duyệt và bạn hầu như sẽ luôn tìm thấy tiêu đề User-Agent. Nó giống như một phần giới thiệu ngắn: trình duyệt nào đang đưa ra yêu cầu, nó chạy trên hệ điều hành nào và nó tuyên bố là phiên bản nào.
Điều đó khiến bạn muốn coi tiêu đề như một ID thiết bị — hoặc giả định rằng thay đổi một dòng có thể biến trình duyệt thành một thiết bị khác. Cả hai ý tưởng chỉ đúng một phần.
Chuỗi User-Agent, hoặc UA, là thông tin tương thích do máy khách khai báo. Nó không phải là thông tin xác thực danh tính đáng tin cậy và khách hàng có thể sửa đổi thông tin đó. Tuy nhiên, nó không tồn tại một cách cô lập. Một trang web có thể so sánh UA với Client Hints, API JavaScript, thuộc tính màn hình, phông chữ, Canvas, WebGL, ngữ cảnh mạng và hành vi. Do đó, câu hỏi hữu ích không chỉ đơn giản là liệu một UA có thể được thay đổi hay không, mà là vai trò của nó trong bề mặt có thể quan sát được hoàn chỉnh của trình duyệt.
Bài viết này sử dụng các tiêu chuẩn HTTP và nghiên cứu dấu vân tay trình duyệt để trả lời bốn câu hỏi:
- Tại sao một chuỗi UA trông giống như một phần của khảo cổ học trình duyệt?
- UA có thể đóng góp bao nhiêu thông tin nhận dạng và chúng ta nên giải thích nghiên cứu như thế nào?
- Tại sao chỉ thay đổi UA có thể tạo ra sự mâu thuẫn rõ ràng hơn?
- UA Reduction và User-Agent Client Hints thực sự thay đổi điều gì?
Trong bài viết này, UA chủ yếu có nghĩa là tiêu đề yêu cầu HTTP
User-Agent. Chúng tôi cũng thảo luận vềnavigator.userAgentvànavigator.userAgentDatatrong JavaScript. Các giao diện này có liên quan nhưng không giống nhau vĩnh viễn trên mọi trình duyệt và ngữ cảnh.
1. User-Agent là gì?
Mục 10.1.5 của RFC 9110 định nghĩa User-Agent là một trường chứa thông tin về tác nhân người dùng đã tạo ra yêu cầu. Ngữ pháp đơn giản của nó là:
User-Agent = product *( RWS ( product / comment ) )
product = token [ "/" product-version ]
Nói một cách đơn giản, chuỗi bắt đầu bằng tên sản phẩm và có thể bao gồm một phiên bản. Nhiều sản phẩm hoặc bình luận có thể theo dõi. Tiêu chuẩn công nhận các cách sử dụng như giải pháp tương tác, chẩn đoán và phân tích, nhưng nó cũng khuyên các triển khai không tiết lộ chi tiết không cần thiết: UA dài hơn, cụ thể hơn làm tăng cả kích thước yêu cầu và rủi ro dấu vân tay.
Một UA máy tính để bàn Chromium hiện đại có thể trông như thế này:
Mozilla/5.0 (Windows NT 10.0; Win64; x64)
AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/145.0.0.0 Safari/537.36
Tách chuỗi theo khoảng trắng sẽ hiển thị một số tên có vẻ không liên quan đến Chrome:
| Mã thông báo | Ý nghĩa chung của nó ngày nay | Đọc sai phổ biến |
|---|---|---|
Mozilla/5.0 | Mã thông báo tương thích lịch sử | Trình duyệt phải là Firefox hoặc sản phẩm Mozilla |
Windows NT 10.0 | Một danh mục nền tảng Windows; Một UA giảm không thể phân biệt Windows 10 với 11 | Máy tính phải chạy Windows 10 |
Win64; x64 | Manh mối cho thấy đây là Windows 64-bit trên kiến trúc x86-64 | Nó chứng minh mô hình CPU vật lý chính xác |
AppleWebKit/537.36 | Mã thông báo tương thích và dòng động cơ | Chrome vẫn sử dụng triển khai hoàn chỉnh của Safari |
KHTML, like Gecko | Ngôn ngữ tương thích lịch sử | Cả KHTML và Gecko đều đang chạy |
Chrome/145.0.0.0 | Họ Chrome/Chromium và phiên bản chính; Các thành phần phiên bản thấp hơn có thể bị giảm | Nó tiết lộ phiên bản vá chính xác |
Safari/537.36 | Mã thông báo được giữ lại để tương thích với các trang web cũ hơn | Trình duyệt phải được Safari |
Sự UA trở nên dài dòng vì các trang web ban đầu thường phân nhánh trên tên trình duyệt. Các trình duyệt mới phải tuyên bố khả năng tương thích với các sản phẩm cũ hơn để nhận được trang chính xác. Những tuyên bố này tích lũy theo thời gian, tạo ra một hồ sơ lịch sử không thể đọc theo nghĩa đen.
Do đó, quy tắc đầu tiên của phân tích cú pháp UA rất đơn giản: ** nó là một giao thức tương thích, không phải là một mô tả thiết bị nghiêm ngặt.
2. Tại sao các website vẫn sử dụng UA?
UA không chỉ được sử dụng để theo dõi. Sử dụng hợp pháp bao gồm:
- phục vụ dự phòng cho trình duyệt cũ hơn có vấn đề tương thích đã biết;
- chọn trình cài đặt hoặc định dạng tải xuống thích hợp;
- tìm lỗi phiên bản cụ thể trong nhật ký chẩn đoán;
- đo lường các bản phân phối dòng trình duyệt, nền tảng và phiên bản chính;
- xác định các kết hợp bất khả thi trong lưu lượng truy cập tự động hoặc độc hại.
Vấn đề bắt đầu khi UA sniffing chuyển từ dự phòng tương thích hẹp sang khả năng đoán theo tên sản phẩm. Mã có thể nhìn thấy Chrome và giả định rằng một API cụ thể tồn tại. Giả định đó có thể thất bại trong WebView nhúng, trình duyệt có nguồn gốc từ Chromium, trình duyệt có chính sách doanh nghiệp, UA bị đóng băng hoặc máy khách đã thay đổi tiêu đề của nó.
Một thứ tự hoạt động mạnh mẽ hơn là:
- Kiểm tra trực tiếp API hoặc hành vi cần thiết bất cứ khi nào có thể phát hiện khả năng.
- Khi không thể tránh khỏi việc nhận dạng trình duyệt, hãy sử dụng trình phân tích cú pháp được duy trì thay vì biểu thức chính quy đặc biệt.
- Chỉ lưu trữ các danh mục thô mà sản phẩm thực sự cần.
- Cung cấp dự phòng cho các thương hiệu không xác định, phiên bản không xác định và trường bị thiếu.
3. UA có phải là dấu vân tay của trình duyệt không?
Chính xác hơn, UA là một đầu vào vào dấu vân tay của trình duyệt, thường không phải là dấu vân tay hoàn chỉnh.
Lấy dấu vân tay của trình duyệt không yêu cầu số sê-ri bí mật. Nó đo lường một tập hợp các thuộc tính tương đối ổn định, phân biệt được trình duyệt hiển thị. UA đóng góp manh mối về dòng trình duyệt, phiên bản và nền tảng. Kích thước màn hình, phông chữ, múi giờ, Canvas, WebGL, AudioContext và các giao diện khác bổ sung thêm thông tin.
Cuộc khảo sát của Laperdrix và các đồng nghiệp, Browser Fingerprinting: A Survey, thảo luận về những kỹ thuật này như một hình thức công nhận không quốc tịch. Một trang web không nhất thiết phải viết một Cookie trước; Nó có thể cố gắng liên kết các lượt truy cập từ các thuộc tính mà trình duyệt hiển thị. "Không có trạng thái" không có nghĩa là máy chủ không lưu trữ gì. Điều đó có nghĩa là tài liệu nhận dạng không phụ thuộc vào mã định danh phía máy khách liên tục.
1. Kết quả 10-bit của bài báo có nghĩa là gì?
Trong nghiên cứu năm Panopticlick năm 2010 How Unique Is Your Web Browser?, Peter Eckersley đã phân tích khoảng 470.000 dấu vân tay của trình duyệt. Tờ báo đưa tin rằng:
- dấu vân tay hoàn chỉnh mang trung bình khoảng 18,1 bit thông tin nhận dạng trong mẫu đó;
- Nói một cách trực quan, một dấu vân tay trung bình xảy ra khoảng một lần trong 286.777 trình duyệt;
- bảng báo cáo khoảng 10,0 bit thông tin trung bình chỉ riêng cho chuỗi UA;
- trong số các trình duyệt đã bật Flash hoặc Java, 94,2% dấu vân tay hoàn chỉnh là duy nhất.
Thông tin bản thân thường được viết như sau:
I(x) = -log₂ P(x)
Nếu một UA cụ thể xảy ra với xác suất 1/1024 trong một quần thể, quan sát nó cung cấp 10 bit thông tin. Điều này không có nghĩa là UA có chính xác 1.024 giá trị có thể có hoặc nó xác định duy nhất một người. Nó mô tả mức độ không chắc chắn mà quan sát đó loại bỏ trung bình.
2. Tại sao kết quả năm 2010 không phải là một hằng số đối với web ngày nay?
Kết quả vẫn quan trọng, nhưng nó cần ít nhất ba tiêu chuẩn:
- Khách truy cập vào trang kiểm tra quyền riêng tư không phải là mẫu ngẫu nhiên của tất cả người dùng internet;
- Sự đa dạng của trình duyệt, plugin và phiên bản UA trong năm 2010 khác rất nhiều so với hệ sinh thái ngày nay;
- UA Reduction, việc thu nhỏ bề mặt plugin và các biện pháp bảo vệ chống dấu vân tay đã thay đổi sự phân phối của các thuộc tính có thể quan sát được.
Nghiên cứu ủng hộ tuyên bố rằng UA và các thuộc tính khác có thể đóng góp thông tin phân biệt có thể đo lường được. Nó không ủng hộ việc nói rằng một UA luôn có chính xác 10 bit entropy ngày nay. Sức mạnh của dấu vân tay phụ thuộc vào dân số, cửa sổ thời gian, chính sách trình duyệt và sự kết hợp của các tín hiệu.
4. Tại sao chỉ thay đổi UA có thể phản tác dụng?
UA là khai báo khách hàng không có bằng chứng mật mã. Máy chủ không thể đọc thông tin trung thực của thiết bị từ tiêu đề này. Tuy nhiên, nó có thể kiểm tra xem các quan sát khác nhau có tương thích hợp lý hay không.
Giả sử một UA tuyên bố là trình duyệt dành cho thiết bị di động, nhưng trang không quan sát thấy điểm tiếp xúc, cửa sổ luôn giống với màn hình máy tính để bàn và Client Hints báo cáo nền tảng máy tính để bàn. Bất kỳ một quan sát nào cũng có thể có một ngoại lệ hợp pháp. Một số mâu thuẫn ổn định với nhau vẫn có thể tạo thành một mô hình có thể phân loại được.
Bài báo Panopticlick đã ghi lại các trường hợp so sánh: một số trình duyệt tuyên bố là một iPhone trong khi hỗ trợ Flash và một số Firefox UA xuất hiện cùng với các tính năng lưu trữ chỉ có trong Internet Explorer. Nghiên cứu năm 2018 FP-Scanner đã kiểm tra vấn đề này một cách có hệ thống. Một số tiện ích mở rộng chống dấu vân tay và công cụ giả mạo đã tạo ra sự không nhất quán giữa các giao diện, cho phép máy dò xác định các thuộc tính đã sửa đổi và trong một số trường hợp, suy ra trình duyệt ban đầu hoặc họ hệ điều hành.
Không phải mọi mâu thuẫn đều độc hại. Máy tính từ xa, công cụ trợ năng, chính sách doanh nghiệp, lớp tương thích và phần cứng không phổ biến đều có thể tạo ra sự kết hợp bất thường. Một hệ thống rủi ro cẩn thận nên coi sự không nhất quán là bằng chứng xác suất, không phải là lý do tự động để chặn người dùng.
Đối với quản lý hồ sơ trình duyệt, ba thuộc tính quan trọng:
- Tính nhất quán bên trong: Các tín hiệu UA, Client Hints, nền tảng, kiến trúc, cảm ứng và màn hình không được mâu thuẫn trực tiếp với nhau.
- Tính ổn định theo thời gian: một hồ sơ tồn tại lâu dài sẽ không thay đổi đáng kể ở mỗi lần ra mắt mà không có lý do.
- Sự đa dạng hợp lý: cấu hình có thể khác nhau, nhưng các kết hợp cơ học hiếm hoi không nhất thiết phải an toàn hơn.
Nghiên cứu FP-STALKER cũng chỉ ra rằng việc thay đổi các thuộc tính không tự động ngăn chặn sự liên kết. Một mô hình có thể sử dụng các thuộc tính ổn định và các thay đổi phiên bản hợp lý để kết nối các dấu vân tay trước đó và muộn hơn.
5. UA Reduction giải quyết vấn đề gì?
Một UA truyền thống được gửi với hầu hết mọi yêu cầu. Bất kỳ điểm cuối của bên thứ nhất hoặc bên thứ ba nào nhận được yêu cầu đều có thể đọc nó một cách thụ động. Chuỗi càng chính xác, mọi người nhận càng nhận được nhiều thông tin phân biệt theo mặc định.
User-Agent Reduction gói của Chromium giảm mức độ chi tiết mặc định này:
- Bắt đầu từ Chrome 101, các phiên bản phụ, bản dựng và bản vá dành cho máy tính để bàn đã giảm xuống còn
0.0.0; - các giai đoạn sau hợp nhất các phiên bản hệ điều hành máy tính để bàn, chi tiết CPU và thông tin thiết bị Android;
- Android UA rút gọn sử dụng các giá trị mô hình và nền tảng cố định như
Android 10; K; - Các trang web thực sự yêu cầu thêm chi tiết có thể yêu cầu User-Agent Client Hints.
Định dạng rút gọn có thể được tóm tắt như sau:
Mozilla/5.0 (<unified platform information>)
AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/<major version>.0.0.0 Safari/537.36
Giảm làm giảm bề mặt dấu vân tay thụ động của UA cũ. Nó không loại bỏ dấu vân tay của trình duyệt. Phiên bản chính, nền tảng rộng và trạng thái di động có thể vẫn hiển thị, trong khi các API, thuộc tính mạng và hành vi khác vẫn có thể cung cấp thông tin.
6. User-Agent Client Hints hoạt động như thế nào?
Cơ chế chung được định nghĩa trong RFC 8942, trong khi WICG User-Agent Client Hints dự thảo mô tả các lĩnh vực cụ thể của UA. Cách tiếp cận này chia thông tin đã từng tồn tại trong một chuỗi không có cấu trúc thành các trường có cấu trúc, phân biệt các gợi ý entropy thấp có thể được gửi theo mặc định với các gợi ý entropy cao mà một trang web thường yêu cầu một cách rõ ràng.
Một yêu cầu ban đầu được đơn giản hóa có thể trông như thế này:
GET /download HTTP/1.1
User-Agent: Mozilla/5.0 (...) Chrome/145.0.0.0 Safari/537.36
Sec-CH-UA: "Chromium";v="145", "Not_A Brand";v="99"
Sec-CH-UA-Mobile: ?0
Sec-CH-UA-Platform: "Windows"
Nếu máy chủ thực sự cần kiến trúc và bitness để chọn trình cài đặt, nó có thể phản hồi bằng:
HTTP/1.1 200 OK
Accept-CH: Sec-CH-UA-Arch, Sec-CH-UA-Bitness
Vary: Sec-CH-UA-Arch, Sec-CH-UA-Bitness
Khi trình duyệt hỗ trợ cơ chế và các yêu cầu về bảo mật và chính sách được đáp ứng, yêu cầu sau này có thể bao gồm:
Sec-CH-UA-Arch: "x86"
Sec-CH-UA-Bitness: "64"
Các UA Client Hints phổ biến bao gồm:
| Lĩnh vực | Mục đích điển hình | Cấp độ thông tin |
|---|---|---|
Sec-CH-UA | Danh sách thương hiệu và phiên bản chính | Thường có entropy thấp |
Sec-CH-UA-Mobile | Khách hàng có thích trải nghiệm di động hay không | Thường có entropy thấp |
Sec-CH-UA-Platform | Danh mục nền tảng rộng | Thường có entropy thấp |
Sec-CH-UA-Arch | Kiến trúc CPU | Entropy cao; Yêu cầu khi cần |
Sec-CH-UA-Bitness | Bitness kiến trúc | Entropy cao; Yêu cầu khi cần |
Sec-CH-UA-Platform-Version | Phiên bản nền tảng | Entropy cao; Yêu cầu khi cần |
Sec-CH-UA-Full-Version-List | Phiên bản đầy đủ cho các thương hiệu được báo cáo | Entropy cao; Yêu cầu khi cần |
Sec-CH-UA-Model | Kiểu thiết bị | Entropy cao; Yêu cầu khi cần |
Ba chi tiết kỹ thuật rất dễ bị bỏ sót.
1. Client Hints không phải tất cả đều được gửi tự động
Gợi ý entropy thấp có thể xuất hiện theo mặc định. Các gợi ý entropy cao thường yêu cầu phản ứng Accept-CH. Điều hướng ban đầu, tài nguyên phụ, chính sách quyền, truyền tải an toàn và hỗ trợ trình duyệt đều có thể ảnh hưởng đến những gì đến. Một máy chủ phải cho phép mọi trường tùy chọn vắng mặt.
2. Danh sách thương hiệu cố tình kiểm tra độ mạnh mẽ của trình phân tích cú pháp
Sec-CH-UA có thể chứa nhiều nhãn hiệu và một thương hiệu tổng hợp được sử dụng để kiểm tra khả năng tương thích. Code không được giả định rằng mục nhập đầu tiên luôn là tên sản phẩm và nó không được thất bại khi một thương hiệu không xác định xuất hiện. Phân tích cú pháp trường có cấu trúc, bỏ qua các mục bạn không nhận ra và để lại chỗ cho các thương hiệu trong tương lai.
3. Các phản hồi khác nhau về gợi ý cần xử lý bộ nhớ cache chính xác
Nếu kiến trúc, nền tảng hoặc gợi ý khác thay đổi phản hồi, hãy định cấu hình Vary hoặc chiến lược khóa bộ nhớ đệm tương đương một cách chính xác. Nếu không, bộ nhớ đệm dùng chung có thể phân phối nội dung được tạo cho lớp thiết bị này sang lớp thiết bị khác.
7. Client Hints có riêng tư hơn UA truyền thống không?
Chúng cải thiện cách thông tin được tiếp xúc, nhưng chúng không cung cấp khả năng miễn nhiễm khỏi dấu vân tay.
UA truyền thống tiết lộ một gói lớn không có cấu trúc một cách thụ động và theo mặc định. Client Hints chia gói đó thành các trường, làm cho các yêu cầu về thông tin entropy cao hơn rõ ràng hơn và cho trình duyệt cơ hội áp dụng các biện pháp kiểm soát chính sách, quyền hoặc quyền riêng tư-ngân sách.
Tuy nhiên, kiến trúc, phiên bản đầy đủ, phiên bản nền tảng và kiểu thiết bị vẫn có thể tăng khả năng phân biệt. RFC 8942 rõ ràng coi quyền riêng tư và hiệu suất là những ràng buộc về thiết kế. Các nhà phát triển nên hỏi:
- Tính năng này có thực sự yêu cầu lĩnh vực này không?
- Phát hiện khả năng hoặc lựa chọn của người dùng có thể thay thế nó không?
- Ứng dụng có thể chỉ lưu trữ một danh mục thô không?
- Các giá trị thô được giữ lại trong bao lâu và ai có thể truy cập chúng?
- Tài nguyên của bên thứ ba có nhận được gợi ý tương tự không?
8. Hướng dẫn kỹ thuật xử lý UA phía máy chủ
1. Không bao giờ sử dụng UA làm bằng chứng về danh tính hoặc thẩm quyền
UA có thể hỗ trợ các lựa chọn bản trình bày và dự phòng tương thích. Nó không nên xác định danh tính, ủy quyền, ủy thác thanh toán hoặc ranh giới bảo mật. Giá trị do máy khách kiểm soát không thể đóng vai trò là thông tin xác thực kiểm soát truy cập.
2. Ưu tiên phát hiện khả năng hơn danh sách trình duyệt
Khi giao diện người dùng cần API, hãy kiểm tra trực tiếp khả năng đó:
if ('share' in navigator) {
// Offer the system share feature.
} else {
// Fall back to copying a link.
}
Phát hiện khả năng xử lý các trình duyệt có nguồn gốc, các tính năng thử nghiệm, chính sách doanh nghiệp và các bản phát hành trong tương lai tốt hơn so với quy tắc như "kích hoạt tính năng này cho Chrome 145".
3. Chấp nhận các trạng thái UA, Client Hints và không xác định kế thừa
Trong quá trình di chuyển, máy chủ có thể chỉ nhận được UA cũ, cả UA và Client Hints, hoặc các dạng giảm giá cao của cả hai. Mô hình dữ liệu nên cho phép unknown thay vì đoán chính xác một hệ điều hành hoặc kiểu thiết bị để điền vào mọi trường.
4. Giảm độ chi tiết của nhật ký
Nếu phân tích chỉ cần máy tính để bàn so với thiết bị di động, họ trình duyệt và phiên bản chính, đừng giữ lại chuỗi UA thô và mọi gợi ý entropy cao vô thời hạn. Giảm thiểu dữ liệu làm giảm rủi ro về quyền riêng tư và ngăn quy trình phân tích coi các biến thể nhỏ như một khía cạnh có ý nghĩa.
5. Coi sự bất thường là bằng chứng, không phải phán quyết
Một UA tuyên bố quyền sở hữu Windows trong khi một API hoạt động khác nhau, nhiều nhất, là một tín hiệu rủi ro. Môi trường doanh nghiệp, ảo hóa, phiên từ xa, lớp tương thích và công nghệ hỗ trợ có thể tạo ra các điểm bất thường hợp pháp. Biến một sự không phù hợp thành quyết định gian lận tự động sẽ tạo ra kết quả dương tính giả.
9. UA nên được cấu hình như thế nào trong môi trường nhiều cấu hình?
Đối với thử nghiệm liên khu vực, xem trước quảng cáo, hoạt động tài khoản và cách ly quyền riêng tư, mục tiêu không nên là tạo UA bất thường nhất. Một hồ sơ phải có thể giải thích được, ổn định và tương thích với môi trường xung quanh.
Xem lại những điều sau theo thứ tự:
- Phiên bản trình duyệt: phiên bản chính UA phải hợp lý với công cụ thực tế và khả năng của nó.
- Hệ điều hành: nền tảng UA, nền tảng Client Hints và danh mục nền tảng hiển thị JavaScript phải tương thích.
- Kiến trúc và bitness: UA, Client Hints và môi trường thực thi không nên đưa ra các tuyên bố mâu thuẫn trực tiếp.
- Yếu tố hình thức thiết bị: Khai báo trên thiết bị di động phải có ý nghĩa cùng với hỗ trợ chạm, khung nhìn, tỷ lệ pixel và mẫu tương tác.
- Ngữ cảnh khu vực: ngôn ngữ, múi giờ, vị trí địa lý và đầu ra proxy không nhất thiết phải khớp một cách máy móc, nhưng chúng phải có ý nghĩa đối với quy trình làm việc thực tế.
- Độ ổn định của hồ sơ: khi một tài khoản hoặc danh tính thử nghiệm sử dụng lại hồ sơ tồn tại lâu dài, hãy tránh chuyển đổi nền tảng và phiên bản chính mà không có lý do.
Chuyển đổi hồ sơ hiện tại của PurpleMark ánh xạ hệ điều hành đã chọn với nền tảng UA và trước tiên cố gắng trích xuất phiên bản trình duyệt từ mã thông báo Chrome/ hoặc CriOS/ đã định cấu hình. Khi không có phiên bản có thể sử dụng được, nó sẽ có được một dự phòng hợp lý từ phiên bản chính của động cơ hiện tại. Mục đích không phải là giả mạo một chuỗi riêng biệt, mà là đặt cấu hình UA bên trong một mô hình hồ sơ trình duyệt nhất quán.
Cách ly hồ sơ và tính nhất quán của tham số có thể làm giảm mối tương quan kỹ thuật và sai lệch thử nghiệm. Chúng không thể đảm bảo rằng các tài khoản sẽ không bao giờ được liên kết và chúng không thay thế các quy tắc nền tảng, dữ liệu tài khoản, thông tin thanh toán hoặc thực tiễn hoạt động có trách nhiệm. Chỉ sử dụng các chức năng này để bảo vệ quyền riêng tư hợp pháp, thử nghiệm được ủy quyền và hoạt động kinh doanh tuân thủ.
10. Những câu hỏi thường gặp
Q1: Thay đổi UA có biến trình duyệt thành một trình duyệt khác không?
Không. Nó thay đổi một phần những gì khách hàng khai báo. Nó không thay thế công cụ JavaScript, quy trình kết xuất, ngăn xếp mạng hoặc API Web được hỗ trợ.
Câu hỏi 2: Một trang web có thể đọc được "UA thật" không?
Không có "UA thực" cấp phần cứng phổ quát mà mọi trang web đều có thể bỏ qua trình duyệt để đọc. Tuy nhiên, một trang web có thể so sánh Client Hints, kiểm tra khả năng và các tín hiệu vân tay khác, tìm các tuyên bố không tương thích và đưa ra suy luận xác suất.
Câu hỏi 3: UA rút gọn có thể phân biệt Windows 10 với Windows 11 không?
Di sản giảm UA thường không thể làm như vậy một cách đáng tin cậy vì cả hai đều có thể báo cáo Windows NT 10.0. Trình duyệt hỗ trợ UA Client Hints có thể cung cấp thông tin phiên bản nền tảng chi tiết hơn sau khi trang web yêu cầu. Máy chủ vẫn phải xử lý các trường bị thiếu và ánh xạ khác biệt.
Q4: Tắt JavaScript có ngăn chặn phơi sáng UA không?
Không hoàn toàn. HTTP User-Agent là tiêu đề yêu cầu và có thể được gửi cùng với yêu cầu trang trước khi trang JavaScript chạy. Vô hiệu hóa JavaScript loại bỏ một số bề mặt bộ sưu tập nhưng cũng phá vỡ các phần đáng kể của web hiện đại.
Q5: Liệu Client Hints có thay thế hoàn toàn User-Agent?
Đừng cho rằng trong thời gian tới. Nhiều máy khách và máy chủ vẫn phụ thuộc vào UA cũ, trong khi hỗ trợ UA Client Hints khác nhau. Coi Client Hints là cải tiến tiến bộ: ưu tiên thông tin có cấu trúc khi có sẵn, nhưng giữ lại dự phòng cho các trạng thái UA cũ và không xác định.
Câu hỏi 6: UA được tạo ngẫu nhiên có cải thiện tính ẩn danh không?
Không nhất thiết. Ngẫu nhiên hóa một trường có thể tạo ra mâu thuẫn với các tín hiệu phiên bản, nền tảng, cảm ứng và kết xuất. Đối với một hồ sơ tồn tại lâu dài, một cấu hình phổ biến, ổn định, tương thích bên trong thường dễ bảo vệ hơn so với các thay đổi ngẫu nhiên thường xuyên.
11. Kết luận
User-Agent không phải là thông tin xác thực danh tính đáng tin cậy cũng không phải là chuỗi không liên quan. Nó nằm ở giao điểm của khả năng tương thích web, quyền riêng tư và phân tích rủi ro. Đối với các nhà phát triển, nó là một đầu vào tương thích bị gánh nặng bởi lịch sử. Đối với các nhà nghiên cứu lấy dấu vân tay, nó là một thuộc tính với thông tin thống kê có thể đo lường được. Đối với các nhà cung cấp trình duyệt, đây là bề mặt phơi sáng mặc định cần được giảm bớt.
Các ý tưởng chính phù hợp với ba tuyên bố:
- Đừng đọc một UA theo nghĩa đen; Nó chứa nhiều mã thông báo tương thích lịch sử.
- Không đánh giá UA một cách cô lập; Nhận biết thực tế đến từ sự kết hợp của các tín hiệu và sự phát triển của chúng theo thời gian.
- Đừng nghĩ về Client Hints chỉ đơn thuần là "những lĩnh vực UA hơn"; Giá trị của chúng nằm ở việc tiết lộ có cấu trúc, theo yêu cầu, có thể quản lý.
Khi một hệ thống chuyển từ việc xác định tên trình duyệt sang kiểm tra khả năng cần thiết – và từ việc thu thập mọi chi tiết có sẵn sang chỉ yêu cầu những gì cần thiết – UA sẽ trở lại vai trò thích hợp của nó: một manh mối tương thích, không phải sự thật về danh tính.
Tài liệu tham khảo và tiêu chuẩn
- Peter Eckersley. How Unique Is Your Web Browser?. Privacy Enhancing Technologies Symposium, 2010.
- Pierre Laperdrix, Nataliia Bielova, Benoit Baudry, Gildas Avoine. Browser Fingerprinting: A Survey. ACM Transactions on the Web, 2020.
- Antoine Vastel, Pierre Laperdrix, Walter Rudametkin, Romain Rouvoy. FP-Scanner: The Privacy Implications of Browser Fingerprint Inconsistencies. USENIX Security Symposium, 2018.
- Antoine Vastel, Pierre Laperdrix, Walter Rudametkin, Romain Rouvoy. FP-STALKER: Tracking Browser Fingerprint Evolutions. IEEE Symposium on Security and Privacy, 2018.
- IETF. RFC 9110: HTTP Semantics, 2022.
- IETF. RFC 8942: HTTP Client Hints, 2021.
- WICG. User-Agent Client Hints, Draft Community Group Report.
- Chromium. User-Agent Reduction.
- Chrome for Developers. Improve user privacy and developer experience with User-Agent Client Hints.