Chuẩn bị cho việc ngừng sử dụng cookie của bên thứ ba trong Chrome. Hãy kiểm tra trang web của bạn ngay hôm nay để xem có xảy ra lỗi nào không.

Trang này được dịch bởi Cloud Translation API.

Bên thứ ba

Bên thứ ba là gì?

Hiếm khi một trang web hoàn toàn độc lập. HTTP Web Almanac cho thấy rằng hầu hết các trang web (khoảng 95%) chứa một số nội dung của bên thứ ba.

Niên giám định nghĩa nội dung của bên thứ ba là nội dung được lưu trữ trên nguồn gốc chung và công khai, được nhiều trang web sử dụng rộng rãi và không chịu ảnh hưởng của chủ sở hữu trang web cá nhân. Đây có thể là hình ảnh hoặc nội dung nghe nhìn khác như video, phông chữ hoặc chữ viết. Hình ảnh và tập lệnh chiếm nhiều hơn mọi yếu tố khác được thêm vào cùng nhau. Nội dung của bên thứ ba không cần thiết cho việc phát triển một trang web, nhưng cũng có thể là cần thiết; gần như chắc chắn bạn sẽ sử dụng nội dung được tải từ máy chủ dùng chung công khai, cho dù là phông chữ web, iframe được nhúng của video, quảng cáo hay thư viện JavaScript. Ví dụ: bạn có thể sử dụng phông chữ trên web được phân phát từ Google Fonts hoặc đo lường số liệu phân tích bằng Google Analytics; bạn có thể đã thêm nút Thích hoặc nút Đăng nhập bằng từ mạng xã hội; bạn có thể nhúng bản đồ hay video hay xử lý giao dịch mua sắm thông qua các dịch vụ của bên thứ ba; bạn có thể theo dõi lỗi và ghi nhật ký cho các nhóm phát triển của riêng mình qua công cụ giám sát bên thứ ba.

Nhằm mục đích bảo vệ quyền riêng tư, bạn nên xem xét một định nghĩa hơi khác và ít rộng hơn: tài nguyên của bên thứ ba (cụ thể là tập lệnh của bên thứ ba) được phân phát từ một nguồn gốc công khai và chung, được sử dụng rộng rãi dưới dạng hình minh hoạ, nhưng cũng do một người không phải chủ sở hữu trang web sáng tạo. Khía cạnh quyền tác giả của bên thứ ba là yếu tố quan trọng khi xem xét cách bảo vệ quyền riêng tư của người dùng khỏi người khác. Việc này sẽ dẫn bạn đến việc xem xét những rủi ro hiện có, sau đó quyết định cách thức hoặc có nên sử dụng tài nguyên của bên thứ ba dựa trên những rủi ro đó hay không. Như đã thảo luận, những thông tin này sẽ giúp bạn hiểu bối cảnh và từ đó, hiểu được bạn cần đánh đổi những gì và có ý nghĩa gì.

Nói chung, điều này không có ý nghĩa khi thảo luận về "tài nguyên của bên thứ ba": sự khác biệt giữa bên thứ nhất và bên thứ ba thực sự là về bối cảnh sử dụng tài nguyên nào đó. Tập lệnh được tải từ một trang web khác là tài nguyên của bên thứ ba và yêu cầu HTTP tải tập lệnh có thể bao gồm cookie, nhưng các cookie đó không thực sự là "cookie của bên thứ ba"; chúng chỉ là cookie và việc chúng là "bên thứ ba" hay "bên thứ nhất" phụ thuộc vào việc tập lệnh đang được tải trên một trang thuộc trang web của bạn hay một trang trên trang web của chủ sở hữu tập lệnh.

Tại sao chúng tôi sử dụng tài nguyên của bên thứ ba?

Bên thứ ba là một cách hay để thêm chức năng vào trang web của bạn. Đó có thể là những tính năng mà người dùng nhìn thấy hoặc các chức năng mà nhà phát triển không nhìn thấy (chẳng hạn như theo dõi lỗi), nhưng các tính năng đó sẽ làm giảm tải phát triển và bản thân các tập lệnh sẽ do một người khác duy trì: nhóm phát triển của dịch vụ mà bạn đang đưa vào. Tất cả điều này có hiệu quả là nhờ tính kết hợp của web: có thể tập hợp các phần lại với nhau để tạo thành một tổng thể lớn hơn tổng của chúng.

Niên giám web của Kho lưu trữ HTTP cung cấp một mô tả hay:

Bên thứ ba cung cấp một bộ sưu tập vô tận gồm các hình ảnh, video, phông chữ, công cụ, thư viện, tiện ích, trình theo dõi, quảng cáo và mọi thứ khác mà bạn có thể nghĩ đến khi nhúng vào các trang web của chúng tôi. Điều này cho phép ngay cả những người dùng không liên quan đến kỹ thuật nhất cũng có thể tạo và xuất bản nội dung lên web. Nếu không có bên thứ ba, web có thể sẽ là một phương tiện học thuật rất nhàm chán, dựa trên văn bản thay vì một nền tảng phong phú, sinh động, phức tạp, vốn không thể thiếu trong cuộc sống của nhiều người ngày nay.

Tài nguyên của bên thứ ba có thể làm những gì?

Truy cập một số thông tin

Khi bạn sử dụng tài nguyên của bên thứ ba trên trang web của mình, bất kể tài nguyên đó là gì, một số thông tin sẽ được chuyển đến bên thứ ba đó. Ví dụ: nếu bạn đưa hình ảnh từ một trang web khác vào, thì yêu cầu HTTP mà trình duyệt của người dùng thực hiện sẽ chuyển đến tiêu đề Giới thiệu cùng với URL trang của bạn, cũng như địa chỉ IP của người dùng.

Theo dõi trên nhiều trang web

Tiếp tục với ví dụ tương tự đó, khi hình ảnh tải từ trang web của bên thứ ba, hình ảnh có thể bao gồm cookie và cookie đó sẽ được gửi lại cho bên thứ ba khi người dùng yêu cầu hình ảnh đó vào lần tiếp theo. Điều này có nghĩa là bên thứ ba có thể biết rằng dịch vụ của họ đang được sử dụng trên trang web của bạn và có thể gửi lại cookie, có thể là một mã nhận dạng duy nhất cho người dùng đó. Điều này có nghĩa là lần tiếp theo người dùng truy cập vào trang web của bạn hoặc bất kỳ trang web nào khác có tài nguyên của bên thứ ba đó, cookie mã nhận dạng duy nhất đó sẽ được gửi lại. Điều này cho phép bên thứ ba xây dựng nhật ký về nơi người dùng đó truy cập: trang web của bạn, các trang web khác sử dụng cùng một tài nguyên bên thứ ba, trên toàn bộ web.

Đây là tính năng theo dõi trên nhiều trang web: cho phép bên thứ ba thu thập nhật ký hoạt động của người dùng trên nhiều trang web, miễn là các trang web đó đều sử dụng tài nguyên từ cùng một bên thứ ba. Đó có thể là phông chữ, hình ảnh hoặc biểu định kiểu — tất cả các tài nguyên tĩnh. Đó cũng có thể là một tài nguyên động: một đoạn kịch bản, một nút mạng xã hội, một quảng cáo. Tập lệnh đi kèm có thể thu thập nhiều thông tin hơn nữa vì đây là tập lệnh động: tập lệnh này có thể kiểm tra trình duyệt và môi trường của người dùng, đồng thời truyền dữ liệu đó về nguồn gốc. Bất kỳ tập lệnh nào cũng có thể thực hiện điều này, chẳng hạn như các tài nguyên động không hiển thị dưới dạng tập lệnh, chẳng hạn như lượt nhúng trên mạng xã hội, quảng cáo hoặc nút chia sẻ. Nếu xem thông tin chi tiết của biểu ngữ cookie trên các trang web phổ biến, bạn có thể thấy danh sách các tổ chức có thể thêm cookie theo dõi cho người dùng, từ đó xây dựng hình ảnh về hoạt động của họ nhằm tạo hồ sơ cho người dùng đó. Có thể có hàng trăm lựa chọn. Nếu bên thứ ba cung cấp dịch vụ miễn phí, thì việc này có thể mang lại hiệu quả kinh tế cho họ là nhờ họ thu thập và sau đó kiếm tiền từ dữ liệu này.

Một hướng dẫn hữu ích về các loại vấn đề về quyền riêng tư mà trình duyệt nên bảo vệ người dùng là Mô hình mối đe doạ về quyền riêng tư mục tiêu. Đây là tài liệu vẫn đang được thảo luận tại thời điểm viết, nhưng đưa ra một số phân loại cấp cao về các loại mối đe doạ về quyền riêng tư còn tồn tại. Rủi ro từ tài nguyên của bên thứ ba chủ yếu là "nhận dạng không mong muốn trên nhiều trang web", trong đó một trang web có thể xác định cùng một người dùng trên nhiều trang web, cũng như "tiết lộ thông tin nhạy cảm", trong đó một trang web có thể thu thập thông tin mà người dùng cho là nhạy cảm.

Đây là điểm khác biệt chính: hoạt động nhận dạng không mong muốn trên nhiều trang web sẽ không hiệu quả ngay cả khi bên thứ ba không thu thập thêm thông tin nhạy cảm qua đó, vì hoạt động này sẽ lấy đi quyền kiểm soát của người dùng đối với danh tính của họ. Việc truy cập vào đường liên kết giới thiệu, địa chỉ IP và cookie của người dùng bản thân nó là sự tiết lộ không mong muốn. Việc sử dụng tài nguyên của bên thứ ba đi kèm với một phần lập kế hoạch về cách bạn sẽ sử dụng các tài nguyên đó theo cách bảo đảm quyền riêng tư. Một số công việc do bạn đảm nhận với tư cách là nhà phát triển trang web, và một số công việc do trình duyệt thực hiện với vai trò là tác nhân người dùng; tức là tác nhân làm việc thay mặt cho người dùng để tránh việc tiết lộ thông tin nhạy cảm và nhận dạng trên nhiều trang web không mong muốn khi có thể. Dưới đây, chúng tôi sẽ xem xét chi tiết hơn về các biện pháp giảm thiểu và phương pháp ở cấp trình duyệt và cấp phát triển trang web.

Mã bên thứ ba phía máy chủ

Định nghĩa trước đây của chúng tôi về bên thứ ba có cố ý thay đổi cách tiếp cận phía máy khách của HTTP Almanac (phù hợp với báo cáo của họ!), để bao gồm quyền tác giả của bên thứ ba, vì từ góc độ quyền riêng tư, bên thứ ba là bất kỳ ai biết bất kỳ điều gì về người dùng của bạn không phải là bạn.

Điều này bao gồm cả các bên thứ ba cung cấp dịch vụ mà bạn sử dụng trên máy chủ cũng như ứng dụng khách. Từ quan điểm về quyền riêng tư, bạn cũng cần phải hiểu rõ một thư viện của bên thứ ba (chẳng hạn như thư viện nào đó được đưa vào từ Lý do, Composer hoặc NuGet). Các phần phụ thuộc có truyền dữ liệu ra ngoài biên giới của bạn không? Nếu bạn truyền dữ liệu đến dịch vụ ghi nhật ký hoặc cơ sở dữ liệu được lưu trữ từ xa, cũng như đưa cả "điện thoại nhà riêng" vào cho tác giả, những thư viện đó có thể vi phạm quyền riêng tư của người dùng và do đó cần được kiểm tra. Thông thường, một bên thứ ba dựa trên máy chủ phải được bạn chuyển giao dữ liệu người dùng, nghĩa là dữ liệu mà bên đó hiển thị sẽ thuộc quyền kiểm soát của bạn nhiều hơn. Ngược lại, một bên thứ ba dựa trên ứng dụng (một tập lệnh hoặc tài nguyên HTTP có trên trang web của bạn và do trình duyệt của người dùng tìm nạp) có thể thu thập một số dữ liệu trực tiếp từ người dùng mà không cần bạn dàn xếp quá trình thu thập đó. Hầu hết học phần này sẽ đề cập đến cách xác định các bên thứ ba phía máy khách mà bạn đã chọn đưa vào và hiển thị cho người dùng của mình, vì bạn có ít khả năng dàn xếp hơn. Tuy nhiên, bạn nên cân nhắc việc bảo mật mã phía máy chủ để hiểu được thông tin liên lạc gửi đi từ mã đó và có thể ghi nhật ký hoặc chặn mọi sự cố không mong muốn. Thông tin chi tiết về cách chính xác để thực hiện việc này nằm ngoài phạm vi của chúng tôi tại đây (và rất phụ thuộc vào cách thiết lập máy chủ của bạn). Tuy nhiên, đây là một phần khác trong quan điểm của bạn về bảo mật và quyền riêng tư.

Tại sao bạn cần phải cẩn thận với các bên thứ ba?

Các tập lệnh và tính năng của bên thứ ba thực sự rất quan trọng và mục tiêu của chúng tôi với tư cách là nhà phát triển web nên tích hợp những thứ như vậy, chứ không nên từ bỏ chúng! Nhưng có thể có một số vấn đề tiềm ẩn. Nội dung của bên thứ ba có thể gây ra các vấn đề về hiệu suất và cũng có thể gây ra vấn đề bảo mật vì bạn đang đưa ra một dịch vụ bên ngoài nằm trong ranh giới tin cậy của mình. Tuy nhiên, nội dung của bên thứ ba cũng có thể gây ra vấn đề về quyền riêng tư!

Khi nói về tài nguyên của bên thứ ba trên web, bạn nên nghĩ đến các vấn đề bảo mật (cùng với những vấn đề khác) mà bên thứ ba có thể lấy cắp dữ liệu của công ty bạn, và trái ngược với các vấn đề về quyền riêng tư, tức là (cùng những vấn đề khác) bên thứ ba mà bạn đã đề cập đến đánh cắp hoặc có được quyền truy cập vào dữ liệu người dùng của bạn mà không có sự đồng ý của bạn (hoặc họ).

Ví dụ về vấn đề bảo mật: "trình duyệt web" đánh cắp thông tin thẻ tín dụng – tài nguyên của bên thứ ba có trên trang mà người dùng nhập thông tin thẻ tín dụng, có khả năng đánh cắp các thông tin thẻ tín dụng đó và gửi cho bên thứ ba độc hại. Những người tạo ra những kịch bản skimmer này rất sáng tạo trong việc tìm cách ẩn chúng. Một bản tóm tắt mô tả cách các tập lệnh skimmer bị ẩn trong nội dung của bên thứ ba, chẳng hạn như các hình ảnh dùng cho biểu trưng trang web, biểu tượng trang web và mạng xã hội, các thư viện phổ biến như jQuery, Modernizr và Trình quản lý thẻ của Google, các tiện ích trên trang web như cửa sổ trò chuyện trực tiếp và tệp CSS.

Vấn đề về quyền riêng tư hơi khác một chút. Các bên thứ ba này là một phần trong sản phẩm/dịch vụ của bạn. Để duy trì niềm tin của người dùng, bạn cần tin tưởng rằng người dùng có thể tin tưởng họ. Nếu một bên thứ ba mà bạn sử dụng thu thập dữ liệu về người dùng của bạn rồi sử dụng dữ liệu đó sai mục đích, gây khó khăn cho việc xoá/khám phá dữ liệu, bị rò rỉ dữ liệu hoặc vi phạm kỳ vọng của người dùng, thì nhiều khả năng người dùng sẽ hiểu rằng đó là sự mất niềm tin đối với dịch vụ của bạn, chứ không chỉ là với bên thứ ba. Đó là danh tiếng và mối quan hệ của bạn. Đây là lý do bạn cần tự hỏi mình: bạn có tin tưởng các bên thứ ba mà bạn đang sử dụng trên trang web của mình không?

Một số ví dụ về bên thứ ba là gì?

Nói chung, chúng tôi đang thảo luận về "bên thứ ba", nhưng thực tế có nhiều loại và họ có quyền truy cập vào lượng dữ liệu người dùng khác nhau. Ví dụ: việc thêm một phần tử <img> vào HTML (được tải từ một máy chủ khác) sẽ cung cấp cho máy chủ đó thông tin khác về người dùng của bạn so với việc thêm <iframe> hoặc phần tử <script>. Đây chỉ là các ví dụ chứ không phải là danh sách đầy đủ. Tuy nhiên, sẽ rất hữu ích nếu bạn hiểu được sự khác biệt giữa các loại mục bên thứ ba mà trang web của bạn có thể sử dụng.

Yêu cầu tài nguyên trên nhiều trang web

Tài nguyên trên nhiều trang web là bất cứ thứ gì trên trang web của bạn, được tải từ một trang web khác và không phải là <iframe> hay <script>. Ví dụ bao gồm <img>, <audio>, <video>, phông chữ web do CSS tải và hoạ tiết WebGL. Tất cả đều được tải thông qua một yêu cầu HTTP và như mô tả trước đó, các yêu cầu HTTP đó sẽ bao gồm mọi cookie do trang web khác đặt trước đó, địa chỉ IP của người dùng yêu cầu và URL của trang hiện tại dưới dạng đường liên kết giới thiệu. Theo mặc định, tất cả yêu cầu của bên thứ ba trước đây đều bao gồm dữ liệu này, mặc dù chúng tôi đã nỗ lực giảm hoặc tách riêng dữ liệu được chuyển đến bên thứ ba bằng các trình duyệt khác nhau, như được mô tả trong phần "Tìm hiểu thêm về các Biện pháp bảo vệ trình duyệt của bên thứ ba".

Nhúng iframe trên nhiều trang web

Tài liệu hoàn chỉnh được nhúng trong các trang của bạn qua <iframe> có thể yêu cầu thêm quyền truy cập vào các API trình duyệt, ngoài bộ 3 cookie, địa chỉ IP và đường liên kết giới thiệu. Danh sách API được cung cấp chính xác cho các trang <iframe>d và cách những API đó yêu cầu quyền truy cập tuỳ theo trình duyệt và hiện đang trải qua các thay đổi: xem "Chính sách về quyền" bên dưới để biết các nỗ lực hiện tại nhằm hạn chế hoặc giám sát quyền truy cập vào API trong các tài liệu được nhúng.

Thực thi JavaScript trên nhiều trang web

Việc bao gồm phần tử <script> sẽ tải và chạy JavaScript trên nhiều trang web trong ngữ cảnh cấp cao nhất của trang. Tức là tập lệnh chạy có quyền truy cập đầy đủ vào mọi hoạt động mà tập lệnh của bên thứ nhất thực hiện. Quyền của trình duyệt vẫn quản lý dữ liệu này, vì vậy, việc yêu cầu thông tin vị trí của người dùng (chẳng hạn) vẫn cần có sự đồng ý của người dùng. Nhưng mọi thông tin có trong trang hoặc có sẵn dưới dạng biến JavaScript đều có thể được đọc bằng tập lệnh như vậy, và điều này không chỉ bao gồm cookie được chuyển đến bên thứ ba như một phần của yêu cầu, mà còn bao gồm cookie dành riêng cho trang web của bạn. Tương tự, tập lệnh của bên thứ ba được tải vào trang của bạn có thể thực hiện tất cả các yêu cầu HTTP tương tự như mã của bạn, nghĩa là tập lệnh đó có thể thực hiện các yêu cầu fetch() đến các API phụ trợ để lấy dữ liệu.

Đưa thư viện bên thứ ba vào phần phụ thuộc

Như đã mô tả trước đó, mã phía máy chủ của bạn cũng có thể bao gồm các phần phụ thuộc của bên thứ ba và không thể phân biệt được các phần phụ thuộc này với mã của riêng bạn; mã mà bạn đưa vào từ kho lưu trữ GitHub hoặc thư viện ngôn ngữ lập trình (npm, PyPI, Compose, v.v.) có thể đọc tất cả dữ liệu mà mã khác có thể đọc.

Hiểu rõ về bên thứ ba

Sau đó, bạn cần phải hiểu rõ về danh sách nhà cung cấp bên thứ ba của mình, cũng như quan điểm và chính sách về quyền riêng tư, hoạt động thu thập dữ liệu và trải nghiệm người dùng của họ. Sau đó, việc hiểu rõ đó sẽ trở thành một phần trong chuỗi đánh đổi của bạn: mức độ hữu ích và quan trọng của dịch vụ, cân bằng với mức độ xâm phạm, bất tiện hoặc làm khó chịu nhu cầu của người dùng. Nội dung của bên thứ ba mang lại giá trị bằng cách đảm nhận phần công việc nặng nhọc của chủ sở hữu trang web và cho phép bạn tập trung vào các năng lực cốt lõi của mình. Vì vậy, việc đánh đổi cũng như hy sinh sự thoải mái và quyền riêng tư của người dùng để có trải nghiệm tốt hơn là một điều đáng lợi. Tuy nhiên, điều quan trọng là không được nhầm lẫn trải nghiệm người dùng với trải nghiệm của nhà phát triển: "nhóm nhà phát triển của chúng tôi xây dựng dịch vụ dễ dàng hơn" không phải là một câu chuyện hấp dẫn với người dùng.

Việc hiểu rõ đó là quá trình kiểm tra.

Kiểm tra các bên thứ ba

Hiểu rõ những việc bên thứ ba thực hiện là quy trình kiểm tra. Bạn có thể thực hiện việc này cả về mặt kỹ thuật lẫn phi kỹ thuật, cũng như cho một bên thứ ba riêng lẻ và cho toàn bộ bộ sưu tập của mình.

Thực hiện một cuộc kiểm tra không mang tính kỹ thuật

Bước đầu tiên không liên quan đến kỹ thuật: đọc chính sách quyền riêng tư của nhà cung cấp của bạn. Nếu bạn cung cấp tài nguyên bên thứ ba, vui lòng kiểm tra chính sách quyền riêng tư. Những tài liệu này sẽ dài và đầy văn bản pháp lý, đồng thời một số tài liệu có thể sử dụng một số phương pháp được cảnh báo cụ thể đối với trong các mô-đun trước, chẳng hạn như những tuyên bố quá chung chung và không có bất kỳ chỉ báo nào về cách thức hoặc thời điểm dữ liệu đã thu thập sẽ bị xoá. Bạn cần hiểu rằng từ góc độ người dùng, tất cả dữ liệu được thu thập trên trang web của bạn, kể cả dữ liệu do các bên thứ ba thu thập, đều sẽ chịu sự điều chỉnh của các chính sách quyền riêng tư này. Ngay cả khi bạn làm mọi thứ đúng cách, nếu bạn minh bạch về mục tiêu của mình và vượt quá kỳ vọng của người dùng về quyền riêng tư cũng như độ nhạy của dữ liệu, thì người dùng cũng có thể phải chịu trách nhiệm cho mọi việc mà bên thứ ba mà bạn chọn. Nếu có điều gì trong chính sách quyền riêng tư của họ mà bạn không muốn đề cập trong chính sách của mình vì điều đó làm giảm niềm tin của người dùng, hãy cân nhắc xem có nhà cung cấp nào khác không.

Đây là một tính năng hữu ích có thể kết hợp với việc kiểm tra kỹ thuật đã thảo luận thêm ở phần sau, vì chúng cung cấp thông tin cho nhau. Bạn nên biết các tài nguyên của bên thứ ba mà bạn đang kết hợp vì lý do kinh doanh (chẳng hạn như mạng quảng cáo hoặc nội dung được nhúng) vì trong đó có một mối quan hệ kinh doanh. Đây là nơi phù hợp để bắt đầu kiểm tra phi kỹ thuật. Quá trình kiểm tra kỹ thuật cũng có thể xác định các bên thứ ba, đặc biệt là những bên được đưa vào vì lý do kỹ thuật thay vì lý do kinh doanh (các thành phần bên ngoài, phân tích, thư viện tiện ích). Danh sách đó có thể kết hợp với danh sách các bên thứ ba tập trung vào hoạt động kinh doanh. Mục tiêu ở đây là để chủ sở hữu trang web cảm thấy mình hiểu rõ công việc mà các bên thứ ba mà bạn thêm vào trang web của mình đang làm.

Tiến hành kiểm tra kỹ thuật

Đối với quy trình kiểm tra về mặt kỹ thuật, bạn phải sử dụng các tài nguyên tại chỗ như một phần của trang web; nghĩa là đừng tải phần phụ thuộc vào phần khai thác kiểm thử và kiểm tra phần phụ thuộc đó theo cách đó. Hãy đảm bảo rằng bạn thấy được cách các phần phụ thuộc hoạt động như một phần của trang web thực tế, được triển khai trên Internet công cộng thay vì trong chế độ thử nghiệm hoặc phát triển. Việc xem trang web của riêng bạn như một người dùng mới là điều cần thiết. Mở một trình duyệt trong hồ sơ mới để bạn không đăng nhập và chưa có thoả thuận nào được lưu trữ, rồi thử truy cập vào trang web của bạn.

Lưu ý: Việc kiểm tra một trang web như thể bạn là người dùng mới có nghĩa là xem trang web đó mà không có thông tin nào được lưu. Trong các trường hợp này, tốt nhất bạn nên tạo một hồ sơ hoàn toàn mới mỗi khi muốn kiểm tra một trang web như thể bạn là người dùng mới. Đừng tạo một hồ sơ mới rồi sử dụng lại. Hãy tạo một hồ sơ mới mỗi lần bạn tạo rồi loại bỏ hồ sơ đó. Đây chủ yếu là một quy trình nhanh trên trình duyệt dành cho máy tính: hãy xem tài liệu dành cho Chrome, Edge và Firefox. Chrome dành cho Android và Safari không hỗ trợ tạo hồ sơ trống mới, vì vậy chế độ duyệt web ẩn danh/riêng tư sẽ được đáp ứng, nhưng nhìn chung, điều quan trọng là phải kiểm tra các trang web ở cả chế độ duyệt web ẩn danh/riêng tư và với hồ sơ mới tạo.

Đăng ký tài khoản mới trên trang web của bạn nếu bạn cung cấp tài khoản người dùng. Nhóm thiết kế của bạn sẽ sắp xếp quy trình thu nạp người dùng mới này từ góc độ trải nghiệm người dùng, nhưng quy trình này từ góc độ quyền riêng tư có thể minh hoạ là cách minh hoạ. Đừng chỉ nhấp vào "Chấp nhận" trên các điều khoản và điều kiện, cảnh báo về cookie hay chính sách quyền riêng tư; hãy tự đặt cho mình nhiệm vụ sử dụng dịch vụ của riêng bạn mà không tiết lộ bất kỳ thông tin cá nhân nào hay có bất kỳ cookie theo dõi nào, đồng thời xem liệu bạn có thể thực hiện việc này hay không cũng như mức độ khó thực hiện. Bạn cũng nên xem xét các công cụ cho nhà phát triển của trình duyệt để xem trang web nào đang được truy cập và dữ liệu nào được chuyển đến các trang web đó. Công cụ cho nhà phát triển cung cấp danh sách các yêu cầu HTTP riêng biệt (thường trong một phần có tên là "Mạng") và từ đây, bạn có thể thấy các yêu cầu được nhóm theo loại (HTML, CSS, hình ảnh, phông chữ, JavaScript, yêu cầu do JavaScript khởi tạo). Bạn cũng có thể thêm một cột mới để hiển thị miền của mỗi yêu cầu. Cột này sẽ cho biết có bao nhiêu địa điểm đang được liên hệ và có thể có hộp đánh dấu "yêu cầu của bên thứ ba" để chỉ hiển thị các bên thứ ba. (Bạn cũng có thể sử dụng báo cáo Content-Security-Policy để thực hiện kiểm tra liên tục để đọc thêm.)

Công cụ "Request Map Generator" (Trình tạo bản đồ yêu cầu) của Simon Listenne, cũng có thể là nơi cung cấp thông tin tổng quan hữu ích về tất cả các yêu cầu phụ mà một trang công khai đưa ra.

Đây cũng là điểm mà bạn có thể đưa vào các bên thứ ba tập trung vào hoạt động kinh doanh được xác định trong quá trình kiểm tra phi kỹ thuật (tức là danh sách các công ty mà bạn có mối quan hệ tài chính để sử dụng tài nguyên của họ). Mục tiêu ở đây là so khớp danh sách bên thứ ba mà bạn tin rằng bạn đang sử dụng (từ hồ sơ tài chính và pháp lý) với danh sách bạn đang thực sự sử dụng (bằng cách xem trang web của bạn thực hiện yêu cầu HTTP nào của bên thứ ba). Bạn có thể xác định cho từng bên thứ ba của doanh nghiệp những yêu cầu kỹ thuật đi được gửi đi. Nếu không thể xác định các yêu cầu trong quá trình kiểm tra kỹ thuật cho một bên thứ ba được xác định theo mối quan hệ kinh doanh, thì bạn cần phải tìm ra lý do và lấy hướng dẫn kiểm thử: có thể tài nguyên bên thứ ba đó chỉ được tải ở một quốc gia cụ thể, trên một loại thiết bị cụ thể, hoặc dành cho người dùng đã đăng nhập. Thao tác này sẽ mở rộng danh sách các khu vực trang web của bạn để kiểm tra và đảm bảo rằng bạn nhìn thấy tất cả các lần truy cập đầu ra. (Hoặc khả năng là xác định được tài nguyên của bên thứ ba mà bạn đang trả tiền và không sử dụng, việc này luôn mang đến niềm vui cho bộ phận tài chính.)

Sau khi bạn thu hẹp danh sách yêu cầu gửi cho bên thứ ba mà bạn muốn tham gia kiểm tra, việc nhấp vào từng yêu cầu sẽ hiển thị tất cả thông tin chi tiết về yêu cầu và cụ thể là dữ liệu nào đã được chuyển đến yêu cầu đó. Một điều rất phổ biến là một yêu cầu của bên thứ ba mà mã của bạn khởi tạo rồi tiếp tục thực hiện nhiều yêu cầu khác của bên thứ ba. Các bên thứ ba bổ sung này cũng được "nhập" vào chính sách quyền riêng tư của riêng bạn. Tác vụ này tốn nhiều công sức nhưng có giá trị và thường có thể được đưa vào các hoạt động phân tích hiện có; nhóm phát triển giao diện người dùng của bạn nên kiểm tra các yêu cầu vì lý do hiệu suất (có thể với sự trợ giúp của các công cụ hiện có như WebPageTest hoặc Lighthouse) và kết hợp kiểm tra dữ liệu và quyền riêng tư vào quy trình đó có thể giúp bạn dễ dàng hơn.

Bản đồ yêu cầu web.dev. — Sơ đồ yêu cầu (được đơn giản hoá đáng kể) dành cho web.dev, thể hiện những trang web bên thứ ba yêu cầu trang web của bên thứ ba khác, v.v.

Nên

Mở một trình duyệt có hồ sơ người dùng mới để bạn chưa đăng nhập và chưa lưu trữ thoả thuận nào; sau đó mở bảng điều khiển Mạng của công cụ phát triển trình duyệt để xem tất cả các yêu cầu gửi đi. Thêm một cột mới để hiển thị miền của từng yêu cầu và chọn hộp đánh dấu "yêu cầu của bên thứ ba" để chỉ hiển thị bên thứ ba (nếu có). Sau đó:

Truy cập vào trang web của bạn.
Đăng ký tài khoản mới nếu bạn cung cấp tài khoản người dùng.
Hãy thử xoá tài khoản bạn đã tạo.
Thực hiện một hoặc hai thao tác thông thường trên trang web (chính xác thao tác này sẽ phụ thuộc vào chức năng của trang web, nhưng hãy chọn thao tác phổ biến mà hầu hết người dùng thực hiện).
Thực hiện một hoặc hai hành động mà bạn biết là có liên quan đến các phần phụ thuộc của bên thứ ba cụ thể. Những cách này có thể bao gồm việc chia sẻ nội dung lên mạng xã hội, bắt đầu quy trình thanh toán hoặc nhúng nội dung từ một trang web khác.

Khi thực hiện mỗi tác vụ này, hãy ghi lại các tài nguyên được yêu cầu từ các miền không phải của bạn, bằng cách xem bảng điều khiển Mạng như mô tả. Đây là một số bên thứ ba của bạn. Một cách hữu ích để thực hiện việc này là sử dụng các công cụ mạng của trình duyệt để ghi nhật ký yêu cầu mạng vào tệp HAR.

Tệp HAR và tính năng ghi

Tệp HAR là một định dạng JSON chuẩn của tất cả các yêu cầu mạng do một trang đưa ra. Để tải tệp HAR cho một trang cụ thể, trong:

Chrome

Mở Công cụ cho nhà phát triển của trình duyệt (Trình đơn > Công cụ khác > Công cụ dành cho nhà phát triển), chuyển đến Bảng điều khiển mạng, tải (hoặc làm mới) trang và chọn biểu tượng lưu theo mũi tên xuống ở trên cùng bên phải gần trình đơn thả xuống Không điều tiết.

Firefox

Mở công cụ cho nhà phát triển trình duyệt (Trình đơn > Công cụ khác > Công cụ dành cho nhà phát triển web), chuyển đến Bảng điều khiển mạng, tải (hoặc làm mới) trang và chọn biểu tượng bánh răng ở trên cùng bên phải bên cạnh trình đơn thả xuống điều tiết. Trên trình đơn của màn hình, hãy chọn Save All As HAR** (Lưu tất cả dưới dạng bộ nhớ HAR).

Safari

Mở công cụ cho nhà phát triển của trình duyệt (Trình đơn > Phát triển > Hiển thị Trình kiểm tra web; nếu bạn không có trình đơn Phát triển, hãy bật trình đơn này từ Trình đơn > Safari > Lựa chọn ưu tiên > Nâng cao > Hiện trình đơn Phát triển trong thanh trình đơn), chuyển đến Bảng điều khiển mạng, tải (hoặc làm mới) trang và chọn Xuất ở trên cùng bên phải (bên phải Bảo tồn nhật ký; bạn có thể cần phóng to cửa sổ).

Để biết thêm chi tiết, bạn cũng có thể ghi lại nội dung được chuyển cho bên thứ ba (trong phần Yêu cầu), mặc dù dữ liệu này thường bị làm rối và không thể hiểu được một cách hữu ích.

Các phương pháp hay nhất khi tích hợp bên thứ ba

Bạn có thể đặt chính sách của riêng mình về các bên thứ ba mà trang web của bạn sử dụng: thay đổi nhà cung cấp quảng cáo mà bạn sử dụng dựa trên cách thức của họ, hoặc cửa sổ bật lên yêu cầu đồng ý sử dụng cookie của họ gây khó chịu hoặc xâm phạm, hoặc bạn muốn sử dụng các nút mạng xã hội trên trang web hay theo dõi các đường liên kết trong email hay đường liên kết utm_campaign để theo dõi trong Google Analytics trong các tweet của bạn. Một khía cạnh cần xem xét trong quá trình phát triển trang web là khả năng bảo vệ quyền riêng tư và bảo mật của dịch vụ phân tích. Một số dịch vụ phân tích đánh đổi rõ ràng về việc bảo vệ quyền riêng tư. Thông thường, cũng có nhiều cách để sử dụng tập lệnh của bên thứ ba để tự thêm tính năng bảo vệ quyền riêng tư: bạn không phải là nhóm đầu tiên muốn cải thiện quyền riêng tư của người dùng và bảo vệ họ khỏi việc thu thập dữ liệu của bên thứ ba và có thể đã có các giải pháp. Cuối cùng, nhiều nhà cung cấp bên thứ ba hiện trở nên nhạy cảm hơn với các vấn đề về thu thập dữ liệu so với trước đây và thường có các tính năng hoặc tham số mà bạn có thể thêm vào để kích hoạt chế độ bảo vệ người dùng tốt hơn. Dưới đây là một số ví dụ.

Khi thêm nút chia sẻ trên mạng xã hội

Hãy cân nhắc việc nhúng trực tiếp các nút HTML: trang web https://sharingbuttons.io/ có một số ví dụ thiết kế hợp lý. Hoặc bạn có thể thêm các đường liên kết HTML thuần tuý. Sự đánh đổi ở đây là bạn sẽ mất số liệu thống kê "số lượt chia sẻ" và khả năng phân loại khách hàng trong số liệu phân tích của Facebook. Đây là ví dụ về sự đánh đổi giữa việc sử dụng nhà cung cấp bên thứ ba và nhận ít dữ liệu phân tích hơn.

Nói chung, khi nhúng một tiện ích tương tác thuộc loại nào đó từ bên thứ ba, bạn thường có thể cung cấp một đường liên kết đến bên thứ ba đó. Điều này có nghĩa là trang web của bạn không có trải nghiệm cùng dòng, nhưng sẽ làm thay đổi quyết định chia sẻ dữ liệu với bên thứ ba từ bạn sang người dùng của bạn. Người dùng có thể chọn tương tác hoặc không tương tác theo ý muốn.

Ví dụ: bạn có thể thêm các đường liên kết cho Twitter và Facebook để chia sẻ dịch vụ của mình tại trangwebcuatoi.example.com như sau:

<a href="https://facebook.com/sharer/sharer.php?u=https%3A%2F%2Fmysite.example.com"
   rel="noopener" aria-label="Share on Facebook" target="_blank" >Share on Facebook</a>
<a href="https://twitter.com/intent/tweet/?text=My%20cool%20service!&amp;url=https%3A%2F%2Fmysite.example.com"
   rel="noopener" aria-label="Share on Twitter" target="_blank">Share on Twitter</a>

Lưu ý rằng Facebook cho phép chỉ định URL để chia sẻ, còn Twitter cho phép chỉ định URL và một số văn bản.

Khi nhúng video

Khi bạn nhúng video từ các trang web lưu trữ video, hãy tìm các tuỳ chọn bảo đảm quyền riêng tư trong mã nhúng. Ví dụ: Đối với YouTube, hãy thay thế youtube.com trong URL nhúng bằng www.youtube-nocookie.com để tránh việc theo dõi cookie được đặt cho người dùng xem trang nhúng. Bạn cũng có thể chọn "Bật chế độ tăng cường bảo mật" khi tạo đường liên kết Chia sẻ/Nhúng từ chính YouTube. Đây là một ví dụ điển hình về việc sử dụng chế độ bảo vệ người dùng tốt hơn do bên thứ ba cung cấp. (https://support.google.com/youtube/answer/171780 mô tả chi tiết hơn về vấn đề này, cũng như các tuỳ chọn nhúng khác dành riêng cho YouTube).

Các trang web video khác có ít lựa chọn hơn về vấn đề này: Ví dụ: TikTok không có cách nhúng video mà không cần theo dõi tại thời điểm viết bài này. Bạn có thể tự lưu trữ video (phương thức thay thế) nhưng có thể mất nhiều công sức hơn, đặc biệt là khi hỗ trợ nhiều thiết bị.

Giống như các tiện ích tương tác đã thảo luận trước đó, bạn thường có thể thay thế video được nhúng bằng một đường liên kết đến trang web của nhà cung cấp. Điều này ít tương tác hơn vì video sẽ không phát nội tuyến nhưng lại có lựa chọn xem cùng người dùng hay không. Bạn có thể dùng tên này làm ví dụ về "mẫu mặt tiền", tên để tự động thay thế nội dung tương tác bằng nội dung yêu cầu người dùng hành động để kích hoạt nội dung đó. Bạn có thể thay thế video TikTok đã nhúng bằng một đường liên kết thuần tuý đến trang video TikTok. Bạn có thể truy xuất và hiển thị hình thu nhỏ của video cũng như tạo đường liên kết cho video đó. Ngay cả khi nhà cung cấp video đã chọn không hỗ trợ cách nhúng video mà không cần theo dõi dễ dàng, thì nhiều nhà cung cấp video cũng hỗ trợ oEmbed. Đây là một API mà khi được cung cấp đường liên kết đến video hoặc nội dung được nhúng sẽ trả về thông tin chi tiết theo chương trình, bao gồm cả hình thu nhỏ và tiêu đề. TikTok hỗ trợ tính năng oEmbedding (xem https://developers.tiktok.com/doc/embed-videos để biết thông tin chi tiết), nghĩa là bạn có thể chuyển một đường liên kết đến một video trên TikTok https://www.tiktok.com/@scout2015/video/6718335390845095173 thành siêu dữ liệu JSON về video đó bằng https://www.tiktok.com/oembed?url=https://www.tiktok.com/@scout2015/video/6718335390845095173, sau đó truy xuất một hình thu nhỏ để hiển thị. Ví dụ: WordPress thường sử dụng cách này để yêu cầu thông tin oEmbedding' cho nội dung được nhúng. Bạn có thể sử dụng tính năng này theo phương thức lập trình để hiển thị "mặt tiền" trông có tính tương tác và chuyển sang chế độ nhúng hoặc liên kết đến một video tương tác khi người dùng chọn nhấp vào video đó.

Khi nhúng tập lệnh phân tích

Analytics được thiết kế để thu thập thông tin về người dùng để có thể phân tích: mục đích của Analytics. Về cơ bản, các hệ thống phân tích là dịch vụ thu thập và hiển thị dữ liệu về quyền truy cập và người dùng. Việc này được thực hiện trên máy chủ của bên thứ ba (như Google Analytics) để dễ dàng triển khai. Ngoài ra, còn có các hệ thống phân tích tự lưu trữ như https://matomo.org/, mặc dù việc này tốn nhiều công sức hơn so với việc sử dụng giải pháp của bên thứ ba cho việc này. Tuy nhiên, việc chạy một hệ thống như vậy trên cơ sở hạ tầng của riêng bạn sẽ giúp giảm việc thu thập dữ liệu, vì hệ thống này không rời khỏi hệ sinh thái của bạn. Mặt khác, bạn có trách nhiệm quản lý, xoá và đặt chính sách cho dữ liệu đó. Việc theo dõi trên nhiều trang web gây ra nhiều mối lo ngại khi hoạt động này được thực hiện một cách lén lút và bí mật hoặc như là tác dụng phụ của việc sử dụng một dịch vụ không cần chứa hoạt động thu thập dữ liệu. Phần mềm Analytics được thiết kế công khai để thu thập dữ liệu nhằm thông báo cho chủ sở hữu trang web về người dùng của họ.

Trước đây, có một phương pháp thu thập tất cả dữ liệu mà bạn có thể có về mọi thứ, như một chiếc lưới đánh cá khổng lồ rồi sau đó phân tích dữ liệu đó để tìm ra các mẫu thú vị. Nhìn chung, tư duy này đã tạo ra cảm giác lo lắng và không thoải mái về việc thu thập dữ liệu đã được thảo luận trong phần 1 của khoá học này. Hiện nay, nhiều trang web tìm ra câu hỏi cần đặt ra trước, sau đó thu thập dữ liệu cụ thể và có giới hạn để trả lời các câu hỏi đó.

Nếu một số dịch vụ của bên thứ ba được trang web của bạn và các trang web khác sử dụng, và dịch vụ đó hoạt động do bạn đưa JavaScript của họ vào trang web của bạn, đồng thời đặt cookie cho từng người dùng, thì bạn cần phải xem xét liệu họ có thể đang thực hiện nhận dạng không mong muốn trên nhiều trang web; tức là theo dõi người dùng của bạn trên nhiều trang web. Một số người có thể và một số người có thể không, nhưng quan điểm bảo vệ quyền riêng tư ở đây là cho rằng một dịch vụ bên thứ ba như vậy thực tế đang theo dõi trên nhiều trang web, trừ phi bạn có lý do chính đáng để suy nghĩ hoặc biết điều khác. Về bản chất, đây không phải là lý do để tránh các dịch vụ như vậy, nhưng bạn nên cân nhắc khi đánh giá về sự đánh đổi khi sử dụng những dịch vụ đó.

Trước đây, khi đánh đổi số liệu phân tích, bạn chỉ cần chọn sử dụng hay không: thu thập tất cả dữ liệu và xâm phạm quyền riêng tư để đổi lấy thông tin chi tiết và việc lập kế hoạch, hoặc từ bỏ hoàn toàn thông tin chi tiết. Tuy nhiên, điều này không còn như vậy nữa và thường có một điểm giữa giữa hai cực đoan này. Hãy kiểm tra nhà cung cấp dịch vụ phân tích của bạn để biết các lựa chọn cấu hình nhằm giới hạn dữ liệu được thu thập, đồng thời giảm dung lượng cũng như thời gian lưu trữ của dữ liệu đó. Vì đã có các bản ghi từ bài kiểm tra kỹ thuật được mô tả trước đó, nên bạn có thể chạy lại các phần liên quan của bài kiểm tra đó để xác nhận rằng việc thay đổi các cấu hình này thực sự làm giảm lượng dữ liệu được thu thập. Nếu bạn đang thực hiện chuyển đổi này trên một trang web hiện có, thì điều này có thể cung cấp cho bạn một số biện pháp đo lường có thể định lượng để viết về người dùng của bạn. Ví dụ: Google Analytics có một số tính năng về quyền riêng tư chọn sử dụng (do đó sẽ tắt theo mặc định), nhiều tính năng trong số đó có thể giúp ích cho việc tuân thủ các luật bảo vệ dữ liệu của địa phương. Có một số lựa chọn cần xem xét khi thiết lập Google Analytics: đặt khoảng thời gian lưu giữ đối với dữ liệu đã thu thập (Quản trị viên > Thông tin theo dõi > Lưu giữ dữ liệu) thấp hơn thời gian mặc định là 26 tháng, và cho phép một số giải pháp kỹ thuật hơn như ẩn danh IP một phần (xem https://support.google.com/analytics/answer/9019185 để biết thêm chi tiết).

Sử dụng bên thứ ba theo cách bảo đảm quyền riêng tư

Đến nay, chúng ta đã thảo luận về cách bảo vệ người dùng khỏi các bên thứ ba trong giai đoạn thiết kế ứng dụng, trong khi bạn đang lên kế hoạch cho ứng dụng đó sẽ làm gì. Quyết định không sử dụng một bên thứ ba cụ thể là một phần của kế hoạch này và việc kiểm tra việc sử dụng cũng thuộc danh mục này: đó là việc đưa ra các quyết định về lập trường về quyền riêng tư của bạn. Tuy nhiên, những quyết định này vốn không chi tiết lắm; việc chọn sử dụng một bên thứ ba cụ thể hoặc chọn không sử dụng không phải là một quyết định phức tạp. Nhiều khả năng là bạn sẽ muốn một mục tiêu cụ thể: cần hoặc dự định sử dụng một sản phẩm hoặc dịch vụ cụ thể của bên thứ ba, nhưng giảm thiểu mọi xu hướng vi phạm quyền riêng tư (dù là cố ý hay vô tình). Nhiệm vụ này là bảo vệ người dùng tại "thời gian xây dựng": thêm các biện pháp bảo vệ để giảm thiểu tác hại mà bạn không lường trước được. Tất cả những tiêu đề này đều là tiêu đề HTTP mới mà bạn có thể cung cấp khi phân phát trang, đồng thời sẽ gợi ý hoặc ra lệnh cho tác nhân người dùng thực hiện một số quan điểm về quyền riêng tư hoặc bảo mật.

Chính sách liên kết giới thiệu

Nên

Thiết lập chính sách strict-origin-when-cross-origin hoặc noreferrer để ngăn các trang web khác nhận được Tiêu đề giới thiệu khi bạn liên kết đến các trang đó hoặc khi một trang tải các trang đó dưới dạng tài nguyên phụ:

index.html:
<meta name="referrer" content="strict-origin-when-cross-origin" />

Hoặc phía máy chủ, ví dụ như trong Express:

const helmet = require('helmet');
app.use(helmet.referrerPolicy({policy: 'strict-origin-when-cross-origin'}));

Nếu cần, hãy đặt chính sách nới lỏng các phần tử hoặc yêu cầu cụ thể.

Lý do điều này bảo vệ quyền riêng tư của người dùng

Theo mặc định, mỗi yêu cầu HTTP mà trình duyệt thực hiện sẽ truyền trên một tiêu đề Referer chứa URL của trang khởi tạo yêu cầu, cho dù đó là một đường liên kết, hình ảnh được nhúng hay tập lệnh. Đây có thể là vấn đề về quyền riêng tư vì các URL có thể chứa thông tin riêng tư và những URL đó có sẵn cho bên thứ ba chuyển thông tin riêng tư đó cho họ. Web.dev liệt kê một số ví dụ về URL có chứa dữ liệu riêng tư — việc biết rằng người dùng truy cập vào trang web của bạn từ https://social.example.com/user/me@example.com sẽ cho bạn biết người dùng đó là ai, rõ ràng là một sự cố rò rỉ dữ liệu. Nhưng ngay cả một URL không tiết lộ thông tin riêng tư cũng có thể tiết lộ rằng người dùng này (người dùng mà bạn có thể biết, nếu họ đã đăng nhập) đến đây từ một trang web khác và điều này cho thấy rằng người dùng này đã truy cập trang web khác. Điều này tự nó tiết lộ thông tin mà có thể bạn không nên biết về nhật ký duyệt web của người dùng.

Việc cung cấp tiêu đề Referrer-Policy (đúng chính tả!) cho phép bạn thay đổi tiêu đề này để một số hoặc không có URL giới thiệu nào được chuyển đi. MDN liệt kê đầy đủ thông tin chi tiết nhưng hầu hết trình duyệt hiện đã áp dụng giá trị giả định là strict-origin-when-cross-origin theo mặc định, nghĩa là URL liên kết giới thiệu hiện chỉ được chuyển đến bên thứ ba dưới dạng nguồn gốc (https://web.dev thay vì https://web.dev/learn/privacy). Đây là một biện pháp bảo vệ quyền riêng tư hữu ích mà bạn không phải làm gì. Tuy nhiên, bạn có thể thắt chặt hơn nữa bằng cách chỉ định Referrer-Policy: same-origin để tránh chuyển mọi thông tin liên kết giới thiệu cho bên thứ ba (hoặc Referrer-Policy: no-referrer để tránh chuyển cho bất kỳ ai kể cả nguồn gốc của bạn). (Đây là một ví dụ hay về sự cân bằng giữa quyền riêng tư và tiện ích; chế độ mặc định mới bảo đảm quyền riêng tư nhiều hơn so với trước đây, nhưng vẫn cung cấp thông tin cấp cao cho bên thứ ba mà bạn chọn, chẳng hạn như nhà cung cấp phân tích của bạn.)

Bạn cũng nên chỉ định rõ tiêu đề này vì sau đó bạn sẽ biết chính xác chính sách là gì thay vì dựa vào các giá trị mặc định của trình duyệt. Nếu không thể đặt tiêu đề, thì bạn có thể đặt chính sách liên kết giới thiệu cho toàn bộ trang HTML bằng cách sử dụng phần tử meta trong <head>: <meta name="referrer" content="same-origin">; và nếu lo ngại về các bên thứ ba cụ thể, bạn cũng có thể đặt thuộc tính referrerpolicy trên các phần tử riêng lẻ như <script>, <a> hoặc <iframe>: <script src="https://thirdparty.example.com/data.js" referrerpolicy="no-referrer">

Chính sách-bảo-mật-nội dung

Tiêu đề Content-Security-Policy, thường được gọi là "CSP", cho biết nơi có thể tải các tài nguyên bên ngoài. API này chủ yếu được dùng cho mục đích bảo mật, bằng cách ngăn các cuộc tấn công tập lệnh trên nhiều trang web và chèn tập lệnh, nhưng khi được sử dụng cùng với các lần kiểm tra định kỳ, công cụ này cũng có thể giới hạn nơi các bên thứ ba đã chọn có thể chuyển dữ liệu đến.

Đây có thể là trải nghiệm người dùng kém tuyệt vời; nếu một trong các tập lệnh bên thứ ba của bạn bắt đầu tải phần phụ thuộc từ một nguồn gốc không có trong danh sách của bạn, thì yêu cầu đó sẽ bị chặn, tập lệnh sẽ không thành công và ứng dụng của bạn có thể không hoạt động được (hoặc ít nhất bị giảm xuống phiên bản dự phòng gặp lỗi JavaScript). Tính năng này rất hữu ích khi CSP được triển khai vì mục đích bảo mật, vốn là mục đích thông thường của nó: bảo vệ khỏi các vấn đề về tập lệnh trên nhiều trang web (và để thực hiện việc này, hãy sử dụng CSP nghiêm ngặt). Sau khi biết tất cả tập lệnh cùng dòng mà trang của bạn sử dụng, bạn có thể lập danh sách các tập lệnh đó, tính giá trị băm hoặc thêm một giá trị ngẫu nhiên (còn gọi là "số chỉ dùng một lần") cho mỗi tập lệnh, rồi thêm danh sách hàm băm vào Chính sách bảo mật nội dung của bạn. Thao tác này sẽ ngăn việc tải bất kỳ tập lệnh nào không nằm trong danh sách. Bước này cần được đưa vào quy trình sản xuất cho trang web: các tập lệnh trong các trang của bạn cần bao gồm số chỉ dùng một lần hoặc có hàm băm được tính toán như một phần của bản dựng. Hãy xem bài viết về nghiêm ngặt để biết tất cả thông tin chi tiết.

Rất may là các trình duyệt có hỗ trợ tiêu đề liên quan là Content-Security-Policy-Report-Only. Nếu bạn cung cấp tiêu đề này, các yêu cầu vi phạm chính sách đã cung cấp sẽ không bị chặn, nhưng báo cáo JSON sẽ được gửi đến một URL đã cung cấp. Tiêu đề như vậy có thể trông như sau: Content-Security-Policy-Report-Only: script-src 3p.example.com; report-uri https://example.com/report/ và nếu trình duyệt tải tập lệnh từ bất kỳ nơi nào khác ngoài 3p.example.com, thì yêu cầu đó sẽ thành công nhưng báo cáo sẽ được gửi đến report-uri đã cung cấp. Thông thường, tính năng này dùng để thử nghiệm một chính sách trước khi triển khai. Tuy nhiên, bạn nên dùng tính năng này như một cách tiến hành "quá trình kiểm tra đang diễn ra". Cũng như hoạt động kiểm tra thông thường được mô tả trước đó, bạn có thể bật tính năng báo cáo CSP để xem liệu có miền không mong muốn nào xuất hiện hay không, tức là tài nguyên bên thứ ba của bạn đang tải những tài nguyên bên thứ ba của riêng họ mà bạn cần xem xét và đánh giá. (Đó cũng có thể là dấu hiệu cho thấy một số hành vi khai thác tập lệnh trên nhiều trang web đã vượt quá ranh giới bảo mật của bạn, tất nhiên, điều này cũng quan trọng bạn cần biết!)

Content-Security-Policy là một API phức tạp và khó sử dụng. Như chúng ta đã biết, chúng tôi vẫn đang tiếp tục xây dựng "thế hệ mới" của CSP sẽ đáp ứng các mục tiêu tương tự nhưng không quá phức tạp khi sử dụng.Tính năng này chưa sẵn sàng, nhưng nếu bạn muốn xem hướng tới mục tiêu nào (hoặc tham gia và trợ giúp về thiết kế của CSP!) thì hãy truy cập https://github.com/WICG/csp-next để biết thông tin chi tiết.

Nên

Thêm tiêu đề HTTP này vào các trang được phân phát: Content-Security-Policy-Report-Only: default-src 'self'; report-uri https://a-url-you-control. Khi JSON được đăng lên URL đó, hãy lưu trữ JSON. Xem lại dữ liệu đã lưu trữ đó để thu thập các miền của bên thứ ba mà trang web của bạn yêu cầu khi có người khác truy cập. Cập nhật tiêu đề Content-Security-Policy-Report-Only để liệt kê các miền mà bạn dự kiến, để xem thời điểm danh sách đó thay đổi:

Content-Security-Policy-Report-Only: default-src 'self' https://expected1.example.com https://expected2.example.com ; report-uri https://a-url-you-control

Tại sao nên

Hoạt động này tạo thành một phần trong hoạt động kiểm tra kỹ thuật và diễn ra liên tục. Bước kiểm tra kỹ thuật ban đầu do bạn thực hiện sẽ cung cấp cho bạn danh sách các bên thứ ba mà trang web của bạn chia sẻ hoặc truyền dữ liệu người dùng. Sau đó, tiêu đề này sẽ khiến các yêu cầu trang báo cáo lại những bên thứ ba nào đang được liên hệ và bạn có thể theo dõi các thay đổi theo thời gian. Thao tác này không chỉ thông báo cho bạn về những thay đổi do các bên thứ ba hiện tại của bạn thực hiện mà còn gắn cờ các bên thứ ba mới được thêm vào chưa được thêm vào quá trình kiểm tra kỹ thuật. Bạn cần phải cập nhật tiêu đề để ngừng báo cáo về những miền mà bạn mong đợi, nhưng thỉnh thoảng cũng cần phải lặp lại quy trình kiểm tra kỹ thuật thủ công (vì phương pháp Content-Security-Policy không gắn cờ dữ liệu cái gì được chuyển mà chỉ gắn cờ dữ liệu đã được thực hiện.)

Xin lưu ý rằng bạn không cần phải thêm đoạn mã vào các trang được phân phát mỗi lần hoặc mọi trang. Hãy điều chỉnh số lượng phản hồi trang nhận được tiêu đề để nhận được mẫu báo cáo đại diện không quá nhiều về số lượng.

Chính sách về quyền

Tiêu đề Permissions-Policy (được giới thiệu dưới tên Feature-Policy) có khái niệm tương tự như Content-Security-Policy, nhưng tiêu đề này hạn chế quyền truy cập vào các tính năng mạnh mẽ của trình duyệt. Ví dụ: bạn có thể hạn chế việc sử dụng phần cứng của thiết bị, chẳng hạn như gia tốc kế, máy ảnh hay thiết bị USB, hoặc hạn chế các tính năng không liên quan đến phần cứng, chẳng hạn như quyền truy cập chế độ toàn màn hình hoặc sử dụng XMLHTTPRequest đồng bộ. Những hạn chế này có thể được áp dụng cho trang cấp cao nhất (để tránh các tập lệnh đã tải cố gắng sử dụng các tính năng này) hoặc cho các trang có khung phụ được tải thông qua iframe. Quy định hạn chế về việc sử dụng API này không thực sự liên quan đến việc tạo vân tay số của trình duyệt; mà là về việc không cho phép bên thứ ba thực hiện các hoạt động xâm nhập (chẳng hạn như sử dụng các API mạnh, bật lên cửa sổ quyền, v.v.). Mô hình mối đe doạ về quyền riêng tư mục tiêu định nghĩa hành vi này là "xâm nhập".

Tiêu đề Permissions-Policy được chỉ định dưới dạng danh sách các cặp (tính năng, nguồn gốc được phép), do đó:

Permissions-Policy: geolocation=(self "https://example.com"), camera=(), fullscreen=*

Ví dụ này cho phép trang này ("self") và các <iframe> từ example.com gốc sử dụng API navigator.geolocation từ JavaScript; cho phép trang này và tất cả các khung phụ sử dụng API toàn màn hình và nghiêm cấm mọi trang (kể cả trang này) sử dụng máy ảnh để đọc thông tin video. Có nhiều thông tin chi tiết hơn và danh sách các ví dụ có thể có tại đây.

Danh sách các tính năng được xử lý trong tiêu đề Permissions-Policy rất lớn và có thể thay đổi. Hiện tại, danh sách này được duy trì tại https://github.com/w3c/webappsec-permissions-policy/blob/main/features.md.

Mẹo: Lưu ý rằng các giá trị Content-Security-Policy được phân tách bằng dấu chấm phẩy nhưng các giá trị Permissions-Policy được phân tách bằng dấu phẩy và các giá trị Permissions-Policy có dấu ngoặc vuông xung quanh. Thông tin chi tiết được nêu rõ trong phần Giải thích về Chính sách quyền.

Nên

Theo mặc định, các trình duyệt hỗ trợ Permissions-Policy không cho phép các tính năng mạnh mẽ trong khung phụ và bạn phải tự mình bật các tính năng này! Phương thức này được đặt ở chế độ riêng tư theo mặc định. Nếu thấy các khung phụ trên trang web của mình cần những quyền này, bạn có thể thêm chúng một cách có chọn lọc. Tuy nhiên, không có chính sách về quyền nào được áp dụng cho trang chính theo mặc định. Do đó, các tập lệnh (bao gồm cả tập lệnh của bên thứ ba) do trang chính tải không bị hạn chế sử dụng các tính năng này. Vì lý do này, bạn nên áp dụng Permissions-Policy hạn chế cho tất cả các trang theo mặc định, sau đó thêm lại dần các tính năng mà trang yêu cầu.

Ví dụ về các tính năng mạnh mẽ mà Permissions-Policy ảnh hưởng đến: yêu cầu thông tin vị trí của người dùng, quyền truy cập vào các cảm biến (bao gồm gia tốc kế, con quay hồi chuyển và từ kế), quyền truy cập chế độ toàn màn hình cũng như yêu cầu quyền truy cập vào máy ảnh và micrô của người dùng. Danh sách (thay đổi) đầy đủ các tính năng được liên kết ở trên.

Thật không may, việc chặn tất cả tính năng theo mặc định rồi sau đó chọn lại cho phép chúng yêu cầu liệt kê tất cả các tính năng trong tiêu đề. Điều này có thể khiến người dùng cảm thấy không hợp lý. Tuy nhiên, tiêu đề Permissions-Policy như vậy là một nơi phù hợp để bắt đầu. Permissionspolicy.com/ có một trình tạo có thể nhấp thuận tiện để tạo tiêu đề như vậy: sử dụng tiêu đề này để tạo tiêu đề vô hiệu hoá tất cả các tính năng dẫn đến:

Permissions-Policy: accelerometer=(), ambient-light-sensor=(), autoplay=(), battery=(), camera=(), cross-origin-isolated=(),
display-capture=(), document-domain=(), encrypted-media=(), execution-while-not-rendered=(), execution-while-out-of-viewport=(),
fullscreen=(), geolocation=(), gyroscope=(), keyboard-map=(), magnetometer=(), microphone=(), midi=(), navigation-override=(),
payment=(), picture-in-picture=(), publickey-credentials-get=(), screen-wake-lock=(), sync-xhr=(), usb=(), web-share=(), xr-spatial-tracking=()

Tìm hiểu các tính năng tích hợp sẵn về quyền riêng tư trong trình duyệt web

Ngoài các biện pháp bảo vệ "thời gian xây dựng" và "thời gian thiết kế", còn có các biện pháp bảo vệ quyền riêng tư diễn ra trong "thời gian chạy": tức là các tính năng về quyền riêng tư được triển khai trong chính trình duyệt để bảo vệ người dùng. Đây không phải là các tính năng mà bạn có thể trực tiếp kiểm soát hoặc khai thác với tư cách là nhà phát triển trang web. Đó là tính năng sản phẩm nhưng bạn nên lưu ý vì trang web của bạn có thể bị ảnh hưởng bởi các quyết định về sản phẩm trong trình duyệt. Ví dụ ở đây về cách các biện pháp bảo vệ trình duyệt này có thể tác động đến trang web của bạn, nếu bạn có JavaScript phía máy khách chờ phần phụ thuộc của bên thứ ba tải trước khi tiếp tục thiết lập trang và phần phụ thuộc bên thứ ba đó không hề tải, thì quá trình thiết lập trang có thể không bao giờ hoàn tất và vì vậy người dùng sẽ thấy một trang đã tải một nửa.

Các chính sách này bao gồm tính năng Ngăn chặn hoạt động theo dõi thông minh trong Safari (và công cụ tin nhắn cơ bản) và tính năng Bảo vệ chống theo dõi nâng cao trong Firefox (và công cụ của trình duyệt là Gecko). Tất cả các vấn đề này đều gây khó khăn cho bên thứ ba trong việc xây dựng hồ sơ chi tiết về người dùng của bạn.

Phương pháp tiếp cận của trình duyệt đối với các tính năng về quyền riêng tư thay đổi thường xuyên và bạn cần phải cập nhật; danh sách các biện pháp bảo vệ sau đây là chính xác tại thời điểm viết. Các trình duyệt cũng có thể triển khai các biện pháp bảo vệ khác; những danh sách này chưa đầy đủ. Hãy xem mô-đun về các phương pháp hay nhất để biết những cách bắt kịp các thay đổi tại đây, và hãy nhớ kiểm thử với các phiên bản trình duyệt sắp tới để biết những thay đổi có thể ảnh hưởng đến dự án của bạn. Lưu ý rằng đôi khi, chế độ duyệt web ẩn danh/riêng tư triển khai các chế độ cài đặt khác với chế độ mặc định của trình duyệt (ví dụ: cookie của bên thứ ba có thể bị chặn theo mặc định ở các chế độ như vậy). Do đó, việc thử nghiệm ở chế độ ẩn danh không phải lúc nào cũng phản ánh trải nghiệm duyệt web thông thường của hầu hết người dùng nếu họ không sử dụng tính năng duyệt web ở chế độ riêng tư. Ngoài ra, hãy lưu ý rằng việc chặn cookie trong nhiều trường hợp có thể đồng nghĩa với việc các giải pháp lưu trữ khác, chẳng hạn như window.localStorage, cũng sẽ bị chặn chứ không chỉ cookie.

Chrome

Cookie của bên thứ ba dự định sẽ bị chặn trong tương lai. Tại thời điểm viết bài này, các trình duyệt này không bị chặn theo mặc định (nhưng người dùng có thể bật tính năng này): https://support.google.com/chrome/answer/95647 giải thích thông tin chi tiết.
Các tính năng về quyền riêng tư của Chrome, cụ thể là các tính năng trong Chrome dùng để giao tiếp với các dịch vụ của Google và bên thứ ba, được mô tả tại privacysandbox.com/.

Edge

Theo mặc định, cookie của bên thứ ba không bị chặn (nhưng người dùng có thể bật cookie này).
Tính năng Ngăn chặn theo dõi của Edge chặn trình theo dõi khỏi các trang web chưa truy cập và các trình theo dõi có hại đã biết sẽ bị chặn theo mặc định.

Firefox

Theo mặc định, cookie của bên thứ ba không bị chặn (nhưng người dùng có thể bật cookie này).
Tính năng Bảo vệ theo dõi nâng cao của Firefox chặn theo mặc định cookie theo dõi, tập lệnh in vân tay, tập lệnh mã hoá và trình theo dõi đã biết. (https://support.mozilla.org/kb/trackers-and-scripts-firefox-blocks-enhanced-track cung cấp thêm một số chi tiết).
Cookie của bên thứ ba bị giới hạn theo trang web, vì vậy, về cơ bản, mỗi trang web có một kho cookie riêng và không thể liên kết với các trang web ( Mozilla gọi đây là "Total Cookie Protect" (Tổng bảo vệ cookie).

Để xem thông tin chi tiết về những yếu tố có thể bị chặn và giúp gỡ lỗi, hãy nhấp vào biểu tượng tấm khiên trong thanh địa chỉ hoặc truy cập vào about:protections trong Firefox (trên máy tính).

Safari

Theo mặc định, cookie của bên thứ ba sẽ bị chặn.
Là một phần của tính năng Ngăn chặn theo dõi thông minh, Safari giảm liên kết giới thiệu được chuyển đến các trang khác thành trang web cấp cao nhất thay vì một trang cụ thể: (https://something.example.com, thay vì https://something.example.com/this/specific/page).
Dữ liệu trên localStorage của trình duyệt sẽ bị xoá sau 7 ngày.

(https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/ tóm tắt các tính năng này.)

Để biết một số thông tin chi tiết về những gì có thể bị chặn và giúp gỡ lỗi sự cố, hãy bật "Chế độ gỡ lỗi ngăn chặn theo dõi thông minh" trong trình đơn dành cho nhà phát triển của Safari (trên máy tính). (Xem https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/ để biết thêm chi tiết.)

Đề xuất API

Tại sao chúng ta cần có API mới?

Mặc dù các tính năng và chính sách bảo đảm quyền riêng tư mới trong các sản phẩm trình duyệt giúp bảo vệ quyền riêng tư của người dùng, nhưng chúng cũng đi kèm với nhiều thách thức. Nhiều công nghệ web có thể sử dụng được để theo dõi trên nhiều trang web mặc dù được thiết kế và sử dụng cho các mục đích khác. Ví dụ: nhiều hệ thống liên kết danh tính mà chúng tôi sử dụng hằng ngày dựa vào cookie của bên thứ ba. Có nhiều giải pháp quảng cáo mà các nhà xuất bản dựa vào để kiếm doanh thu ngày nay được xây dựng dựa trên cookie của bên thứ ba. Nhiều giải pháp phát hiện hành vi gian lận phụ thuộc vào phương thức tạo vân tay số. Điều gì xảy ra với các trường hợp sử dụng này khi cookie của bên thứ ba và giải pháp tạo vân tay số không còn được dùng nữa?

Trình duyệt sẽ khó phân biệt các trường hợp sử dụng và phân biệt một cách chính xác các trường hợp sử dụng vi phạm quyền riêng tư với các trường hợp khác. Đây là lý do hầu hết các trình duyệt lớn đã chặn cookie của bên thứ ba và tạo vân tay số hoặc có ý định làm như vậy để bảo vệ quyền riêng tư của người dùng.

Cần có một phương pháp mới: vì cookie của bên thứ ba sẽ bị loại bỏ và giảm thiểu vân tay số, nhà phát triển cần có các API được thiết kế riêng đáp ứng các trường hợp sử dụng (vẫn chưa biến mất) nhưng được thiết kế theo cách bảo đảm quyền riêng tư. Mục tiêu là thiết kế và xây dựng các API không thể dùng để theo dõi trên nhiều trang web. Không giống như các tính năng của trình duyệt được mô tả trong phần trước, các công nghệ này mong muốn trở thành API trên nhiều trình duyệt.

Ví dụ về đề xuất API

Danh sách sau đây chưa đầy đủ và chỉ bao gồm một số nội dung đang được thảo luận.

Ví dụ về đề xuất API để thay thế công nghệ xây dựng trên cookie của bên thứ ba:

Các trường hợp sử dụng danh tính: FedCM
Các trường hợp sử dụng quảng cáo: Đo lường lượt nhấp riêng tư, Mô hình phân bổ riêng tư có thể tương tác, Báo cáo phân bổ, Chủ đề, FLEDGE, ban ban gaitot.

Ví dụ về đề xuất API để thay thế các công nghệ được xây dựng dựa trên tính năng theo dõi thụ động:

Các trường hợp sử dụng phát hiện gian lận: Mã thông báo tin cậy.

Ví dụ về các đề xuất khác mà các API khác có thể xây dựng trong tương lai mà không cần cookie của bên thứ ba:

Storage Access API (API Quyền truy cập vào bộ nhớ)

Ngoài ra, một loại đề xuất API khác đang xuất hiện để thử và có các giải pháp giảm thiểu hoạt động theo dõi bí mật cho từng trình duyệt cho đến nay. Một ví dụ là Ngân sách quyền riêng tư. Trong nhiều trường hợp sử dụng này, các API mà Chrome đề xuất ban đầu đều hoạt động trong phạm vi bao quát là Hộp cát về quyền riêng tư.

Global-Privacy-Control là tiêu đề nhằm thông báo cho một trang web rằng người dùng không muốn chia sẻ bất kỳ dữ liệu cá nhân nào đã thu thập với các trang web khác. Mục đích của tính năng này tương tự như tính năng Không theo dõi đã ngừng hoạt động.

Lưu ý: Đầu những năm 2000, các nhóm tư vấn tiêu dùng đã thúc đẩy để cho phép người dùng nêu rõ rằng họ không muốn bị theo dõi bằng cookie hoặc các công nghệ tương tự. Tất cả các trình duyệt chính đã triển khai tiêu đề này dưới dạng tiêu đề yêu cầu, Không theo dõi, với giá trị 1 để cho các trang web biết người dùng không muốn bị theo dõi. Điều này nhận được rất nhiều phản hồi của các công ty thu thập dữ liệu và không yêu cầu phải tuân thủ yêu cầu này, và phần lớn thì không. Đến cuối những năm 2010, phần lớn trình duyệt đã bị xoá khỏi trình duyệt và nhóm làm việc có trách nhiệm đóng, cho rằng "chưa có dấu hiệu nào về việc các tác nhân người dùng, các bên thứ ba và hệ sinh thái nói chung sẽ hỗ trợ theo kế hoạch".

Trạng thái của đề xuất API

Hầu hết các đề xuất API này chưa được triển khai hoặc chỉ được triển khai sau khi gắn cờ hoặc trong môi trường hạn chế để thử nghiệm.

Giai đoạn ươm công khai này rất quan trọng: các nhà cung cấp trình duyệt và nhà phát triển sẽ thu thập thảo luận và kinh nghiệm về việc liệu các API này có hữu ích hay không và liệu chúng có thực sự làm đúng mục đích của chúng hay không. Các nhà phát triển, nhà cung cấp trình duyệt và các đối tượng khác trong hệ sinh thái sử dụng giai đoạn này để lặp lại thiết kế của API.

Hiện tại, nơi tốt nhất để cập nhật các API mới đang được đề xuất là danh sách đề xuất của Nhóm về quyền riêng tư trên GitHub.

Bạn có cần sử dụng các API này không?

Nếu sản phẩm của bạn được xây dựng trực tiếp dựa trên cookie hoặc kỹ thuật của bên thứ ba như tạo vân tay số, bạn nên tham gia vào các API mới này, thử nghiệm chúng và đóng góp trải nghiệm của riêng mình vào các cuộc thảo luận và thiết kế API. Trong mọi trường hợp khác, bạn không nhất thiết phải biết tất cả chi tiết về các API mới này tại thời điểm viết bài, nhưng bạn nên biết được những gì sắp tới.