[OUTDATED] Nhóm bên thứ nhất và thuộc tính SameParty

Nhiều tổ chức có các trang web liên quan bằng nhiều tên miền, chẳng hạn như brandx.site và fly-brandx.site, hoặc miền dành cho các quốc gia khác nhau, chẳng hạn như example.com, example.rs, example.co.uk, v.v.

Các trình duyệt đang hướng tới việc làm cho cookie của bên thứ ba lỗi thời để cải thiện quyền riêng tư trên web. Tuy nhiên, các trang web như thế này thường dựa vào cookie để thực hiện các chức năng yêu cầu duy trì và truy cập trạng thái trên nhiều miền (chẳng hạn như đăng nhập một lần và quản lý sự đồng ý).

Nhóm bên thứ nhất có thể cho phép coi các tên miền liên quan do cùng một thực thể sở hữu và điều hành là bên thứ nhất trong trường hợp bên thứ nhất và bên thứ ba được xử lý khác nhau. Tên miền trong nhóm bên thứ nhất được coi là cùng một bên và có thể gắn nhãn những cookie mà bạn muốn đặt hoặc gửi trong ngữ cảnh bên thứ nhất. Mục đích là tìm được sự cân bằng giữa việc ngăn bên thứ ba theo dõi trên nhiều trang web trong khi vẫn duy trì một đường dẫn không phá vỡ các trường hợp sử dụng hợp lệ.

Đề xuất Nhóm bên thứ nhất hiện đang trong giai đoạn thử nghiệm, hãy đọc tiếp để tìm hiểu cách hoạt động và cách bạn có thể dùng thử.

Sự khác biệt giữa cookie của bên thứ nhất và bên thứ ba là gì?

Cookie vốn không phải là của bên thứ nhất hay bên thứ ba, điều này phụ thuộc vào ngữ cảnh hiện tại nơi cookie được đưa vào. Đó là theo một yêu cầu trong tiêu đề cookie hoặc qua document.cookie trong JavaScript.

Ví dụ: nếu video.site có cookie theme=dark, khi bạn duyệt video.site và một yêu cầu được gửi đến video.site, thì đó là bối cảnh cùng trang web và cookie đi kèm là bên thứ nhất.

Tuy nhiên, nếu bạn đang sử dụng my-blog.site nhúng trình phát iframe cho video.site, thì khi yêu cầu được thực hiện từ my-blog.site đến video.site, thì đó là ngữ cảnh trên nhiều trang web và cookie theme là của bên thứ ba.

Sơ đồ cho thấy cookie từ video.site theo 2 ngữ cảnh. Cookie này cùng trang web khi ngữ cảnh cấp cao nhất cũng là video.site. Cookie này được lưu trên nhiều trang web khi ngữ cảnh cấp cao nhất là my-blog.site với video.site trong một iframe.

Việc bao gồm cookie được xác định bởi thuộc tính SameSite của cookie:

  • Ngữ cảnh cùng trang web với SameSite=Lax, Strict hoặc None tạo ra cookie là bên thứ nhất.
  • Ngữ cảnh trên nhiều trang web với SameSite=None làm cho cookie trở thành bên thứ ba.

Tuy nhiên, không phải lúc nào điều này cũng rõ ràng. Hãy tưởng tượng brandx.site là một trang web đặt vé du lịch. Trang web này cũng sử dụng fly-brandx.site và drive-brandx.site để tách riêng các chuyến bay và thuê xe. Trong quá trình đặt trước một hành trình, khách truy cập di chuyển giữa các trang web này để chọn lựa chọn khác nhau và họ muốn rằng "giỏ hàng" sẽ vẫn tồn tại trên các trang web này. brandx.site quản lý phiên hoạt động của người dùng bằng một cookie SameSite=None để cho phép hoạt động này trong ngữ cảnh nhiều trang web. Tuy nhiên, nhược điểm hiện tại là cookie này không có biện pháp bảo vệ Yêu cầu giả mạo trên nhiều trang web (CSRF). Nếu evil.site bao gồm yêu cầu đến brandx.site thì nó sẽ bao gồm cookie đó!

Cookie này hoạt động trên nhiều trang web, nhưng tất cả các trang web đó đều do cùng một tổ chức sở hữu và điều hành. Khách truy cập cũng hiểu rằng cùng một tổ chức và muốn cùng một phiên, nói cách khác—một danh tính chung, giữa họ.

Sơ đồ cho thấy cách cookie vẫn có thể được đưa vào ngữ cảnh nhiều trang web nếu các trang web đó thuộc cùng một Nhóm bên thứ nhất, nhưng sẽ bị từ chối đối với các ngữ cảnh nhiều trang web bên ngoài nhóm này.

Chính sách về Nhóm bên thứ nhất

Nhóm bên thứ nhất đề xuất một phương thức để xác định rõ ràng mối quan hệ này trên nhiều trang web do cùng một bên sở hữu và điều hành. Điều này cho phép brandx.site xác định mối quan hệ bên thứ nhất với fly-brandx.site, drive-brandx.site, v.v.

Mô hình quyền riêng tư thúc đẩy nhiều đề xuất cho Hộp cát về quyền riêng tư dựa trên khái niệm phân vùng danh tính để ngăn hoạt động theo dõi trên nhiều trang web — vạch ra ranh giới giữa các trang web giới hạn quyền truy cập vào bất kỳ thông tin nào có thể dùng để nhận dạng người dùng.

Sơ đồ cho thấy trạng thái chưa được phân vùng, trong đó cookie của bên thứ ba có thể truy cập được trong nhiều ngữ cảnh trên nhiều trang web, trái ngược với một mô hình được phân vùng, trong đó mỗi ngữ cảnh cấp cao nhất đều có một phiên bản riêng của cookie trên nhiều trang web, ngăn hoạt động liên kết giữa các trang web đó.

Mặc dù tuỳ chọn mặc định là phân vùng theo trang web, giúp giải quyết nhiều trường hợp sử dụng của bên thứ nhất, nhưng ví dụ brandx.site cho thấy rằng bên thứ nhất có thể lớn hơn chỉ một trang web.

Sơ đồ cho thấy cách đưa cùng một phiên bản cookie cho một nhóm vào ngữ cảnh nhiều trang web khi tất cả các trang web đó đều thuộc cùng một nhóm.

Một phần quan trọng trong đề xuất Nhóm bên thứ nhất là đảm bảo chính sách đó trên các trình duyệt ngăn chặn hành vi sử dụng sai mục đích hoặc sử dụng sai mục đích. Ví dụ: Nhóm bên thứ nhất không được cho phép trao đổi thông tin người dùng giữa các trang web không liên quan hoặc nhóm các trang web không thuộc sở hữu của cùng một thực thể. Mục đích là để đảm bảo Nhóm bên thứ nhất liên kết với một giá trị mà một người hiểu là bên thứ nhất và không được dùng làm cách chia sẻ danh tính giữa các bên.

Một cách để một trang web có thể đăng ký nhóm bên thứ nhất là gửi nhóm miền đề xuất tới một công cụ theo dõi công khai (chẳng hạn như kho lưu trữ GitHub riêng) cùng với thông tin cần thiết để đáp ứng chính sách trình duyệt.

Sau khi xác nhận nhóm của bên thứ nhất được xác minh theo chính sách, các trình duyệt có thể tìm nạp danh sách các nhóm thông qua quy trình cập nhật.

Bản dùng thử theo nguyên gốc có một chính sách đã xác định và chưa phải là chính sách chính thức, nhưng các nguyên tắc có thể vẫn giữ nguyên:

  • Các miền trong nhóm bên thứ nhất phải do cùng một tổ chức sở hữu và điều hành.
  • Người dùng có thể nhận ra miền dưới dạng một nhóm.
  • Các miền phải có chung một chính sách quyền riêng tư.

Cách xác định nhóm bên thứ nhất

Sau khi bạn xác định được các thành viên và chủ sở hữu nhóm bên thứ nhất của tổ chức, một bước quan trọng là gửi nhóm mà bạn đề xuất để được phê duyệt. Quy trình chính xác này vẫn đang được thảo luận.

Để khai báo nhóm của bên thứ nhất, các tài nguyên JSON tĩnh liệt kê thành viên và chủ sở hữu nên được lưu trữ tại /.well-known/first-party-set ở cấp cao nhất của mỗi miền được đưa vào.

Trong ví dụ về nhóm brandx bên thứ nhất, chủ sở hữu miền lưu trữ nội dung sau tại https://brandx.site/.well-known/first-party-set:

{
  "owner": "brandx.site",
  "version": 1,
  "members": ["fly-brandx.site", "drive-brandx.site"]
}

Mỗi thành phần của tập hợp cũng lưu trữ một tài nguyên JSON tĩnh trỏ ngược lại chủ sở hữu của tập hợp. Tại https://fly-brandx.site/.well-known/first-party-set, chúng tôi có:

{ "owner": "brandx.site" }

Và lúc https://drive-brandx.site/.well-known/first-party-set:

{ "owner": "brandx.site" }

Có một số hạn chế đối với các nhóm bên thứ nhất:

  • Một tập hợp chỉ có thể có một chủ sở hữu.
  • Mỗi thành viên chỉ có thể thuộc về một tập hợp, không chồng chéo hoặc kết hợp với nhau.
  • Danh sách thành viên nhằm mục đích duy trì tương đối dễ đọc và không quá lớn.

Nhóm bên thứ nhất ảnh hưởng như thế nào đến cookie?

Thành phần so khớp cho cookie là thuộc tính SameParty được đề xuất. Việc chỉ định SameParty sẽ yêu cầu trình duyệt bao gồm cookie khi ngữ cảnh của nó thuộc cùng một bên thứ nhất được đặt làm ngữ cảnh cấp cao nhất.

Điều đó có nghĩa là nếu brandx.site đặt cookie này:

Set-Cookie: session=123; Secure; SameSite=Lax; SameParty

Sau đó, khi khách truy cập truy cập vào fly-brandx.site và một yêu cầu chuyển đến brandx.site, thì cookie session sẽ được đưa vào yêu cầu đó. Nếu một trang web nào khác không thuộc nhóm bên thứ nhất, chẳng hạn như hotel.xyz, gửi yêu cầu đến brandx.site, thì cookie này sẽ không được đưa vào.

Sơ đồ cho thấy cookie brandx.site được cho phép hoặc bị chặn trong ngữ cảnh nhiều trang web như mô tả.

Cho đến khi SameParty được hỗ trợ rộng rãi, hãy sử dụng thuộc tính SameSite cùng với thuộc tính đó để xác định hành vi dự phòng cho cookie. Bạn có thể xem thuộc tính SameParty cung cấp cho bạn chế độ cài đặt từ SameSite=Lax đến SameSite=None.

  • SameSite=Lax; SameParty sẽ mở rộng chức năng Lax để bao gồm ngữ cảnh cùng bên khi được hỗ trợ, nhưng sẽ quay lại sử dụng các hạn chế Lax nếu không được hỗ trợ.
  • SameSite=None; SameParty sẽ hạn chế chức năng None đối với chỉ ngữ cảnh cùng bên khi được hỗ trợ, nhưng sẽ quay lại sử dụng các quyền None rộng hơn nếu không được hỗ trợ.

Có một số yêu cầu bổ sung:

  • Cookie SameParty phải bao gồm Secure.
  • Cookie SameParty không được bao gồm SameSite=Strict.

Secure là bắt buộc vì đây vẫn là hoạt động trên nhiều trang web và bạn nên giảm thiểu những rủi ro đó bằng cách đảm bảo các kết nối bảo mật (HTTPS). Tương tự, vì đây là mối quan hệ trên nhiều trang web, nên SameSite=Strict không hợp lệ vì vẫn cho phép bảo vệ chặt chẽ CSRF dựa trên trang web trong một tập hợp.

Những trường hợp sử dụng nào phù hợp với Nhóm bên thứ nhất?

Nhóm bên thứ nhất phù hợp với các trường hợp khi một tổ chức cần một hình thức danh tính dùng chung trên nhiều trang web cấp cao nhất. Danh tính chung trong trường hợp này có nghĩa là mọi thứ từ giải pháp đăng nhập một lần đầy đủ đến chỉ cần một lựa chọn ưu tiên chung giữa các trang web.

Tổ chức của bạn có thể có các miền cấp cao nhất khác nhau cho:

  • Miền ứng dụng: office.com,live.com, microsoft.com
  • Tên miền được gắn thương hiệu: amazon.com, audible.com / disney.com, pixar.com
  • Các miền theo quốc gia để cho phép bản địa hoá: google.co.in, google.co.uk
  • Các miền dịch vụ mà người dùng không bao giờ tương tác trực tiếp nhưng cung cấp dịch vụ trên các trang web của cùng một tổ chức: gstatic.com, githubassets.com, fbcdn.net
  • Các miền hộp cát mà người dùng không bao giờ tương tác trực tiếp, nhưng tồn tại vì lý do bảo mật: googleusercontent.com, githubusercontent.com

Bạn tham gia bằng cách nào?

Nếu bạn có một nhóm trang web phù hợp với các tiêu chí ở trên, thì bạn có một số cách để tham gia. Khoản đầu tư nhẹ nhất là đọc và tham gia thảo luận về 2 đề xuất:

Trong giai đoạn kiểm thử, bạn có thể dùng thử chức năng này bằng cách sử dụng cờ dòng lệnh --use-first-party-set và cung cấp danh sách trang web được phân tách bằng dấu phẩy.

Bạn có thể thử thực hiện thao tác này trên trang web minh hoạ tại https://fps-member1.glitch.me/ sau khi khởi động Chrome với cờ sau:

--use-first-party-set=https://fps-member1.glitch.me,https://fps-member2.glitch.me,https://fps-member3.glitch.me

Điều này rất hữu ích nếu bạn muốn kiểm thử trong môi trường phát triển hoặc muốn thử thêm thuộc tính SameParty trong môi trường thực tế để xem nhóm bên thứ nhất sẽ ảnh hưởng đến cookie như thế nào.

Nếu có đủ băng thông để thử nghiệm và phản hồi, bạn cũng có thể đăng ký Bản dùng thử nguyên gốc cho Nhóm bên thứ nhất vàCùngParty có sẵn trong Chrome từ phiên bản 89 đến 93.

Cách cập nhật cookie cho bản dùng thử theo nguyên gốc

Nếu đang tham gia bản dùng thử theo nguyên gốc và kiểm thử thuộc tính SameParty trên cookie, bạn cần cân nhắc 2 mẫu sau đây.

Tùy chọn 1

Trước tiên, khi có cookie mà bạn đã gắn nhãn là SameSite=None nhưng muốn hạn chế trong ngữ cảnh bên thứ nhất, bạn có thể thêm thuộc tính SameParty vào các cookie đó. Trong các trình duyệt đang chạy bản dùng thử theo nguyên gốc, cookie sẽ không được gửi trong ngữ cảnh nhiều trang web bên ngoài tập hợp thử nghiệm.

Tuy nhiên, đối với phần lớn trình duyệt không thuộc bản dùng thử theo nguyên gốc, cookie sẽ tiếp tục được gửi trên nhiều trang web như thường lệ. Hãy xem đây là một phương pháp nâng cao tăng dần.

Trước: set-cookie: cname=cval; SameSite=None; Secure

Sau: set-cookie: cname=cval; SameSite=None; Secure; SameParty

Tùy chọn 2

Tuỳ chọn thứ hai tốn nhiều công sức hơn nhưng cho phép bạn tách biệt hoàn toàn bản dùng thử theo nguyên gốc khỏi chức năng hiện có và cho phép kiểm thử tổ hợp SameSite=Lax; SameParty.

Trước: set-cookie: cname=cval; SameSite=None; Secure

Sau:

set-cookie: cname=cval; SameSite=None; Secure
set-cookie: cname-fps=cval; SameSite=Lax; Secure; SameParty

Khi kiểm tra cookie theo các yêu cầu được gửi đến, bạn chỉ nên thấy cookie cname-fps trên yêu cầu trên nhiều trang web nếu các trang web liên quan nằm trong tập hợp này và trình duyệt đang ở trong bản dùng thử theo nguyên gốc. Hãy xem phương pháp này như việc ra mắt đồng thời một tính năng cập nhật trước khi ngừng cung cấp phiên bản trước đó.

Tại sao bạn có thể không cần nhóm của bên thứ nhất?

Đối với hầu hết các trang web, ranh giới trang web là vị trí chấp nhận được để vẽ phân vùng hoặc ranh giới quyền riêng tư. Đây là tuyến đang được đề xuất với CHIPS (Cookie có trạng thái phân vùng độc lập). Tuyến này sẽ cung cấp cho các trang web chọn tham gia thông qua thuộc tính Partitioned để vẫn có các lượt nhúng, tài nguyên, API và dịch vụ quan trọng đó trên nhiều trang web, đồng thời ngăn chặn rò rỉ thông tin nhận dạng trên các trang web.

Có một vài điều khác cần xem xét là trang web của bạn có thể vẫn ổn mà không cần thiết lập:

  • Bạn lưu trữ trên các nguồn gốc khác nhau, chứ không phải các trang web khác nhau. Trong ví dụ trên, nếu brandx.site có fly.brandx.site và drive.brandx.site thì đó là các miền con khác nhau trong cùng một trang web. Các cookie có thể sử dụng SameSite=Lax mà không cần tập hợp quy tắc nào.
  • Bạn cung cấp nội dung nhúng của bên thứ ba vào các trang web khác. Ở phần giới thiệu, ví dụ về video từ video.site được nhúng vào my-blog.site là sự phân chia rõ ràng của bên thứ ba. Các trang web do nhiều tổ chức điều hành và người dùng sẽ xem chúng là các thực thể riêng biệt. Không nên đặt hai trang web đó cùng nhau.
  • Bạn cung cấp dịch vụ đăng nhập bằng mạng xã hội của bên thứ ba. Các nhà cung cấp danh tính sử dụng những phương thức như OAuth hoặc OpenId kết nối thường dựa vào cookie của bên thứ ba để có trải nghiệm đăng nhập suôn sẻ hơn cho người dùng. Đây là trường hợp sử dụng hợp lệ, nhưng không phù hợp với Nhóm bên thứ nhất vì có sự khác biệt rõ ràng giữa các tổ chức. Các đề xuất ban đầu như WebID đang tìm cách hỗ trợ các trường hợp sử dụng này.