[OUTDATED] Set Pihak Pertama dan atribut SameParty

Banyak organisasi memiliki situs terkait dengan nama domain yang berbeda, seperti brandx.site dan fly-brandx.site—atau domain untuk negara yang berbeda seperti example.com, example.rs, example.co.uk, dan sebagainya.

Browser bergerak menuju penghentian penggunaan cookie pihak ketiga untuk meningkatkan privasi di web, tetapi situs seperti ini sering kali mengandalkan cookie untuk fungsi yang memerlukan pemeliharaan dan akses status di seluruh domain (seperti login sekali klik dan pengelolaan izin).

Set Pihak Pertama dapat mengizinkan nama domain terkait yang dimiliki dan dioperasikan oleh entitas yang sama untuk diperlakukan sebagai pihak pertama dalam situasi saat pihak pertama dan pihak ketiga diperlakukan secara berbeda. Nama domain dalam kumpulan pihak pertama dianggap pihak yang sama dan dapat memberi label pada cookie yang dimaksudkan untuk ditetapkan atau dikirim dalam konteks pihak yang sama. Tujuannya adalah untuk menemukan keseimbangan antara mencegah pelacakan lintas situs oleh pihak ketiga sekaligus mempertahankan jalur yang tidak merusak kasus penggunaan yang valid.

Proposal Set Pihak Pertama saat ini dalam fase pengujian. Baca terus untuk mengetahui cara kerjanya dan cara mencobanya.

Apa perbedaan antara cookie pihak pertama dan pihak ketiga?

Cookie tidak secara inheren merupakan cookie pihak pertama atau pihak ketiga, tetapi bergantung pada konteks saat ini tempat cookie disertakan. Hal ini dapat dilakukan pada permintaan di header cookie atau melalui document.cookie di JavaScript.

Misalnya, jika video.site memiliki cookie theme=dark, saat Anda menjelajahi video.site dan permintaan dibuat ke video.site, itu adalah konteks situs yang sama dan cookie yang disertakan adalah pihak pertama.

Namun, jika Anda menggunakan my-blog.site yang menyematkan pemutar iframe untuk video.site, saat permintaan dibuat dari my-blog.site ke video.site, konteks lintas situs dan cookie theme adalah pihak ketiga.

Diagram yang menampilkan cookie dari video.site dalam dua konteks. Cookie adalah situs yang sama jika konteks tingkat teratas juga video.site. Cookie bersifat lintas situs jika konteks tingkat teratas adalah my-blog.site dengan video.site dalam iframe.

Penyertaan cookie ditentukan oleh atribut SameSite cookie:

  • Konteks situs yang sama dengan SameSite=Lax, Strict, atau None akan membuat cookie menjadi pihak pertama.
  • Konteks lintas situs dengan SameSite=None membuat cookie menjadi pihak ketiga.

Namun, hal ini tidak selalu begitu jelas. Bayangkan brandx.site adalah situs pemesanan perjalanan dan juga menggunakan fly-brandx.site dan drive-brandx.site untuk memisahkan penerbangan dan penyewaan mobil. Selama proses pemesanan satu perjalanan, pengunjung akan beralih di antara situs ini untuk memilih berbagai opsi—mereka mengharapkan "keranjang belanja" pilihan mereka tetap ada di seluruh situs ini. brandx.site mengelola sesi pengguna dengan cookie SameSite=None untuk mengizinkannya dalam konteks lintas situs. Namun, kelemahannya adalah sekarang cookie tidak memiliki perlindungan Pemalsuan Permintaan Lintas Situs (CSRF). Jika evil.site menyertakan permintaan ke brandx.site, cookie tersebut akan disertakan.

Cookie ini bersifat lintas situs, tetapi semua situs tersebut dimiliki dan dioperasikan oleh organisasi yang sama. Pengunjung juga memahami bahwa ini adalah organisasi yang sama dan menginginkan sesi yang sama, dengan kata lain—identitas bersama, di seluruh situs.

Diagram yang menunjukkan bagaimana cookie masih dapat disertakan dalam konteks lintas situs jika situs tersebut merupakan bagian dari Set Pihak Pertama yang sama, tetapi cookie tersebut akan ditolak untuk konteks lintas situs di luar set.

Kebijakan Set Pihak Pertama

Set Pihak Pertama mengusulkan metode untuk menentukan hubungan ini secara eksplisit di beberapa situs yang dimiliki dan dioperasikan oleh pihak yang sama. Hal ini akan memungkinkan brandx.site menentukan hubungan pihak pertamanya dengan fly-brandx.site, drive-brandx.site, dan sebagainya.

Model Privasi yang mendorong berbagai proposal Privacy Sandbox didasarkan pada konsep partisi identitas untuk mencegah pelacakan lintas situs—menggambar batas antara situs yang membatasi akses ke informasi apa pun yang dapat digunakan untuk mengidentifikasi pengguna.

Diagram yang menunjukkan status yang tidak dipartisi, tempat cookie pihak ketiga yang sama dapat diakses di beberapa konteks lintas situs, berbeda dengan model yang dipartisi, tempat setiap konteks tingkat teratas memiliki instance cookie lintas situs terpisah yang mencegah aktivitas penautan di seluruh situs tersebut.

Meskipun opsi defaultnya adalah mempartisi menurut situs, yang menyelesaikan banyak kasus penggunaan pihak pertama, contoh brandx.site menunjukkan bahwa pihak pertama dapat lebih besar daripada hanya satu situs.

Diagram yang menunjukkan bagaimana instance cookie yang sama untuk satu set dapat disertakan dalam konteks lintas situs jika semua situs tersebut merupakan bagian dari set yang sama.

Bagian penting dari proposal Set Pihak Pertama adalah memastikan bahwa kebijakan di seluruh browser mencegah penyalahgunaan atau penggunaan yang tidak tepat. Misalnya, Set Pihak Pertama tidak boleh memungkinkan pertukaran informasi pengguna di seluruh situs yang tidak terkait, atau pengelompokan situs yang tidak dimiliki oleh entitas yang sama. Idenya adalah untuk memastikan bahwa Set Pihak Pertama dipetakan ke sesuatu yang dipahami seseorang sebagai pihak pertama dan tidak digunakan sebagai cara untuk membagikan identitas di berbagai pihak.

Salah satu kemungkinan cara bagi situs untuk mendaftarkan kumpulan pihak pertama adalah dengan meminta situs tersebut mengirimkan grup domain yang diusulkan ke pelacak publik (seperti repositori GitHub khusus) beserta informasi yang diperlukan untuk memenuhi kebijakan browser.

Setelah pernyataan set pihak pertama diverifikasi sesuai kebijakan, browser dapat mengambil daftar set melalui proses update.

Uji coba origin memiliki kebijakan yang ditentukan yang belum final, tetapi prinsipnya kemungkinan akan tetap sama:

  • Domain dalam set pihak pertama harus dimiliki dan dioperasikan oleh organisasi yang sama.
  • Domain harus dapat dikenali oleh pengguna sebagai grup.
  • Domain harus memiliki kebijakan privasi yang sama.

Cara menentukan set pihak pertama

Setelah mengidentifikasi anggota dan pemilik set pihak pertama organisasi, langkah penting yang harus dilakukan adalah mengirimkan set yang Anda usulkan untuk disetujui. Proses yang tepat masih dalam pembahasan.

Untuk mendeklarasikan set pihak pertama, resource JSON statis yang mencantumkan anggota dan pemilik harus dihosting di /.well-known/first-party-set di tingkat teratas setiap domain yang disertakan.

Dalam contoh kumpulan pihak pertama brandx, domain pemilik menghosting hal berikut di https://brandx.site/.well-known/first-party-set:

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

Setiap anggota set juga menghosting resource JSON statis yang mengarah kembali ke pemilik set. Di https://fly-brandx.site/.well-known/first-party-set, kita memiliki:

{ "owner": "brandx.site" }

Dan di https://drive-brandx.site/.well-known/first-party-set:

{ "owner": "brandx.site" }

Ada beberapa batasan untuk set pihak pertama:

  • Set hanya boleh memiliki satu pemilik.
  • Anggota hanya boleh berada dalam satu set, tidak boleh tumpang-tindih atau tercampur.
  • Daftar anggota dimaksudkan agar tetap relatif dapat dibaca manusia dan tidak terlalu besar.

Bagaimana pengaruh Set Pihak Pertama terhadap cookie?

Bahan yang cocok untuk cookie adalah atribut SameParty yang diusulkan. Menentukan SameParty memberi tahu browser untuk menyertakan cookie saat konteksnya adalah bagian dari set pihak pertama yang sama dengan konteks tingkat teratas.

Artinya, jika brandx.site menetapkan cookie ini:

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

Kemudian, saat pengunjung berada di fly-brandx.site dan permintaan dikirim ke brandx.site, cookie session akan disertakan dalam permintaan tersebut. Jika beberapa situs lain yang bukan bagian dari kumpulan pihak pertama, misalnya hotel.xyz, mengirim permintaan ke brandx.site, cookie tidak akan disertakan.

Diagram yang menunjukkan cookie brandx.site diizinkan atau diblokir dalam konteks lintas situs seperti yang dijelaskan.

Hingga SameParty didukung secara luas, gunakan atribut SameSite bersama dengan atribut tersebut untuk menentukan perilaku penggantian untuk cookie. Anda dapat menganggap atribut SameParty sebagai memberikan setelan antara SameSite=Lax dan SameSite=None.

  • SameSite=Lax; SameParty akan memperluas fungsi Lax untuk menyertakan konteks pihak yang sama jika didukung, tetapi kembali ke batasan Lax jika tidak.
  • SameSite=None; SameParty akan membatasi fungsi None hanya pada konteks pihak yang sama jika didukung, tetapi kembali ke izin None yang lebih luas jika tidak.

Ada beberapa persyaratan tambahan:

  • Cookie SameParty harus menyertakan Secure.
  • Cookie SameParty tidak boleh menyertakan SameSite=Strict.

Secure diwajibkan karena masih bersifat lintas situs dan Anda harus mengurangi risiko tersebut dengan memastikan koneksi yang aman (HTTPS). Demikian pula, karena ini adalah hubungan lintas situs, SameSite=Strict tidak valid karena masih memungkinkan perlindungan CSRF berbasis situs yang ketat dalam kumpulan.

Apa kasus penggunaan yang tepat untuk Set Pihak Pertama?

Set Pihak Pertama cocok untuk kasus saat organisasi memerlukan bentuk identitas bersama di berbagai situs tingkat teratas. Dalam hal ini, identitas bersama berarti apa pun, mulai dari solusi login tunggal lengkap hingga hanya memerlukan preferensi bersama di seluruh situs.

Organisasi Anda mungkin memiliki domain level teratas yang berbeda untuk:

  • Domain aplikasi: office.com,live.com, microsoft.com
  • Domain bermerek: amazon.com, audible.com / disney.com, pixar.com
  • Domain khusus negara untuk mengaktifkan pelokalan: google.co.in, google.co.uk
  • Domain layanan yang tidak pernah berinteraksi langsung dengan pengguna, tetapi menyediakan layanan di seluruh situs organisasi yang sama: gstatic.com, githubassets.com, fbcdn.net
  • Domain sandbox yang tidak pernah berinteraksi langsung dengan pengguna, tetapi ada karena alasan keamanan: googleusercontent.com, githubusercontent.com

Bagaimana cara Anda berpartisipasi?

Jika Anda memiliki sekumpulan situs yang cocok dengan kriteria di atas, ada beberapa opsi untuk berpartisipasi. Investasi yang paling ringan adalah membaca dan bergabung dalam diskusi tentang dua proposal:

Selama fase pengujian, Anda dapat mencoba fungsi menggunakan tanda command line --use-first-party-set dan memberikan daftar situs yang dipisahkan koma.

Anda dapat mencobanya di situs demo di https://fps-member1.glitch.me/ setelah memulai Chrome dengan flag berikut:

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

Hal ini berguna jika Anda ingin melakukan pengujian di lingkungan pengembangan, atau ingin mencoba menambahkan atribut SameParty di lingkungan aktif untuk melihat pengaruh kumpulan pihak pertama terhadap cookie.

Jika memiliki bandwidth untuk eksperimen dan masukan, Anda juga dapat mendaftar ke Uji Coba Origin untuk Set Pihak Pertama dan SameParty yang tersedia di Chrome dari versi 89 hingga 93.

Cara memperbarui cookie untuk uji coba origin

Jika Anda bergabung dalam uji coba origin dan menguji atribut SameParty di cookie, berikut dua pola yang perlu dipertimbangkan.

Opsi 1

Pertama, jika Anda memiliki cookie yang telah diberi label sebagai SameSite=None, tetapi ingin membatasinya ke konteks pihak pertama, Anda dapat menambahkan atribut SameParty ke cookie tersebut. Di browser tempat uji coba origin aktif, cookie tidak akan dikirim dalam konteks lintas situs di luar set.

Namun, untuk sebagian besar browser di luar uji coba origin, cookie akan terus dikirim lintas situs seperti biasa. Anggap ini sebagai pendekatan progressive enhancement.

Sebelum: set-cookie: cname=cval; SameSite=None; Secure

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

Opsi 2

Opsi kedua lebih banyak pekerjaan, tetapi memungkinkan Anda memisahkan sepenuhnya uji coba asal dari fungsi yang ada dan secara khusus memungkinkan pengujian kombinasi SameSite=Lax; SameParty.

Sebelum: set-cookie: cname=cval; SameSite=None; Secure

Setelah:

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

Saat memeriksa cookie pada permintaan masuk, Anda hanya akan melihat cookie cname-fps pada permintaan lintas situs jika situs yang terlibat ada dalam kumpulan dan browser berada dalam uji coba origin. Pertimbangkan pendekatan ini seperti peluncuran serentak fitur yang diperbarui sebelum menonaktifkan versi sebelumnya.

Mengapa Anda mungkin tidak memerlukan set pihak pertama?

Untuk sebagian besar situs, batas situsnya adalah tempat yang dapat diterima untuk menggambar partisi atau batas privasi. Ini adalah rute yang diusulkan dengan CHIPS (Cookies Having Independent Partitioned State) yang akan memberi situs rute keikutsertaan melalui atribut Partitioned agar tetap memiliki penyematan, resource, API, dan layanan lintas situs yang penting, sekaligus mencegah kebocoran informasi identifikasi di seluruh situs.

Beberapa hal lain yang perlu dipertimbangkan yang berarti situs Anda mungkin tidak memerlukan kumpulan:

  • Anda menghosting di origin yang berbeda, bukan situs yang berbeda. Pada contoh di atas, jika brandx.site memiliki fly.brandx.site dan drive.brandx.site, maka subdomain tersebut adalah subdomain yang berbeda-beda dalam situs yang sama. Cookie dapat menggunakan SameSite=Lax dan tidak perlu ditetapkan.
  • Anda menyediakan penyematan pihak ketiga ke situs lain. Dalam pengantar, contoh video dari video.site yang disematkan di my-blog.site adalah pemisah pihak ketiga yang jelas. Situs tersebut dioperasikan oleh organisasi yang berbeda dan pengguna melihatnya sebagai entitas terpisah. Kedua situs tersebut tidak boleh berada dalam satu set.
  • Anda menyediakan layanan login dengan profil sosial pihak ketiga. Penyedia identitas yang menggunakan hal-hal seperti OAuth atau OpenId connect sering kali mengandalkan cookie pihak ketiga untuk pengalaman login yang lebih lancar bagi pengguna. Ini adalah kasus penggunaan yang valid, tetapi tidak cocok untuk Set Pihak Pertama karena ada perbedaan yang jelas dalam organisasi. Proposal awal seperti WebID sedang mempelajari cara mengaktifkan kasus penggunaan ini.