[OUTDATED] Set Pihak Pertama dan atribut SameParty

Peringatan: Proposal Set Pihak Pertama telah diperbarui dan artikel ini tidak lagi diperbarui. Lihat 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 seterusnya.

Browser mulai membuat cookie pihak ketiga usang untuk meningkatkan privasi di web, tetapi situs seperti ini sering mengandalkan cookie untuk fungsi yang memerlukan pemeliharaan dan akses ke 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 tersebut diperlakukan secara berbeda. Nama domain dalam kumpulan pihak pertama dianggap sebagai pihak yang sama dan dapat memberi label cookie mana dimaksudkan untuk ditetapkan atau dikirim dalam konteks pihak yang sama. Tujuannya adalah untuk menemukan keseimbangan antara mencegah pelacakan lintas situs oleh pihak ketiga mempertahankan jalur yang tidak melanggar kasus penggunaan yang valid.

Proposal Set Pihak Pertama saat ini dalam pengujian fase ini, baca terus untuk mengetahui cara kerjanya dan bagaimana Anda bisa mencobanya.

Apa perbedaan antara cookie pihak pertama dan pihak ketiga?

Cookie pada dasarnya tidak merupakan pihak pertama atau pihak ketiga, cookie bergantung pada konteks tempat cookie disertakan. Itu berasal dari permintaan di Header cookie atau melalui document.cookie di JavaScript.

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

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

Penyertaan cookie ditentukan oleh atribut SameSite cookie:

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

Namun, ini tidak selalu terlihat jelas. Bayangkan brandx.site sedang melakukan perjalanan situs pemesanan dan mereka juga menggunakan fly-brandx.site dan drive-brandx.site untuk penerbangan terpisah dan persewaan mobil. Selama memesan satu perjalanan, pengunjung membuka kedua situs tersebut untuk memilih opsi yang berbeda—mereka menginginkan "keranjang belanja" pilihan untuk tetap ada di seluruh situs ini. brandx.site mengelola sesi pengguna dengan cookie SameSite=None untuk mengizinkannya dalam konteks lintas situs. Kelemahannya adalah cookie tidak memiliki fitur Lintas Situs Meminta perlindungan Pemalsuan (CSRF). Jika evil.site menyertakan permintaan untuk brandx.site, maka kueri akan menyertakan cookie tersebut.

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

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

Kebijakan Set Pihak Pertama

Set Pihak Pertama mengusulkan untuk secara eksplisit menentukan hubungan ini di beberapa situs yang dimiliki dan dioperasikan oleh pihak yang sama. Tindakan ini akan memungkinkan brandx.site untuk 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—membuat batas di antara situs membatasi akses ke informasi apa pun yang dapat digunakan untuk mengidentifikasi pengguna.

Sementara opsi defaultnya adalah partisi menurut situs, yang menyelesaikan banyak solusi pihak pertama kasus penggunaan, 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. 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 memetakan ke sesuatu yang dipahami seseorang sebagai pihak pertama dan tidak digunakan sebagai cara untuk berbagi identitas di antara berbagai pihak.

Salah satu cara yang memungkinkan bagi situs untuk mendaftarkan kumpulan pihak pertama adalah dengan untuk mengirimkan kumpulan domain yang mereka usulkan ke pelacak publik (seperti repositori GitHub khusus) beserta informasi yang diperlukan untuk memenuhi kebutuhan browser lebih lanjut.

Catatan: Proses persetujuan untuk kumpulan pihak pertama yang baru sedang dibahas 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 dengan kebijakan, browser dapat kemudian mengambil daftar {i>dataset<i} melalui proses pembaruan.

Uji coba origin memiliki kebijakan yang belum final, tetapi prinsipnya bersifat cenderung tetap sama:

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

Catatan: Pelajari lebih lanjut kebijakan yang diusulkan untuk Pihak Pertama Kumpulan.

Cara menentukan kumpulan pihak pertama

Setelah Anda mengidentifikasi anggota dan pemilik item baris pihak pertama organisasi langkah penting adalah mengirimkan set yang Anda usulkan untuk mendapat persetujuan. Persis prosesnya masih dalam diskusi.

Perhatian: Kumpulan pihak pertama tidak dimaksudkan sebagai daftar lengkap situs milik organisasi yang sama. Anda hanya perlu membuat kumpulan antar situs jika Anda secara eksplisit membutuhkan cookie lintas situs yang diizinkan di seluruh situs. Pastikan Anda melihat Kasus penggunaan yang tepat untuk Set Pihak Pertama Uji Coba Origin? di bawah.

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

Pada contoh kumpulan pihak pertama brandx, domain pemilik menghosting mengikuti 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, kami mendapatkan:

{ "owner": "brandx.site" }

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

{ "owner": "brandx.site" }

Ada beberapa batasan untuk kumpulan pihak pertama:

• Suatu kumpulan hanya boleh memiliki satu pemilik.
• Anggota hanya dapat dimiliki oleh satu kumpulan, tidak ada yang tumpang-tindih atau bercampur.
• Daftar anggota dimaksudkan agar tetap dapat dibaca manusia dan tidak terlalu besar.

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

Bagaimana pengaruh Set Pihak Pertama terhadap cookie?

Bahan yang cocok untuk kue adalah SameParty yang diusulkan . Menentukan SameParty memberi tahu browser untuk menyertakan cookie ketika konteksnya adalah bagian dari 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 pada permintaan tersebut. Jika beberapa situs lain yang bukan bagian dari kumpulan pihak pertama, hotel.xyz, mengirim permintaan ke brandx.site, cookie tidak akan disertakan.

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

Ada beberapa persyaratan tambahan:

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

Secure dimandatkan karena masih bersifat lintas situs dan Anda harus mengurangi hal-hal tersebut risiko 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 dengan cookie dapat dikirim, tetapi tidak membuat toples cookie bersama. Cookie dari brandx.site hanya tersedia pada permintaan atau dokumen untuk brandx.site, cookie tidak pernah tersedia secara langsung untuk fly-brandx.site. Ini bisa membingungkan karena Anda mungkin melihat hal ini dirujuk sebagai identitas bersama, tapi ini berarti bahwa batasan yang ada di antara situs-situs tersebut memungkinkan pengguna menyetel atau mengirim cookie dalam konteks lintas situs pihak yang sama bahwa cookie dibagikan secara langsung.

Kasus penggunaan apa yang tepat untuk Set Pihak Pertama?

Set Pihak Pertama cocok untuk kasus ketika organisasi membutuhkan identitas bersama di berbagai situs tingkat atas. Identitas bersama dalam kasus ini dapat berarti apa saja, mulai dari solusi single sign-on yang lengkap hingga sekadar kebutuhan preferensi di seluruh situs.

Catatan: Anda dapat mengidentifikasi kandidat yang memungkinkan untuk kasus penggunaan ini karena adalah contoh saat Anda telah menandai cookie sebagai SameSite=None bahkan meskipun ini hanya untuk konteks lintas situs tempat Anda adalah pemilik 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 khusus negara untuk mengaktifkan pelokalan: google.co.in, google.co.uk
• Domain layanan yang tidak pernah berinteraksi secara langsung dengan pengguna, tetapi berikan layanan di situs organisasi yang sama: gstatic.com, githubassets.com, fbcdn.net
• Domain sandbox yang tidak pernah berinteraksi secara langsung dengan pengguna, tetapi ada untuk alasan keamanan: googleusercontent.com, githubusercontent.com

Bagaimana cara Anda terlibat?

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

• Diskusi Grup Komunitas Privasi Set Pihak Pertama
• Diskusi atribut cookie Pihak yang Sama

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

Anda dapat mencobanya pada 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 Coba tambahkan atribut SameParty di lingkungan aktif untuk melihat performa yang ditetapkan pihak pertama akan memengaruhi cookie.

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

Istilah penting: uji coba terbatas adalah cara Chrome untuk memungkinkan developer eksternal melakukan pengujian proposal awal dalam skenario dunia nyata untuk memberikan masukan yang diperlukan untuk dan melakukan iterasi menuju sesuatu yang memenuhi kebutuhan platform web. Pelajari selengkapnya di Memulai asal Chrome uji coba.

Cara mengupdate cookie untuk uji coba origin

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

Opsi 1

Pertama, jika Anda memiliki cookie yang diberi label sebagai SameSite=None, tetapi Anda ingin membatasi ke konteks pihak pertama, Anda dapat menambahkan SameParty kepada mereka. Di browser tempat uji coba origin aktif, cookie akan tidak 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. Pertimbangkan hal ini sebagai pendekatan progressive enhancement.

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

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

Opsi 2

Opsi kedua memberikan lebih banyak pekerjaan, tetapi memungkinkan Anda sepenuhnya memisahkan origin uji coba 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 seharusnya hanya melihat cookie cname-fps pada permintaan lintas situs jika situs yang terlibat berada dalam dan browser berada dalam uji coba origin. Pertimbangkan pendekatan ini peluncuran fitur yang diupdate secara bersamaan sebelum menonaktifkan .

Mengapa Anda tidak memerlukan set pihak pertama?

Untuk sebagian besar situs, batas situs mereka adalah tempat yang dapat diterima untuk menarik partisi atau batas privasi. Ini adalah rute yang diusulkan bersama CHIPS (Cookie yang Memiliki Partisi Independen provinsi) yang akan memberikan keikutsertaan situs dirutekan melalui atribut Partitioned agar tetap memiliki lintas lokasi penting sematan, resource, API, dan layanan, sekaligus mencegah kebocoran informasi informasi lintas situs.

Beberapa hal lain yang perlu dipertimbangkan yang berarti situs Anda mungkin akan baik-baik saja tanpa memerlukan satu set:

• Anda menghosting situs dari origin yang berbeda, bukan situs yang berbeda. Pada contoh di atas, jika brandx.site memiliki fly.brandx.site dan drive.brandx.site, maka adalah subdomain yang berbeda, semuanya dalam situs yang sama. Cookie tersebut dapat menggunakan SameSite=Lax dan tidak ada yang disetel.
• Anda menyediakan sematan pihak ketiga ke situs lain. Sebagai pengantar, contoh video dari video.site yang disematkan di my-blog.site merupakan pihak ketiga yang jelas bagi. Situs dioperasikan oleh organisasi yang berbeda dan pengguna melihatnya sebagai entity terpisah. Kedua situs tersebut tidak boleh berada dalam satu rangkaian.
• Anda menyediakan layanan login media sosial pihak ketiga. Penyedia identitas yang menggunakan hal-hal seperti OAuth atau OpenID Connect sering mengandalkan cookie pihak ketiga 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 mempelajari cara-cara untuk memungkinkan kasus penggunaan ini.