[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 với tên miền khác nhau, chẳng hạn như brandx.site và fly-brandx.site hoặc miền cho các quốc gia khác nhau như example.com, example.rs, example.co.uk, v.v.

Các trình duyệt đang hướng tới việc ngừng sử dụng cookie của bên thứ ba để cải thiện quyền riêng tư trên web, nhưng các trang web như vậy thường dựa vào cookie cho các chức năng yêu cầu duy trì và truy cập trạng thái trên các miền (chẳng hạn như tính năng đă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 có liên quan do cùng một pháp nhân sở hữu và vận hành là bên thứ nhất trong trường hợp bên thứ nhất và bên thứ ba được coi là khác nhau. Tên miền trong một nhóm bên thứ nhất được coi là cùng bên và có thể gắn nhãn cho những cookie dự định được đặt hoặc gửi trong ngữ cảnh cùng bên. Mục đích là tìm ra điểm cân bằng giữa việc ngăn chặn hoạt động theo dõi qua nhiều trang web của bên thứ ba, đồng thời vẫn duy trì một đường dẫn không làm gián đoạn các trường hợp sử dụng hợp lệ.

Đề xuất về Nhóm bên thứ nhất hiện đang ở giai đoạn thử nghiệm. Hãy đọc tiếp để tìm hiểu cách hoạt động của đề xuất này 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à cookie của bên thứ ba là gì?

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

Ví dụ: nếu video.site có một cookie theme=dark, khi bạn đang duyệt xem 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 được đưa vào 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, đó là bối cảnh trên nhiều trang web và cookie theme là bên thứ ba.

Sơ đồ cho thấy một cookie từ video.site trong hai ngữ cảnh. Cookie này là cùng trang web khi ngữ cảnh cấp cao nhất cũng là video.site. Cookie này là cookie 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 đưa cookie vào được xác định bằng thuộc tính SameSite của cookie:

  • Ngữ cảnh trên cùng một trang web với SameSite=Lax, Strict hoặc None sẽ khiến cookie trở thành cookie của bên thứ nhất.
  • Ngữ cảnh trên nhiều trang web với SameSite=None sẽ khiến cookie trở thành cookie của bên thứ ba.

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

Sơ đồ cho thấy cách một cookie vẫn có thể được đưa vào ngữ cảnh trên 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 cookie đó sẽ bị từ chối đối với ngữ cảnh trên nhiều trang web nằm ngoài nhóm.

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õ 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ệ của 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 về 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 chặn hoạt động theo dõi trên nhiều trang web, vẽ ranh giới giữa các trang web để hạn chế quyền truy cập vào bất kỳ thông tin nào có thể dùng để xác định người dùng.

Sơ đồ cho thấy trạng thái không phân vùng, trong đó bạn có thể truy cập vào cùng một cookie của bên thứ ba trong nhiều ngữ cảnh trên nhiều trang web, trái ngược với mô hình phân vùng, trong đó mỗi ngữ cảnh cấp cao nhất có một thực thể riêng biệt của cookie trên nhiều trang web, ngăn chặn hoạt động liên kết trên 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 bên thứ nhất, nhưng ví dụ về brandx.site cho thấy một bên thứ nhất có thể lớn hơn một trang web.

Sơ đồ minh hoạ cách một thực thể cookie cho một tập hợp có thể được đưa vào ngữ cảnh trên nhiều trang web khi tất cả các trang web đó đều thuộc cùng một tập hợp.

Một phần quan trọng trong đề xuất về 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 lạm dụng. Ví dụ: Nhóm bên thứ nhất không được cho phép trao đổi thông tin người dùng trên các trang web không liên quan hoặc nhóm các trang web không thuộc cùng một pháp nhân. Ý tưởng là đảm bảo rằng một Tập hợp bên thứ nhất liên kết đến một đối tượng mà người dùng 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 để trang web đăng ký một nhóm bên thứ nhất có thể là trang web gửi nhóm miền đề xuất của họ đến một trình theo dõi công khai (chẳng hạn như kho lưu trữ GitHub chuyên dụng) cùng với thông tin cần thiết để đáp ứng chính sách của trình duyệt.

Sau khi xác minh câu nhận định về nhóm bên thứ nhất theo chính sách, 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.

Chương trình thử nghiệm nguồn gốc có một chính sách đã xác định nhưng chưa phải là chính sách cuối cùng, nhưng các nguyên tắc có thể vẫn giữ nguyên:

  • Các miền trong một nhóm bên thứ nhất phải do cùng một tổ chức sở hữu và vận hành.
  • Người dùng phải nhận ra các 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 tập hợp bên thứ nhất

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

Để khai báo một nhóm bên thứ nhất, bạn phải lưu trữ các tài nguyên JSON tĩnh liệt kê thành viên và chủ sở hữu 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 bên thứ nhất brandx, miền của chủ sở hữu 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ỏ 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 ta có:

{ "owner": "brandx.site" }

Và tại https://drive-brandx.site/.well-known/first-party-set:

{ "owner": "brandx.site" }

Có một số quy tắc ràng buộc đối với nhóm bên thứ nhất:

  • Một bộ chỉ có thể có một chủ sở hữu.
  • Một thành phần chỉ có thể thuộc về một tập hợp, không được trùng lặp hoặc kết hợp.
  • Danh sách thành viên phải 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 đưa cookie vào khi ngữ cảnh của cookie đó thuộc cùng một nhóm bên thứ nhất với 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 đang ở 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 số trang web 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 sẽ không được đưa vào.

Sơ đồ cho thấy cookie brandx.site được cho phép hoặc bị chặn trong các ngữ cảnh trên 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 này để xác định hành vi dự phòng cho cookie. Bạn có thể coi thuộc tính SameParty là một chế độ cài đặt giữa SameSite=Lax và SameSite=None.

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

Có một số yêu cầu khác:

  • 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à cookie trên nhiều trang web và bạn nên giảm thiểu các 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ệ CSRF chặt chẽ dựa trên trang web trong một tập hợp.

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

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

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

  • Miền ứng dụng: office.com,live.com, microsoft.com
  • Miền có thương hiệu: amazon.com, audible.com / disney.com, pixar.com
  • Miền theo quốc gia để bật tính năng bản địa hoá: google.co.in, google.co.uk
  • 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 các dịch vụ trên các trang web của cùng một tổ chức: gstatic.com, githubassets.com, fbcdn.net
  • 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í nêu trên, thì bạn có một số lựa chọn để tham gia. Khoản đầu tư nhẹ nhất là đọc và tham gia thảo luận về hai đề xuất:

Trong giai đoạn thử nghiệm, bạn có thể 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ử tính năng này trên trang web minh hoạ tại https://fps-member1.glitch.me/ sau khi khởi động Chrome bằng 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 trực tiếp để xem cách một nhóm bên thứ nhất sẽ ảnh hưởng đến cookie.

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

Cách cập nhật cookie cho thử nghiệm theo nguyên gốc

Nếu bạn đang tham gia thử nghiệm theo nguyên gốc và kiểm thử thuộc tính SameParty trên cookie, hãy cân nhắc hai mẫu sau.

Tùy chọn 1

Trước tiên, nếu bạn có các cookie được gắn nhãn là SameSite=None nhưng bạn muốn hạn chế ở bối cảnh bên thứ nhất, thì 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 thử nghiệm theo nguyên gốc, cookie sẽ không được gửi trong ngữ cảnh trên nhiều trang web bên ngoài tập hợp.

Tuy nhiên, đối với phần lớn trình duyệt bên ngoài thử nghiệm theo nguyên gốc, cookie sẽ tiếp tục được gửi trên nhiều trang web như bình thường. Hãy xem đây là một phương pháp cải tiến dần 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 sẽ tốn nhiều công sức hơn, nhưng cho phép bạn tách hoàn toàn thử nghiệm gốc khỏi chức năng hiện có và cho phép kiểm thử cụ 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 trên các yêu cầu sắp tới, 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 nhóm và trình duyệt đang trong giai đoạn thử nghiệm theo nguồn gốc. Hãy xem phương pháp này như một cách chạy đồng thời tính năng đã cập nhật trước khi tắt phiên bản trước.

Tại sao bạn có thể không cần nhóm 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 đường được đề xuất với CHIPS (Cookie có trạng thái phân vùng độc lập). Tuyến đường này sẽ cung cấp cho các trang web một tuyến đường chọn tham gia thông qua thuộc tính Partitioned để vẫn có các phần 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 việc rò rỉ thông tin nhận dạng trên các trang web.

Một vài điều khác cần cân nhắc có thể giúp trang web của bạn không cần phải có bộ:

  • Bạn lưu trữ trên nhiều nguồn gốc, chứ không phải trên nhiều trang web. 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. Cookie có thể sử dụng SameSite=Lax và không cần thiết lập.
  • Bạn cung cấp tính năng nhúng của bên thứ ba cho các trang web khác. Trong phần giới thiệu, ví dụ về một video từ video.site được nhúng trên my-blog.site là một ranh giới rõ ràng của bên thứ ba. Các trang web này do các tổ chức khác nhau vận hành và người dùng xem các trang web này là các thực thể riêng biệt. Hai trang web đó không được nằm trong cùng một nhóm.
  • Bạn cung cấp dịch vụ đăng nhập qua mạng xã hội của bên thứ ba. Các nhà cung cấp danh tính sử dụng các tính năng như OAuth hoặc OpenId connect thường dựa vào cookie của bên thứ ba để mang lại trải nghiệm đăng nhập mượt mà hơn cho người dùng. Đây là một trường hợp sử dụng hợp lệ, nhưng không phù hợp với Tập hợp bên thứ nhất vì có sự khác biệt rõ ràng về cách tổ chức. Các đề xuất ban đầu như WebID đang khám phá các cách để hỗ trợ những trường hợp sử dụng này.