[OUTDATED] Set Pihak Pertama dan atribut SameParty

Peringatan: Proposal Set Pihak Pertama telah diperbarui dan artikel ini tidak lagi diperbarui. Baca penjelasan dan petunjuk pengujian untuk mendapatkan informasi terbaru.

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 mulai membuat cookie pihak ketiga tidak digunakan lagi 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 single sign-on 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 ketika pihak pertama dan pihak ketiga diperlakukan secara berbeda. Nama domain dalam kumpulan pihak pertama dianggap sebagai pihak yang sama dan dapat memberi label cookie mana yang ditujukan untuk ditetapkan atau dikirim dalam konteks pihak yang sama. Tujuannya adalah untuk menemukan keseimbangan antara mencegah pelacakan lintas situs oleh pihak ketiga sambil tetap mempertahankan jalur yang tidak merusak kasus penggunaan yang valid.

Proposal Set Pihak Pertama saat ini sedang dalam tahap pengujian, baca terus untuk mengetahui cara kerjanya dan cara mencobanya.

Apa perbedaan antara cookie pihak pertama dan pihak ketiga?

Cookie pada dasarnya bukan pihak pertama atau pihak ketiga, melainkan bergantung pada konteks saat ini tempat cookie disertakan. Baik itu permintaan di header cookie atau melalui document.cookie di JavaScript.

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

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

Penyertaan cookie ditentukan oleh atribut SameSite cookie:

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

Namun, hal ini tidak selalu jelas. Bayangkan brandx.site adalah situs pemesanan perjalanan dan dia juga menggunakan fly-brandx.site dan drive-brandx.site untuk memisahkan penerbangan dan penyewaan mobil. Selama memesan satu perjalanan, pengunjung beralih antar-situs untuk memilih opsi yang berbeda—mereka berharap "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. Kelemahannya adalah saat ini cookie tidak memiliki perlindungan Pemalsuan Permintaan Lintas Situs (CSRF). Jika evil.site menyertakan permintaan ke brandx.site, permintaan tersebut akan mencakup cookie tersebut.

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

Catatan: Dengan Set Pihak Pertama, ada rute untuk menentukan situasi saat konteks lintas situs masih merupakan pihak pertama. Cookie dapat disertakan dalam kumpulan pihak pertama dan dikecualikan dalam konteks pihak ketiga.

Kebijakan Set Pihak Pertama

Set Pihak Pertama mengusulkan metode untuk secara eksplisit menentukan hubungan ini 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 seterusnya.

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

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

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

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

Catatan: Proses persetujuan untuk kumpulan pihak pertama yang baru sedang dalam pembahasan dengan W3C dan salah satu opsi yang dipertimbangkan adalah agar verifikasi ditangani oleh entitas independen, bukan perusahaan 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 kumpulan 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.

Catatan: Pelajari lebih lanjut kebijakan yang disarankan untuk Set Pihak Pertama.

Cara menentukan kumpulan pihak pertama

Setelah Anda mengidentifikasi anggota dan pemilik set pihak pertama organisasi, langkah penting adalah mengirimkan kumpulan yang diusulkan untuk mendapatkan persetujuan. Proses persisnya masih dalam diskusi.

Perhatian: Kumpulan pihak pertama tidak dimaksudkan sebagai daftar lengkap situs yang dimiliki oleh organisasi yang sama. Anda hanya perlu membuat kumpulan antar-situs jika Anda secara eksplisit memerlukan cookie lintas situs yang diizinkan di situs-situs tersebut. Pastikan Anda membaca Kasus penggunaan apa yang tepat untuk Uji Coba Origin Set Pihak Pertama? di bawah.

Untuk mendeklarasikan set pihak pertama, resource JSON statis yang mencantumkan anggota dan pemilik harus dihosting di /.well-known/first-party-set pada level 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 kumpulan juga menghosting resource JSON statis yang mengarah kembali ke pemilik kumpulan. Di https://fly-brandx.site/.well-known/first-party-set, kami memiliki:

{ "owner": "brandx.site" }

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

{ "owner": "brandx.site" }

Ada beberapa batasan untuk set pihak pertama:

• Satu kumpulan hanya dapat memiliki satu pemilik.
• Anggota hanya boleh tergabung dalam satu kumpulan, tidak ada tumpang tindih atau campuran.
• Daftar anggota dimaksudkan agar tetap dapat dibaca oleh manusia dan tidak terlalu besar.

Catatan: Anda mungkin sudah menghosting file serupa jika menggunakan Digital Asset Links untuk menautkan situs yang memiliki backend pengelolaan akun yang sama. Hal ini secara khusus memungkinkan kredensial yang sama disarankan oleh pengelola sandi Chrome di seluruh situs terafiliasi.

Bagaimana pengaruh Set Pihak Pertama terhadap cookie?

Bahan yang cocok untuk cookie adalah atribut SameParty yang diusulkan. Menentukan SameParty akan memberi tahu browser untuk menyertakan cookie saat konteksnya adalah bagian dari pihak pertama yang sama yang ditetapkan sebagai konteks tingkat atas.

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 mengarah ke brandx.site, cookie session akan disertakan dalam permintaan tersebut. Jika beberapa situs lain yang bukan bagian dari kumpulan pihak pertama, misalnya hotel.xyz, mengirimkan permintaan ke brandx.site, cookie tidak akan disertakan.

Hingga SameParty didukung secara luas, gunakan atribut SameSite bersamanya untuk menentukan perilaku penggantian cookie. Anda dapat menganggap atribut SameParty sebagai memberi Anda 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 pembatasan Lax jika tidak didukung.
• SameSite=None; SameParty akan membatasi fungsi None hanya ke konteks pihak yang sama jika didukung, tetapi akan kembali ke izin None yang lebih luas jika tidak didukung.

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 (HTTPS) yang aman. Demikian juga, karena ini adalah hubungan lintas situs, SameSite=Strict tidak valid karena masih memungkinkan perlindungan CSRF berbasis situs yang ketat dalam satu set.

Poin penting: Atribut SameParty hanya memengaruhi konteks tempat cookie dapat dikirim. Atribut ini tidak membuat jar cookie bersama. Cookie dari brandx.site hanya tersedia pada permintaan atau dokumen untuk brandx.site, cookie tersebut tidak pernah tersedia secara langsung untuk fly-brandx.site. Hal ini dapat membingungkan karena Anda mungkin melihat ini dirujuk sebagai identitas bersama, tetapi ini berarti bahwa batasan yang longgar antar-situs memungkinkan situs menetapkan atau mengirim cookie dalam konteks pihak yang sama, lintas situs, bukan bahwa cookie dibagikan secara langsung.

Kasus penggunaan apa yang tepat untuk Set Pihak Pertama?

Set Pihak Pertama cocok untuk kasus-kasus saat suatu organisasi memerlukan bentuk identitas bersama di berbagai situs tingkat atas. Dalam hal ini, identitas bersama dapat berarti mulai dari solusi single sign-on penuh hingga kebutuhan akan preferensi bersama di seluruh situs.

Catatan: Anda dapat mengidentifikasi kemungkinan kandidat untuk kasus penggunaan tersebut karena kandidat tersebut akan menjadi instance di mana Anda telah menandai cookie sebagai SameSite=None meskipun hanya untuk konteks lintas situs tempat Anda memiliki semua situs yang terlibat.

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 spesifik per negara untuk mengaktifkan pelokalan: google.co.in, google.co.uk
• Domain layanan yang tidak pernah digunakan pengguna untuk berinteraksi langsung, tetapi menyediakan layanan di seluruh situs organisasi yang sama: gstatic.com, githubassets.com, fbcdn.net
• Domain sandbox yang tidak pernah digunakan pengguna secara langsung, tetapi ada karena alasan keamanan: googleusercontent.com, githubusercontent.com

Bagaimana Anda bisa terlibat?

Jika Anda memiliki kumpulan situs yang cocok dengan kriteria di atas, ada sejumlah opsi untuk terlibat. Investasi paling ringan adalah dengan membaca dan mengikuti diskusi tentang kedua proposal tersebut:

• Diskusi Grup Komunitas Privasi Set Pihak Pertama
• Diskusi atribut cookie SameParty

Selama fase pengujian, Anda dapat mencoba fungsi ini 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 tanda 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 set 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.

Istilah penting: uji coba ketat adalah cara Chrome yang memungkinkan developer eksternal menguji proposal awal dalam skenario dunia nyata untuk memberikan masukan yang diperlukan guna berkembang dan melakukan iterasi menuju sesuatu yang memenuhi kebutuhan platform web. Pelajari lebih lanjut di Mulai menggunakan uji coba origin Chrome.

Cara mengupdate cookie untuk uji coba origin

Jika Anda bergabung ke uji coba origin dan menguji atribut SameParty pada 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 kumpulan.

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

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

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

Opsi 2

Opsi kedua adalah lebih banyak pekerjaan, tetapi memungkinkan Anda untuk sepenuhnya memisahkan uji coba origin 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 berada dalam kumpulan dan browser berada dalam uji coba origin. Pertimbangkan pendekatan ini seperti peluncuran serentak fitur yang diupdate sebelum menonaktifkan versi sebelumnya.

Mengapa Anda tidak memerlukan set pihak pertama?

Untuk sebagian besar situs, batas situsnya adalah tempat yang dapat diterima untuk menggambar batas partisi atau privasi. Ini adalah rute yang diusulkan dengan CHIPS (Cookie Memiliki Status Partisi Independen) yang akan memberikan rute keikutsertaan melalui atribut Partitioned agar tetap memiliki sematan, resource, API, dan layanan lintas situs yang penting, sekaligus mencegah kebocoran informasi di seluruh situs.

Beberapa hal lain yang perlu dipertimbangkan yang berarti bahwa situs Anda mungkin baik-baik saja tanpa memerlukan kumpulan:

• Anda menghosting situs asal yang berbeda, bukan situs yang berbeda. Dalam contoh di atas, jika brandx.site memiliki fly.brandx.site dan drive.brandx.site, maka subdomain tersebut adalah subdomain yang berbeda, yang semuanya ada di dalam situs yang sama. Cookie tersebut dapat menggunakan SameSite=Lax dan tidak diperlukan set.
• Anda memberikan sematan pihak ketiga ke situs lain. Di pengantar, contoh video dari video.site yang disematkan di my-blog.site adalah pembagian pihak ketiga yang jelas. Situs dioperasikan oleh berbagai organisasi dan pengguna melihatnya sebagai entitas terpisah. Kedua situs tersebut tidak boleh berada dalam satu kumpulan.
• Anda menyediakan layanan login dengan media sosial pihak ketiga. Penyedia identitas yang menggunakan fitur 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 mencari cara untuk mengaktifkan kasus penggunaan ini.