ITP của Safari hoạt động ra sao, từng cơ chế một: phân loại bên theo dõi, giới hạn lưu trữ 7 ngày, chặn cookie, cắt referrer và những gì nó không ngăn được.
"Safari có chặn trình theo dõi không?" có một câu trả lời ngắn — có — và một câu trả lời dài hữu ích hơn nhiều. Intelligent Tracking Prevention (ITP) không phải là một công tắc đơn lẻ. Nó là một chồng các cơ chế riêng biệt trong WebKit, mỗi cơ chế nhắm vào một cách khác nhau để mang định danh từ trang này sang trang khác: một bộ phân loại gắn nhãn các tên miền có khả năng theo dõi, lệnh chặn cứng cookie bên thứ ba, giới hạn thời gian script được giữ dữ liệu, việc cắt bớt referrer, và nhiều thứ khác. Bài hướng dẫn này đi qua từng cơ chế một và với mỗi cơ chế đều đặt cùng ba câu hỏi: nó làm gì, bên theo dõi mất gì, và một trang web bình thường mất gì?
Điểm chính
- ITP là một chồng cơ chế, không phải một tính năng. Theo tài liệu Tracking Prevention của WebKit, nó kết hợp chặn cookie bên thứ ba, hạ cấp referrer, phân loại bên theo dõi ngay trên thiết bị, xóa dữ liệu lưu trữ và giới hạn thời hạn.
- "Giới hạn 7 ngày" áp dụng cho bộ nhớ do script ghi. WebKit xóa cookie được tạo bằng JavaScript, cùng
localStorage, IndexedDB,sessionStorage, media key, và các service worker registration cùng cache của chúng, sau 7 ngày người dùng không tương tác với trang. - Cookie bên thứ ba bị chặn hoàn toàn. WebKit khẳng định không có ngoại lệ; quyền truy cập chỉ được cấp qua Storage Access API (và một bản vá tương thích tạm thời cho popup).
- ITP chỉ là lớp phòng thủ dựa trên trạng thái. Nó loại bỏ các định danh đã lưu và bộ nhớ dùng chung. Nó không ngăn một trang thu thập dữ liệu về chính khách truy cập của mình, và cũng không phải hệ thống chống lấy dấu vân tay — WebKit xử lý dấu vân tay bằng một nhóm thay đổi riêng.
- Trên iOS, nó áp dụng cho mọi trình duyệt. Vì mọi trình duyệt trên iPhone đều dựng trang bằng WebKit, hành vi của ITP không phải thứ chỉ có khi bạn chọn Safari — xem vì sao mọi trình duyệt trên iOS thực chất là Safari.
ITP bắt đầu từ đâu, và vì sao trang tài liệu quan trọng
WebKit giới thiệu ITP vào tháng 6 năm 2017. Thông báo ban đầu, Intelligent Tracking Prevention của John Wilander, mô tả nó như một cách giảm theo dõi liên trang bằng việc "hạn chế thêm cookie và các dữ liệu website khác", và nó được xây dựng trên một mặc định vốn đã lâu đời: từ Safari 1.0, WebKit đã không cho bên thứ ba đặt cookie mới nếu nó chưa có cookie nào.
Thiết kế ban đầu đó đã thay đổi. Ở phiên bản 2017, một tên miền bị phân loại mà người dùng đã tương tác trong 24 giờ gần nhất vẫn được dùng cookie của mình trong ngữ cảnh bên thứ ba; nếu tương tác nằm trong 30 ngày gần nhất, nó vẫn giữ cookie nhưng ở dạng đã phân vùng. Tài liệu WebKit hiện tại mô tả việc chặn cookie bên thứ ba là tuyệt đối. Đó là lý do lịch sử phiên bản theo trình tự thời gian là cách học ITP không hiệu quả — nó nhanh lỗi thời. Tài liệu tham chiếu được duy trì là trang Tracking Prevention của WebKit, và phần còn lại của bài viết bám theo trang đó.
Cơ chế 1: phân loại các tên miền có khả năng theo dõi
Nó làm gì. ITP thu thập thống kê về các lượt tải tài nguyên và đối chiếu chúng với những mẫu theo dõi liên trang đã biết. Nếu một registrable domain khớp với một mẫu, nó bị phân loại là có khả năng theo dõi liên trang. Một mô hình học máy xem xét ba con số: tên miền đó đã xuất hiện trên bao nhiêu trang khác nhau dưới dạng subresource bên thứ ba, bao nhiêu trang dưới dạng iframe bên thứ ba, và nó đã thực hiện redirect liên trang trên bao nhiêu trang. Trong thông báo năm 2017, WebKit nói toàn bộ việc thu thập dữ liệu và phân loại diễn ra ngay trên thiết bị.
Hai mẫu nữa cũng góp vào cùng một nhãn. Các redirect top-frame lặp lại (bounce tracking) được tính, kể cả khi redirect bị trì hoãn vài giây. Và tracker collusion (thông đồng giữa các bên theo dõi) lan nhãn này ra: khi một tên miền đã bị phân loại, mọi tên miền từng redirect tới nó cũng bị phân loại, đệ quy qua toàn bộ đồ thị redirect.
Bên theo dõi mất gì. Một tên miền bị phân loại sẽ bị xóa toàn bộ dữ liệu website, trừ khi trong 30 ngày sử dụng trình duyệt gần nhất nó có tương tác của người dùng ở vai trò bên thứ nhất, hoặc được cấp quyền truy cập bộ nhớ. Một tên miền chỉ xuất hiện ngầm ở nền sẽ không bao giờ có được tương tác đó, nên nó không bao giờ giữ lại được gì.
Trang web bình thường mất gì. Không mất gì, trừ khi nó trông giống một bên theo dõi. Một trang bạn thực sự dùng sẽ được tính điểm tương tác, và đó chính là ngoại lệ. Cái giá rơi vào các dịch vụ nhúng hợp pháp mà người dùng hiếm khi truy cập trực tiếp — một nhà cung cấp widget mà bạn chưa bao giờ mở trong tab riêng có thể bị nhận nhầm là bên theo dõi.
Cơ chế 2: chặn hoàn toàn cookie bên thứ ba
Nó làm gì. Chính sách cookie mặc định của WebKit, có hiệu lực từ Safari 1.0, không cho bên thứ ba đặt cookie mới trừ khi nó đã có cookie sẵn. ITP đi xa hơn: theo mặc định nó chặn mọi cookie bên thứ ba, không có ngoại lệ. Hai quy tắc liên quan bịt các cửa phụ. Latch mode nghĩa là một khi một yêu cầu bị chặn dùng cookie, mọi redirect của yêu cầu đó cũng bị chặn. Và HSTS của bên thứ ba bị chặn: nó chỉ có thể do chính website bên thứ nhất đặt, cho host và registrable domain của chính nó.
Bên theo dõi mất gì. Cơ chế kinh điển: một tên miền quảng cáo hoặc phân tích được tải trên nhiều trang sẽ đọc cùng một cookie ở mỗi trang. Dưới ITP, cookie đó không bao giờ được gửi đi, nên bên theo dõi lần nào cũng thấy một người lạ.
Trang web bình thường mất gì. Mọi dịch vụ nhúng dựa vào cookie bên thứ ba dùng chung: frame đăng nhập một lần (single sign-on), hệ thống bình luận nhúng nhận ra người dùng đã đăng nhập, widget thanh toán. Chúng phải xin quyền truy cập một cách tường minh (xem Cơ chế 6).
Cơ chế 3: giới hạn bộ nhớ do script ghi
Nó làm gì. Hai giới hạn áp dụng cho dữ liệu lưu trữ do JavaScript tạo ra trong ngữ cảnh bên thứ nhất, vì các bên theo dõi chạy dưới dạng script bên thứ nhất từng lưu định danh ở đó:
- 7 ngày. ITP xóa mọi cookie được tạo bằng JavaScript và mọi bộ nhớ khác mà script ghi được sau 7 ngày người dùng không tương tác với website. WebKit liệt kê các kho bị ảnh hưởng: IndexedDB, LocalStorage, media key, SessionStorage, cùng service worker registration và cache.
- 24 giờ cho link decoration. Một số bên theo dõi gắn "click ID" vào tham số URL rồi dùng script ở trang đích để lấy chúng. ITP phát hiện mẫu này và giới hạn thời hạn của cookie được tạo bằng JavaScript trên trang đích đó xuống còn 24 giờ.
Đồng hồ tính theo tương tác của người dùng — một cú nhấp, chạm hoặc gõ phím; WebKit nói cuộn trang không được tính — chứ không phải số ngày tính từ lúc tạo. Một trang bạn dùng cách vài ngày một lần sẽ giữ được dữ liệu.
Bên theo dõi mất gì. Định danh bên thứ nhất sống lâu mà một script bên thứ ba đã ghi vào bộ nhớ của chính trang. Bất kỳ khách nào quay lại sau hơn một tuần đều trông như khách mới với nó.
Trang web bình thường mất gì. Bất cứ thứ gì lưu phía client mà phải tồn tại lâu hơn một tuần không có lượt truy cập: cờ "ghi nhớ đăng nhập" đặt từ JavaScript, bản nháp lưu trong localStorage, cookie tùy chọn. Những trang cần trạng thái bền vững nên lưu phía server hoặc đặt nó từ phản hồi của server. Trang của WebKit cũng ghi chú rằng web app trên màn hình chính (home screen web app) được miễn giới hạn 7 ngày và được tách biệt khỏi dữ liệu của chính Safari.
Cơ chế 4: hạ cấp referrer
Nó làm gì. Theo mặc định, mọi referrer bên thứ ba đều bị cắt xuống còn origin, ở cả header HTTP Referer lẫn document.referrer. Ví dụ của WebKit: một referrer đầy đủ https://www.social.example/feed?clickID=123456 sẽ hiển thị thành https://www.social.example/.
Bên theo dõi mất gì. Đường dẫn và chuỗi truy vấn. Một click ID hay URL bài viết truyền qua referrer không còn đến được đích; chỉ còn trang nguồn.
Trang web bình thường mất gì. Phân tích nguồn giới thiệu chi tiết. Một trang vẫn thấy origin nào đã gửi khách đến, nhưng không thấy trang hay tham số chiến dịch nào trên origin đó.
Cơ chế 5: đối phó với redirect và bounce tracking
Nó làm gì. Bounce tracking đưa bạn thoáng qua tên miền của bên theo dõi để nó chạy như một bên thứ nhất và đọc được cookie của chính nó. ITP đếm số redirect top-frame theo từng tên miền và đưa chúng vào bộ phân loại ở Cơ chế 1. Với một tên miền bị phân loại nhưng có tương tác của người dùng hoặc quyền truy cập bộ nhớ mà lại bị phát hiện bounce, WebKit nói cookie của nó có thể bị ghi lại thành SameSite=strict — để chúng không còn được gửi trong điều hướng liên trang. Latch mode chặn cookie (Cơ chế 2) bao phủ các chuỗi redirect.
Có một biện pháp liên quan cho CNAME cloaking: khi một subdomain trông như bên thứ nhất thực ra trỏ tới một bên theo dõi bên thứ ba, ITP giới hạn thời hạn cookie đặt trong phản hồi HTTP xuống 7 ngày. WebKit áp dụng cùng giới hạn cho việc che giấu bằng địa chỉ IP của bên thứ ba. Bài giải thích về CNAME cloaking của chúng tôi bàn về chính kỹ thuật này.
Bên theo dõi mất gì. Khả năng dùng một redirect thoáng qua qua tên miền của chính mình để trở thành bên thứ nhất và lấy lại cookie.
Trang web bình thường mất gì. Các luồng dựa trên redirect hợp pháp, như bước nhảy single sign-on hay trình rút gọn liên kết, có thể trông giống bounce. Ngoại lệ tương tác bảo vệ những nhà cung cấp mà người dùng thực sự dùng. Về chính kỹ thuật này, xem bounce tracking là gì.
Cơ chế 6: Storage Access API là ngoại lệ được cho phép
Nó làm gì. Việc chặn của ITP sẽ làm hỏng các dịch vụ nhúng hợp pháp, nên WebKit bổ sung ngoại lệ: một frame bên thứ ba có thể xin quyền truy cập cookie bên thứ nhất của chính nó qua Storage Access API, thường là để đáp lại một thao tác của người dùng. MDN ghi lại API này với document.hasStorageAccess() và document.requestStorageAccess(), quyền được cấp giới hạn cho một cặp cụ thể gồm trang cấp cao nhất và trang được nhúng. Xem tài liệu tham chiếu Storage Access API của MDN để biết hành vi hiện tại và khác biệt về cách hỏi ý kiến giữa các trình duyệt.
Tài liệu của WebKit lưu ý rằng quyền truy cập bộ nhớ đã được cấp là một trong hai điều (cùng với tương tác của người dùng ở vai trò bên thứ nhất) giúp một tên miền bị phân loại khỏi bị xóa dữ liệu.
Bên theo dõi mất gì. Khả năng lấy quyền truy cập một cách âm thầm. Nó phải xin trong đúng ngữ cảnh, sau một tương tác thật, và người dùng hoặc trình duyệt có thể từ chối.
Trang web bình thường mất gì. Một chút ma sát: một phần nhúng từng hoạt động vô hình giờ cần một cú nhấp và một lần gọi API.
Lớp phân vùng bên dưới
Bên cạnh sáu cơ chế trên, tài liệu của WebKit còn mô tả một lớp phân vùng: LocalStorage và IndexedDB bên thứ ba được phân vùng theo từng website bên thứ nhất và chỉ tồn tại tạm thời, Service Worker bên thứ ba được phân vùng cùng với cache và IndexedDB của nó, và các mục HTTP cache của nội dung bên thứ ba được phân vùng theo từng website bên thứ nhất. Các mục tạo ra cho những tên miền bị phân loại là bên theo dõi còn bị đánh dấu để xác minh: sau bảy ngày, một lượt cache hit được coi là miss, tài nguyên được tải lại và so sánh, và mục đó bị loại bỏ nếu hai phản hồi khác nhau — một lớp phòng thủ chống lại các định danh dựa trên cache như ETag. Ý tưởng chung được trình bày trong phân vùng bộ nhớ.
Những gì ITP không làm
Đây là phần mà hầu hết các bài viết lướt qua, nên ở đây nói thẳng.
- Nó không ngăn thu thập dữ liệu bên thứ nhất. ITP nhắm vào theo dõi liên trang. Một trang vẫn có thể nhận ra khách quay lại của chính mình, ghi log những gì họ làm và đặt cookie trong phản hồi HTTP của chính nó. Các giới hạn nêu trên áp dụng cho bộ nhớ do script ghi; tài liệu WebKit không liệt kê cookie bên thứ nhất thông thường do server đặt trong số các kho bị ảnh hưởng (trường hợp CNAME cloaking là ngoại lệ).
- Nó không ngăn lấy dấu vân tay. Dấu vân tay được tính từ các tín hiệu của trình duyệt và phần cứng, không lưu gì cả, nên ITP không có gì để xóa, giới hạn hay phân vùng. Hãy đọc hướng dẫn về lấy dấu vân tay trình duyệt để hiểu cơ chế, hoặc chạy công cụ kiểm tra dấu vân tay để xem trình duyệt của bạn để lộ những gì.
- Nó không khiến link decoration trở nên vô hại. ITP giới hạn tuổi thọ của cookie do script ghi trên trang đích khi phát hiện click ID, nhưng một server nhận được click ID trong yêu cầu vẫn có thể ghi lại nó.
- Nó không phải là một tín hiệu yêu cầu. Header Do Not Track chỉ nhã nhặn yêu cầu các trang; ITP thì cưỡng chế. WebKit thậm chí đã gỡ cờ DNT của mình vì nó "bị dùng làm một vector lấy dấu vân tay". Xem vì sao DNT thất bại.
ITP và lấy dấu vân tay là hai hệ thống con khác nhau
Rất dễ nhập nhằng hai thứ mà WebKit giữ tách biệt. ITP quản lý trạng thái: cookie, bộ nhớ, referrer, cache và redirect. Chống lấy dấu vân tay là một nhóm thay đổi khác, được liệt kê ở một mục riêng trong cùng trang tài liệu: yêu cầu cấp quyền cho các API Device Orientation/Motion, hạn chế những gì WebRTC tiết lộ về camera và micro được gắn, giới hạn phông chữ khả dụng ở web font và phông chữ hệ thống, đóng băng chuỗi user-agent giữa các phiên bản tiếp thị, gỡ hỗ trợ plug-in trên macOS, và từ chối triển khai các tính năng như Web Bluetooth, Web MIDI và Battery Status API.
Hai nhóm có mục tiêu khác nhau và điểm yếu khác nhau. ITP đánh bại một định danh mà bên theo dõi lưu. Chống lấy dấu vân tay thu hẹp số lượng tín hiệu phân biệt sẵn có cho một định danh mà bên theo dõi tính ra. Mỗi lớp phòng thủ dựa trên trạng thái mà Safari đưa ra lại khiến con đường không lưu trạng thái tương đối có giá trị hơn đối với bên theo dõi vẫn muốn liên kết liên trang — đó là lý do một visitor ID bền vững, dựng từ các tín hiệu trình duyệt, vẫn sống sót qua mọi cơ chế nêu trên.
Câu hỏi thường gặp
Safari có chặn trình theo dõi không?
Có, bằng nhiều cách cùng lúc: chặn cookie bên thứ ba, cắt referrer bên thứ ba, phân loại các tên miền có khả năng theo dõi rồi xóa dữ liệu của chúng, và giới hạn thời gian tồn tại của bộ nhớ do script ghi. Nó không chặn mọi hình thức theo dõi — thu thập bên thứ nhất và lấy dấu vân tay vẫn còn.
Giới hạn cookie 7 ngày của ITP là gì?
Đó là giới hạn cho bộ nhớ mà script ghi được. Sau 7 ngày người dùng không tương tác với một trang, WebKit xóa cookie được tạo bằng JavaScript và các bộ nhớ khác mà script ghi được như localStorage và IndexedDB của trang đó. Tương tác với trang sẽ đặt lại đồng hồ.
ITP có áp dụng cho Chrome hay Firefox trên iPhone không?
Có, vì trên iOS các ứng dụng đó dựng trang bằng WebKit — dù tình hình cụ thể đang thay đổi ở một số khu vực, như trình bày trong vì sao mọi trình duyệt trên iPhone của bạn thực chất là Safari. Hành vi của ITP là thuộc tính của engine, không phải của thương hiệu Safari.
Tôi có thể tắt ITP không?
Tài liệu của WebKit gắn chính sách cookie mặc định với thiết lập "Prevent cross-site tracking" của Safari. Tắt nó đi khiến theo dõi liên trang dễ hơn và hiếm khi là cách đúng để sửa một phần nhúng bị hỏng; con đường được cho phép là Storage Access API.
ITP có ngăn lấy dấu vân tay trình duyệt không?
Không. ITP liên quan đến trạng thái được lưu. Lấy dấu vân tay không lưu gì cả, và các biện pháp chống lấy dấu vân tay riêng của WebKit làm giảm, nhưng không loại bỏ hoàn toàn, những gì có thể dùng để dựng một dấu vân tay.
Kết luận
ITP hiệu quả vì nó không dựa vào một mẹo duy nhất. Phân loại tìm ra bên theo dõi qua cách chúng hành xử, chặn cookie loại bỏ cookie dùng chung giữa các trang, các giới hạn lưu trữ rút ngắn những gì script có thể giữ, việc cắt referrer bỏ đi chi tiết URL, còn Storage Access API để lại cho các phần nhúng hợp pháp một lối quay lại công khai, chỉ mở khi người dùng thao tác. Những gì nó bỏ qua cũng quan trọng không kém: hồ sơ của một trang về chính khách truy cập của mình, và bất kỳ định danh nào được tính ra thay vì được lưu. Nếu muốn tự xem nhóm thứ hai đó, hãy chạy công cụ kiểm tra dấu vân tay trong Safari và so sánh với một trình duyệt khác.
Đọc thêm:
