Pihak ketiga

Apa yang dimaksud dengan pihak ketiga?

Sangat jarang ada situs web yang sepenuhnya mandiri. HTTP Web Almanac menunjukkan bahwa sebagian besar situs—sekitar 95%—berisi beberapa konten pihak ketiga.

Almanak mendefinisikan konten pihak ketiga sebagai sesuatu yang dihosting pada asal bersama dan bersifat publik, yang digunakan secara luas oleh berbagai situs dan tidak dipengaruhi oleh masing-masing pemilik situs. Materi ini dapat berupa gambar atau media lain seperti video, font, atau skrip. Gambar dan skrip memperhitungkan lebih dari semua yang lain jika digabungkan. Konten pihak ketiga tidak penting untuk mengembangkan situs, tetapi mungkin juga; Anda hampir dipastikan akan menggunakan sesuatu yang dimuat dari server bersama publik, baik font web, iframe video tersemat, iklan, atau pustaka JavaScript. Misalnya, Anda mungkin menggunakan font web yang ditayangkan dari Google Fonts, atau mengukur analisis dengan Google Analytics; Anda dapat menambahkan tombol Suka atau tombol Login Dengan dari jaringan sosial; Anda dapat menyematkan peta atau video, atau menangani pembelian belanja melalui layanan pihak ketiga; Anda mungkin melacak error dan mencatat log untuk tim pengembangan Anda sendiri melalui alat pemantauan pihak ketiga.

Untuk tujuan privasi, sebaiknya pertimbangkan definisi yang sedikit berbeda dan tidak terlalu luas: resource pihak ketiga, dan khususnya skrip pihak ketiga, ditayangkan dari asal yang dibagikan dan bersifat publik serta digunakan secara luas seperti yang diilustrasikan, tetapi juga ditulis oleh orang selain pemilik situs. Aspek kepengarangan pihak ketiga adalah hal yang penting saat mempertimbangkan cara melindungi privasi pengguna dari orang lain. Hal ini akan membuat Anda mempertimbangkan risiko yang ada, lalu memutuskan bagaimana atau apakah akan menggunakan resource pihak ketiga berdasarkan risiko tersebut. Seperti yang sudah dibahas, hal-hal ini akan membantu Anda memahami konteks dan oleh karena itu untuk memahami kompromi mana yang perlu Anda lakukan, dan apa artinya.

Ini sebenarnya tidak benar ketika membahas "sumber daya pihak ketiga" secara umum: perbedaan antara pihak pertama dan pihak ketiga sebenarnya adalah tentang konteks yang menggunakan sesuatu. Skrip yang dimuat dari situs lain adalah resource pihak ketiga, dan permintaan HTTP yang memuat skrip tersebut dapat menyertakan cookie, tetapi cookie tersebut sebenarnya bukan "cookie pihak ketiga"; cookie tersebut hanya cookie, dan apakah skrip tersebut "pihak ketiga" atau "pihak pertama" bergantung pada apakah skrip dimuat di halaman di situs Anda atau halaman di situs pemilik skrip.

Mengapa kami menggunakan resource pihak ketiga?

Pihak ketiga adalah cara yang bagus untuk menambahkan fungsi ke situs Anda. Fitur tersebut bisa berupa fitur yang diekspos kepada pengguna, atau fungsi developer yang tidak terlihat seperti pelacakan error, tetapi fitur tersebut mengurangi beban pengembangan Anda, dan skrip itu sendiri dikelola oleh orang lain: tim pengembangan layanan yang Anda sertakan. Semua ini berhasil karena kekomposisian web: kemampuan untuk menyatukan bagian-bagian untuk membentuk keseluruhan yang lebih besar dari jumlahnya.

Almanak Web Arsip HTTP memberikan deskripsi yang jelas:

Pihak ketiga memberikan koleksi gambar, video, font, alat, library, widget, pelacak, iklan, dan hal lainnya yang tidak ada habisnya seperti disematkan ke dalam halaman web kami. Dengan begitu, orang yang paling tidak teknis pun dapat membuat dan memublikasikan konten ke web. Tanpa pihak ketiga, web mungkin akan menjadi media akademik yang sangat membosankan, berbasis teks, dan bukan platform yang kaya, imersif, dan kompleks, yang sangat penting bagi kehidupan kita saat ini.

Apa yang dapat dilakukan resource pihak ketiga?

Mengakses beberapa informasi

Saat Anda menggunakan resource pihak ketiga di situs, apa pun resource tersebut, beberapa informasi akan diteruskan ke pihak ketiga tersebut. Misalnya, jika Anda menyertakan gambar dari situs lain, permintaan HTTP yang dibuat oleh browser pengguna akan meneruskan header Perujuk dengan URL laman, serta alamat IP pengguna.

Pelacakan lintas situs

Melanjutkan contoh yang sama—saat gambar dimuat dari situs pihak ketiga, gambar dapat menyertakan cookie, dan cookie tersebut akan dikirim kembali ke pihak ketiga saat pengguna meminta gambar tersebut lagi. Artinya, pihak ketiga dapat mengetahui bahwa layanan mereka sedang digunakan di situs Anda, dan dapat mengirim kembali cookie, kemungkinan dengan ID unik untuk pengguna tersebut. Artinya, saat pengguna mengunjungi situs Anda lagi, atau situs lain yang menyertakan resource dari pihak ketiga tersebut, cookie ID unik akan dikirim lagi. Hal ini memungkinkan pihak ketiga membuat log tentang tempat kunjungan pengguna tersebut: situs Anda, situs lain yang menggunakan resource pihak ketiga yang sama, di seluruh web.

Ini adalah pelacakan lintas situs: memungkinkan pihak ketiga mengumpulkan log aktivitas pengguna di banyak situs, selama semua situs tersebut menggunakan resource yang berasal dari pihak ketiga yang sama. Dapat berupa font, gambar, atau stylesheet—semua resource statis. Aset ini juga dapat berupa referensi dinamis: skrip, tombol media sosial, iklan. Skrip yang disertakan dapat mengumpulkan lebih banyak informasi karena bersifat dinamis: skrip ini dapat memeriksa browser dan lingkungan pengguna serta meneruskan data tersebut kembali ke originnya. Skrip apa pun dapat melakukan hal ini hingga batas tertentu, seperti halnya resource dinamis yang tidak ada sebagai skrip, seperti sematan media sosial atau iklan atau tombol bagikan. Jika Anda melihat detail banner cookie di situs populer, Anda dapat melihat daftar organisasi yang dapat menambahkan cookie pelacakan ke pengguna Anda guna membuat gambaran tentang aktivitas mereka untuk membuat profil pengguna tersebut. Mungkin ada ratusan. Jika pihak ketiga menawarkan layanan secara gratis, salah satu cara agar hal ini dapat dilakukan secara ekonomis adalah karena mereka mengumpulkan lalu memonetisasi data ini.

Panduan yang berguna untuk jenis masalah privasi yang membuat browser harus melindungi penggunanya adalah Model Ancaman Privasi Target. Ini adalah dokumen yang masih dibahas pada saat dokumen ini ditulis, tetapi memberikan beberapa klasifikasi tingkat tinggi tentang jenis ancaman privasi yang ada. Risiko dari resource pihak ketiga utamanya adalah "pengenalan lintas situs yang tidak diinginkan", yaitu ketika situs dapat mengidentifikasi pengguna yang sama di beberapa situs, dan "pengungkapan informasi sensitif", yang memungkinkan situs mengumpulkan informasi yang dianggap sensitif oleh pengguna.

Hal ini adalah perbedaan utama: pengenalan lintas situs yang tidak diinginkan akan berdampak buruk meskipun pihak ketiga tidak mengumpulkan informasi sensitif tambahan darinya, karena hal ini menghilangkan kontrol pengguna atas identitas mereka. Mendapatkan akses ke perujuk dan alamat IP serta cookie pengguna merupakan bentuk pengungkapan yang tidak diinginkan. Penggunaan resource pihak ketiga disertai dengan komponen perencanaan tentang cara penggunaannya dengan cara yang menjaga privasi. Sebagian pekerjaan tersebut adalah tanggung jawab Anda sebagai developer situs, dan sebagian dilakukan oleh browser dalam perannya sebagai agen pengguna; yaitu, agen yang bekerja atas nama pengguna untuk menghindari pengungkapan informasi sensitif dan pengakuan lintas situs yang tidak diinginkan jika memungkinkan. Di bawah ini kita akan mempelajari secara lebih mendetail tentang mitigasi dan pendekatan pada tingkat browser dan tingkat pengembangan situs.

Kode pihak ketiga sisi server

Definisi awal kami tentang pihak ketiga sengaja mengubah pendekatan sisi klien HTTP Almac (sebagaimana sesuai untuk laporan mereka!), untuk menyertakan kepengarangan pihak ketiga, karena dari perspektif privasi, pihak ketiga adalah siapa pun yang mengetahui apa pun tentang pengguna Anda, yang bukan Anda.

Ini termasuk pihak ketiga yang menyediakan layanan yang Anda gunakan di server, serta klien. Dari sudut pandang privasi, library pihak ketiga (seperti konten yang disertakan dari NPM atau Composer atau NuGet) juga penting untuk dipahami. Apakah dependensi Anda meneruskan data ke luar batas Anda? Jika Anda meneruskan data ke layanan logging atau database yang dihosting dari jarak jauh, jika library yang Anda sertakan juga "phone home" ke penulisnya, maka hal ini dapat melanggar privasi pengguna dan oleh karena itu perlu diaudit. Pihak ketiga berbasis server biasanya harus menyerahkan data pengguna oleh Anda, yang berarti data yang dieksposnya lebih berada di bawah kendali Anda. Sebaliknya, pihak ketiga berbasis klien, yaitu skrip atau resource HTTP yang disertakan di situs Anda dan diambil oleh browser pengguna, dapat mengumpulkan beberapa data langsung dari pengguna tanpa perlu mediasi proses pengumpulan tersebut oleh Anda. Sebagian besar modul ini akan membahas cara mengidentifikasi pihak ketiga sisi klien yang Anda pilih untuk menyertakan dan mengekspos pengguna Anda, karena Anda lebih sedikit melakukan mediasi. Namun, ada baiknya Anda mempertimbangkan untuk mengamankan kode sisi server agar memahami komunikasi keluar dari kode tersebut dan dapat mencatat atau memblokir kode yang tidak terduga. Detail tentang cara melakukan hal ini secara tepat berada di luar cakupan kami di sini (dan sangat bergantung pada penyiapan server Anda), tetapi ini adalah bagian lain dari upaya keamanan dan privasi Anda.

Mengapa Anda harus berhati-hati dengan pihak ketiga?

Skrip dan fitur pihak ketiga sangat penting, dan tujuan kami sebagai developer web seharusnya mengintegrasikan hal-hal tersebut, bukan untuk mengabaikannya. Tetapi ada potensi masalah. Konten pihak ketiga dapat menimbulkan masalah performa dan juga dapat menimbulkan masalah keamanan karena Anda memasukkan layanan eksternal dalam batas kepercayaan Anda. Namun, konten pihak ketiga juga dapat menimbulkan masalah privasi.

Ketika kita berbicara tentang sumber daya pihak ketiga di web, ada baiknya untuk memikirkan masalah keamanan (antara lain) saat pihak ketiga dapat mencuri data dari perusahaan Anda, dan untuk membandingkannya dengan masalah privasi, yang (di antaranya) adalah pihak ketiga yang Anda sertakan mencuri atau memperoleh akses ke data pengguna Anda tanpa Anda (atau mereka).

Contoh masalah keamanan adalah saat "pembuka web skimmer" mencuri informasi kartu kredit-–resource pihak ketiga yang disertakan di halaman tempat pengguna memasukkan detail kartu kredit dapat, berpotensi, mencuri detail kartu kredit tersebut dan mengirimkannya ke pihak ketiga yang berbahaya. Mereka yang membuat skrip skimmer ini sangat kreatif dalam mencari tempat untuk menyembunyikannya. Ringkasan menjelaskan bagaimana skrip skimmer disembunyikan di konten pihak ketiga, misalnya gambar yang digunakan untuk logo situs, favicon, dan jaringan media sosial, library populer seperti jQuery, Modernizr, dan Google Tag Manager, serta widget situs seperti jendela live chat, dan file CSS.

Masalah privasi sedikit berbeda. Pihak ketiga ini adalah bagian dari penawaran Anda; untuk mempertahankan kepercayaan pengguna kepada Anda, Anda harus yakin bahwa pengguna dapat memercayai mereka. Jika pihak ketiga yang Anda gunakan mengumpulkan data tentang pengguna Anda lalu menyalahgunakannya, atau menyulitkan untuk menghapus atau menemukan, atau mengalami pelanggaran data, atau melanggar ekspektasi pengguna, pengguna mungkin akan menganggapnya sebagai penguraian kepercayaan mereka terhadap layanan Anda, bukan hanya kepada pihak ketiga. Ini adalah reputasi dan hubungan Anda yang ditelepon. Inilah alasan penting untuk bertanya kepada diri sendiri: apakah Anda memercayai pihak ketiga yang digunakan di situs Anda?

Apa saja contoh pihak ketiga?

Kami membahas "pihak ketiga" secara umum, tetapi sebenarnya ada berbagai jenis, dan mereka memiliki akses ke jumlah data pengguna yang berbeda. Misalnya, menambahkan elemen <img> ke HTML Anda, yang dimuat dari server yang berbeda, akan memberikan informasi yang berbeda tentang pengguna Anda kepada server tersebut dibandingkan penambahan <iframe> atau elemen <script>. Contoh berikut, bukan daftar lengkap, tetapi akan bermanfaat untuk memahami perbedaan antara berbagai jenis item pihak ketiga yang dapat digunakan oleh situs Anda.

Meminta resource lintas situs

Resource lintas situs adalah semua hal di situs Anda yang dimuat dari situs yang berbeda dan bukan <iframe> atau <script>. Contohnya mencakup <img>, <audio>, <video>, font web yang dimuat oleh CSS, dan tekstur WebGL. Semuanya dimuat melalui permintaan HTTP, dan seperti yang dijelaskan sebelumnya, permintaan HTTP tersebut akan mencakup cookie apa pun yang sebelumnya ditetapkan oleh situs lain, alamat IP pengguna yang meminta, dan URL halaman saat ini sebagai perujuk. Semua permintaan pihak ketiga secara historis menyertakan data ini secara default, meskipun ada upaya untuk mengurangi atau mengisolasi data yang diteruskan ke pihak ketiga oleh berbagai browser, seperti yang dijelaskan dalam "Memahami Perlindungan Browser Pihak Ketiga" lebih lanjut.

Menyematkan iframe lintas situs

Dokumen lengkap yang disematkan di halaman Anda melalui <iframe> dapat meminta akses tambahan ke API browser, selain trifecta cookie, alamat IP, dan perujuk. Tepat API yang tersedia untuk halaman <iframe> dan caranya meminta akses adalah khusus browser, dan saat ini mengalami perubahan: lihat "Kebijakan Izin" di bawah untuk mengetahui upaya saat ini dalam membatasi atau memantau akses API di dokumen yang disematkan.

Mengeksekusi JavaScript lintas situs

Menyertakan elemen <script> akan memuat dan menjalankan JavaScript lintas situs dalam konteks tingkat atas halaman Anda. Artinya, skrip yang berjalan memiliki akses penuh ke semua hal yang dilakukan oleh skrip pihak pertama milik Anda. Izin browser tetap mengelola data ini, sehingga meminta lokasi pengguna (misalnya) tetap memerlukan persetujuan pengguna. Namun, informasi apa pun yang ada di halaman atau yang tersedia sebagai variabel JavaScript dapat dibaca oleh skrip tersebut, dan ini tidak hanya mencakup cookie yang diteruskan ke pihak ketiga sebagai bagian dari permintaan, tetapi juga cookie yang ditujukan untuk situs Anda saja. Demikian pula, skrip pihak ketiga yang dimuat ke halaman Anda dapat membuat semua permintaan HTTP yang sama seperti yang dilakukan kode Anda sendiri, yang berarti skrip tersebut dapat membuat permintaan fetch() ke API back-end Anda untuk mendapatkan data.

Menyertakan library pihak ketiga dalam dependensi Anda

Seperti yang dijelaskan sebelumnya, kode sisi server Anda kemungkinan juga akan menyertakan dependensi pihak ketiga, dan dependensi ini tidak dapat dibedakan dengan kode Anda sendiri dalam kecanggihannya; kode yang Anda sertakan dari repositori GitHub atau library bahasa pemrograman Anda (npm, PyPI, composer, dan sebagainya) dapat membaca semua data yang sama dengan kode Anda yang lain.

Mengenal pihak ketiga

Oleh karena itu, diperlukan pemahaman tentang daftar pemasok pihak ketiga Anda, serta bagaimana sikap dan kebijakan privasi, pengumpulan data, dan pengalaman pengguna mereka. Pemahaman tersebut kemudian menjadi bagian dari rangkaian kompromi Anda: seberapa berguna dan penting layanannya, diimbangi dengan seberapa mengganggu, tidak nyaman, atau menggelisahkan permintaan mereka terhadap pengguna Anda. Konten pihak ketiga memberikan nilai dengan mengambil bagian pekerjaan yang sulit dari Anda sebagai pemilik situs dan memungkinkan Anda berfokus pada kompetensi inti; sehingga ada manfaat dalam melakukan kompromi tersebut serta mengorbankan sebagian kenyamanan dan privasi pengguna untuk pengalaman pengguna yang lebih baik. Namun, jangan keliru membedakan pengalaman pengguna dengan pengalaman developer: "lebih mudah bagi tim developer kami untuk membangun layanan" bukanlah cerita yang menarik bagi pengguna.

Bagaimana Anda mendapatkan pemahaman itu adalah melalui proses audit.

Mengaudit pihak ketiga Anda

Memahami tindakan yang dilakukan pihak ketiga adalah proses audit. Anda dapat melakukannya baik secara teknis maupun non-teknis, dan untuk pihak ketiga individual dan untuk seluruh koleksi Anda.

Menjalankan audit non-teknis

Langkah pertama tidak teknis: baca kebijakan privasi pemasok Anda. Jika Anda menyertakan referensi pihak ketiga, periksa kebijakan privasi. Dokumen ini akan panjang dan penuh dengan teks hukum, dan beberapa dokumen mungkin menggunakan beberapa pendekatan yang secara khusus diperingatkan terhadap di modul sebelumnya, seperti pernyataan yang terlalu umum dan tanpa indikasi bagaimana atau kapan data yang dikumpulkan akan dihapus. Penting untuk diketahui bahwa dari perspektif pengguna, semua data yang dikumpulkan di situs Anda, termasuk oleh pihak ketiga, akan diatur oleh kebijakan privasi ini. Meskipun Anda melakukan semuanya dengan benar, saat Anda bersikap transparan tentang sasaran Anda dan melampaui ekspektasi pengguna terkait privasi dan sensitivitas data, pengguna mungkin meminta Anda bertanggung jawab atas apa pun yang dilakukan oleh pihak ketiga yang Anda pilih. Jika ada sesuatu dalam kebijakan privasi mereka yang tidak ingin Anda katakan dalam kebijakan Anda sendiri karena akan mengurangi kepercayaan pengguna, maka pertimbangkan apakah ada pemasok alternatif.

Hal ini adalah sesuatu yang berguna seiring dengan audit teknis yang dibahas lebih lanjut, karena keduanya saling melengkapi. Anda harus mengetahui resource pihak ketiga yang Anda sertakan untuk alasan bisnis (seperti jaringan iklan atau konten tersemat) karena akan ada hubungan bisnis. Ini adalah tempat yang baik untuk memulai audit non-teknis. Audit teknis juga dapat mengidentifikasi pihak ketiga, terutama yang disertakan untuk alasan teknis, bukan bisnis (komponen eksternal, analisis, library utilitas), dan daftar tersebut dapat bergabung dengan daftar pihak ketiga yang berfokus pada bisnis. Tujuan Anda di sini adalah agar Anda sebagai pemilik situs merasa telah memahami apa yang dilakukan pihak ketiga yang Anda tambahkan ke situs, dan agar Anda sebagai bisnis dapat memberikan inventaris pihak ketiga ini kepada penasihat hukum Anda untuk memastikan Anda memenuhi kewajiban apa pun yang diwajibkan.

Menjalankan audit teknis

Untuk audit teknis, penting untuk menggunakan resource in situ sebagai bagian dari situs. Artinya, jangan memuat dependensi dalam harness pengujian dan memeriksanya dengan cara tersebut. Pastikan Anda melihat bagaimana dependensi berfungsi sebagai bagian dari situs Anda yang sebenarnya, yang di-deploy di internet publik, bukan dalam mode pengujian atau pengembangan. Melihat situs web Anda sendiri sebagai pengguna baru itu sangat instruktif. Buka browser dengan profil baru yang bersih, sehingga Anda tidak masuk dan tidak memiliki perjanjian yang tersimpan, dan cobalah mengunjungi situs Anda.

Daftar di situs Anda sendiri untuk mendapatkan akun baru, jika Anda memberikan akun pengguna. Tim desain Anda akan mengatur proses akuisisi pengguna baru ini dari perspektif UX, tetapi dapat memberikan ilustrasi untuk melakukan pendekatan dari perspektif privasi. Jangan hanya mengklik "Setuju" pada persyaratan dan ketentuan, peringatan cookie, atau kebijakan privasi; tetapkan tugas Anda untuk menggunakan layanan sendiri tanpa mengungkapkan informasi pribadi apa pun atau memiliki cookie pelacakan, dan lihat apakah Anda dapat melakukannya dan seberapa sulit melakukannya. Ada baiknya juga melihat alat developer browser untuk melihat situs mana yang sedang diakses dan data mana yang diteruskan ke situs tersebut. Alat developer menyediakan daftar permintaan HTTP yang terpisah (biasanya di bagian yang disebut "Jaringan"), dan Anda dapat melihat dari sini permintaan yang dikelompokkan berdasarkan jenis (HTML, CSS, gambar, font, JavaScript, permintaan yang dimulai oleh JavaScript). Anda juga dapat menambahkan kolom baru untuk menampilkan domain setiap permintaan, yang akan menunjukkan jumlah tempat berbeda yang dihubungi, dan mungkin ada kotak centang "permintaan pihak ketiga" yang hanya menampilkan pihak ketiga. (Sebaiknya gunakan pelaporan Content-Security-Policy untuk melakukan audit berkelanjutan, yang akan dibaca lebih lanjut.)

Alat "Request Map Generator" Simon Hearne juga dapat menjadi ringkasan bermanfaat dari semua subpermintaan yang dibuat oleh halaman yang tersedia untuk publik.

Pada poin ini, Anda juga dapat menyertakan pihak ketiga yang berfokus pada bisnis yang diidentifikasi sebagai bagian dari audit non-teknis (yaitu: daftar perusahaan yang memiliki hubungan finansial dengan Anda untuk menggunakan sumber daya mereka). Tujuannya di sini adalah untuk mencocokkan daftar pihak ketiga yang Anda yakini Anda gunakan (dari catatan keuangan dan hukum) dan daftar yang sebenarnya Anda gunakan (dengan melihat permintaan HTTP pihak ketiga yang dibuat oleh situs Anda). Anda harus dapat mengidentifikasi setiap pihak ketiga bisnis yang membuat permintaan keluar teknis. Jika Anda tidak dapat mengidentifikasi permintaan dalam audit teknis untuk pihak ketiga yang diidentifikasi berdasarkan hubungan bisnis, penting untuk mencari tahu alasannya dan memiliki panduan tersebut untuk melakukan pengujian: mungkin resource pihak ketiga hanya dimuat di negara tertentu, atau pada jenis perangkat tertentu, atau untuk pengguna yang login. Tindakan ini akan memperbesar daftar area situs yang akan diaudit dan memastikan Anda melihat semua akses keluar. (Atau mungkin sistem akan mengidentifikasi resource pihak ketiga yang Anda bayar dan tidak gunakan, yang selalu menghibur bagian keuangan.)

Setelah Anda mempersempit daftar permintaan kepada pihak ketiga yang ingin dijadikan bagian dari audit, mengklik setiap permintaan akan menampilkan semua detailnya dan, khususnya, data mana yang diteruskan ke permintaan tersebut. Selain itu, sangat umum juga jika permintaan pihak ketiga yang dimulai kode Anda kemudian dilanjutkan dengan permintaan pihak ketiga lainnya. Pihak ketiga tambahan ini juga "diimpor" ke kebijakan privasi Anda. Tugas ini melelahkan, tetapi bermanfaat, dan sering kali dapat dimasukkan ke dalam analisis yang ada; tim pengembangan frontend Anda harus sudah mengaudit permintaan untuk alasan performa (mungkin dengan bantuan alat yang ada seperti WebPageTest atau Lighthouse), dan menggabungkan data dan audit privasi ke dalam proses tersebut dapat mempermudah prosesnya.

Peta permintaan web.dev.
Peta permintaan (disederhanakan secara drastis) untuk web.dev, yang menampilkan situs pihak ketiga yang meminta situs pihak ketiga lainnya, dan sebagainya.

Anjuran

Buka browser dengan profil pengguna baru yang bersih, sehingga Anda tidak login dan tidak memiliki perjanjian yang tersimpan; lalu buka panel Jaringan alat pengembangan browser untuk melihat semua permintaan keluar. Tambahkan kolom baru untuk menampilkan domain setiap permintaan, dan centang kotak "permintaan pihak ketiga" untuk menampilkan hanya pihak ketiga jika ada. Kemudian:

  • Kunjungi situs Anda.
  • Daftar akun baru, jika Anda menyediakan akun pengguna.
  • Coba hapus akun yang Anda buat.
  • Lakukan satu atau dua tindakan normal di situs (hal ini akan bergantung pada tindakan yang dilakukan situs Anda, tetapi pilih tindakan umum yang dilakukan oleh sebagian besar pengguna).
  • Lakukan satu atau dua tindakan yang Anda tahu secara khusus melibatkan dependensi pihak ketiga. Hal ini dapat mencakup berbagi konten ke media sosial, memulai alur checkout, atau menyematkan konten dari situs lain.

Saat melakukan setiap tugas ini, buat data resource yang diminta dari domain yang bukan milik Anda dengan melihat panel Jaringan seperti yang dijelaskan. Ini adalah beberapa pihak ketiga Anda. Cara yang baik untuk melakukannya adalah dengan menggunakan alat jaringan browser untuk menangkap log permintaan jaringan dalam file HAR.

dan pengambilan file HAR

File HAR adalah format JSON standar dari semua permintaan jaringan yang dibuat oleh halaman. Untuk mendapatkan file HAR bagi halaman tertentu, di:

Chrome

Buka DevTools browser (Menu > Alat Lainnya > Developer Tools), buka panel Jaringan, muat (atau muat ulang) halaman, lalu pilih simbol simpan panah ke bawah di kanan atas di dekat menu dropdown Tidak ada throttling.

Panel jaringan Chrome DevTools dengan simbol Download HAR ditandai.
Firefox

Buka alat developer browser (Menu > Alat Lainnya > Alat Developer Web), buka panel Jaringan, muat (atau muat ulang) halaman, lalu pilih simbol roda gigi di kanan atas di samping menu dropdown pembatasan. Dari menunya, pilih Save All As HAR**.

Panel jaringan alat developer Firefox dengan opsi Save All As Har ditandai.
Safari

Buka alat developer browser (Menu > Develop > Show Web Inspector; jika Anda tidak memiliki menu Develop, aktifkan dari Menu > Safari > Preferences > Advanced > Show Develop menu di panel menu), buka panel Network, muat (atau muat ulang) halaman, dan pilih Export di kanan atas (di sebelah kanan Preserve Log; Anda mungkin perlu memperbesar jendela).

Panel Safari Web Inspector Network dengan opsi ekspor HAR ditandai.

Untuk mengetahui detail lebih lanjut, Anda juga dapat mencatat apa saja yang diteruskan ke pihak ketiga (di bagian Permintaan), meskipun data ini sering kali di-obfuscate dan tidak dapat ditafsirkan secara berguna.

Praktik terbaik saat mengintegrasikan pihak ketiga

Anda dapat menetapkan kebijakan sendiri terkait pihak ketiga yang digunakan situs Anda: mengubah penyedia iklan yang Anda gunakan berdasarkan praktik mereka, atau seberapa mengganggu atau mengganggu pop-up izin cookie mereka, atau apakah Anda ingin menggunakan tombol media sosial di situs Anda atau melacak link dalam email atau link utm_campaign untuk dilacak di Google Analytics dalam tweet Anda. Salah satu aspek yang harus dipertimbangkan saat mengembangkan situs adalah postur privasi dan keamanan layanan analisis Anda. Beberapa layanan analisis secara eksplisit berfokus melindungi privasi. Sering kali, ada juga cara untuk menggunakan skrip pihak ketiga yang menambah perlindungan privasi dengan sendirinya: Anda bukan tim pertama yang ingin meningkatkan privasi pengguna dan melindungi mereka dari pengumpulan data pihak ketiga, dan mungkin sudah ada solusinya. Terakhir, banyak penyedia pihak ketiga saat ini lebih sensitif terhadap masalah pengumpulan data daripada sebelumnya, dan sering kali ada fitur atau parameter yang dapat Anda tambahkan untuk memungkinkan mode yang lebih melindungi pengguna. Berikut ini beberapa contohnya.

Saat menambahkan tombol berbagi media sosial

Pertimbangkan untuk langsung menyematkan tombol HTML: situs https://sharingbuttons.io/ memiliki beberapa contoh yang didesain dengan baik. Atau Anda dapat menambahkan tautan HTML biasa. Konsekuensinya, Anda akan kehilangan statistik "jumlah berbagi" dan kemampuan untuk mengklasifikasikan pelanggan di analisis Facebook. Ini adalah contoh kompromi antara menggunakan penyedia pihak ketiga dan menerima lebih sedikit data analisis.

Secara lebih umum, jika Anda menyematkan sejenis widget interaktif dari pihak ketiga, sering kali kita dapat menyediakan link ke pihak ketiga tersebut. Hal ini berarti situs Anda tidak memiliki pengalaman inline, tetapi mengubah keputusan untuk berbagi data dengan pihak ketiga dari Anda kepada pengguna, yang dapat memilih untuk berinteraksi atau tidak sesuai keinginan mereka.

Misalnya, Anda dapat menambahkan link untuk Twitter dan Facebook untuk berbagi layanan di mysite.example.com seperti ini:

<a href="https://facebook.com/sharer/sharer.php?u=https%3A%2F%2Fmysite.example.com"
   rel="noopener" aria-label="Share on Facebook" target="_blank" >Share on Facebook</a>
<a href="https://twitter.com/intent/tweet/?text=My%20cool%20service!&amp;url=https%3A%2F%2Fmysite.example.com"
   rel="noopener" aria-label="Share on Twitter" target="_blank">Share on Twitter</a>

Perhatikan bahwa Facebook memungkinkan penentuan URL untuk dibagikan, dan Twitter memungkinkan penentuan URL dan beberapa teks.

Saat menyematkan video

Saat Anda menyematkan video dari situs yang menghosting video, cari opsi yang menjaga privasi dalam kode penyematan. Misalnya, untuk YouTube, ganti youtube.com di URL sematan dengan www.youtube-nocookie.com agar cookie pelacakan tidak ditempatkan pada pengguna yang melihat halaman penyematan. Anda juga dapat mencentang "Aktifkan mode privasi yang ditingkatkan" saat membuat link Bagikan/Sematkan dari YouTube itu sendiri. Ini adalah contoh yang baik dari penggunaan mode yang lebih melindungi pengguna yang disediakan oleh pihak ketiga. (https://support.google.com/youtube/answer/171780 menjelaskan hal ini secara lebih mendetail, dan opsi penyematan lainnya untuk YouTube secara khusus.)

Opsi situs video lain dalam hal ini lebih sedikit: TikTok, misalnya, tidak memiliki cara untuk menyematkan video tanpa pelacakan pada saat penulisan ini. Anda dapat menghosting video sendiri (ini menggunakan alternatif), tetapi pekerjaannya bisa lebih banyak, terutama untuk mendukung banyak perangkat.

Seperti widget interaktif yang dibahas sebelumnya, video yang disematkan sering kali diganti dengan link ke situs penyedia. Hal ini kurang interaktif karena video tidak akan diputar inline, tetapi memberi pengguna pilihan apakah akan menontonnya atau tidak. Atribut ini dapat digunakan sebagai contoh "pola fasad", yaitu nama untuk mengganti konten interaktif secara dinamis dengan sesuatu yang memerlukan tindakan pengguna untuk memicunya. Video TikTok yang disematkan dapat diganti dengan link biasa ke halaman video TikTok, tetapi dengan sedikit upaya lagi, Anda dapat mengambil dan menampilkan thumbnail untuk video tersebut dan menjadikannya sebagai link. Meskipun penyedia video yang dipilih tidak mendukung cara mudah untuk menyematkan video tanpa pelacakan, banyak host video mendukung oEmbed, API yang, jika diberi link ke video atau konten tersemat, akan menampilkan detail terprogram untuk konten tersebut, termasuk thumbnail dan judul. TikTok mendukung oEmbed (lihat https://developers.tiktok.com/doc/embed-videos untuk mengetahui detailnya), yang berarti bahwa Anda dapat (secara manual atau terprogram) mengubah link ke video TikTok https://www.tiktok.com/@scout2015/video/6718335390845095173 menjadi metadata JSON terkait video tersebut dengan https://www.tiktok.com/oembed?url=https://www.tiktok.com/@scout2015/video/6718335390845095173, sehingga mengambil thumbnail untuk ditampilkan. Misalnya, WordPress menggunakan cara ini untuk meminta informasi oEmbed' untuk konten yang disematkan. Anda dapat menggunakannya secara terprogram untuk menampilkan "fasad" yang terlihat interaktif dan beralih untuk menyematkan atau menautkan ke video interaktif ketika pengguna memilih untuk mengkliknya.

Saat menyematkan skrip Analytics

Analytics dirancang untuk mengumpulkan informasi tentang pengguna Anda sehingga dapat dianalisis: inilah fungsinya. Sistem analisis pada dasarnya adalah layanan untuk mengumpulkan dan menampilkan data tentang akses dan pengguna, yang dilakukan di server pihak ketiga seperti Google Analytics untuk kemudahan penerapan. Ada juga sistem analisis yang dihosting sendiri seperti https://matomo.org/, meskipun jika ini memerlukan lebih banyak pekerjaan daripada menggunakan solusi pihak ketiga. Namun, menjalankan sistem semacam itu di infrastruktur Anda sendiri dapat membantu Anda mengurangi pengumpulan data, karena sistem tersebut tidak meninggalkan ekosistem Anda sendiri. Di sisi lain, mengelola data tersebut, menghapusnya, dan menetapkan kebijakan untuk data tersebut menjadi tanggung jawab Anda. Sebagian besar kekhawatiran terkait pelacakan lintas situs terjadi jika tindakan tersebut dilakukan secara sembunyi-sembunyi dan secara diam-diam, atau sebagai efek samping dari penggunaan layanan yang sama sekali tidak memerlukan pengumpulan data. Software analisis dirancang secara terbuka untuk mengumpulkan data guna menginformasikan pengguna situs kepada pemilik situs.

Secara historis, ada pendekatan mengumpulkan semua data yang bisa Anda lakukan tentang segala hal, seperti jaring ikan raksasa, lalu menganalisisnya nanti untuk menemukan pola-pola yang menarik. Pola pikir ini, sebagian besar, menimbulkan rasa tidak nyaman dan kegelisahan tentang pengumpulan data yang dibahas di bagian 1 dalam kursus ini. Sekarang, banyak situs terlebih dulu menentukan pertanyaan mana yang harus diajukan, kemudian mengumpulkan data yang spesifik dan terbatas untuk menjawab pertanyaan tersebut.

Jika beberapa layanan pihak ketiga digunakan oleh situs Anda dan situs lain, dan layanan ini bekerja dengan Anda menyertakan JavaScript mereka ke dalam situs Anda, dan menetapkan cookie untuk setiap pengguna, penting untuk mempertimbangkan bahwa mereka mungkin melakukan pengenalan lintas situs yang tidak diinginkan, yaitu melacak pengguna di seluruh situs. Sebagian mungkin dan sebagian mungkin tidak, tetapi sikap yang melindungi privasi di sini adalah dengan berasumsi bahwa layanan pihak ketiga tersebut sebenarnya melakukan pelacakan lintas situs, kecuali jika Anda memiliki alasan yang baik untuk berpikir atau mengetahui sebaliknya. Hal ini bukan merupakan alasan untuk menghindari layanan tersebut, tetapi merupakan suatu hal yang perlu dipertimbangkan dalam penilaian Anda tentang konsekuensi penggunaannya.

Kompromi dalam analisis biasanya hanya untuk memilih apakah akan menggunakannya atau tidak: mengumpulkan semua data dan mengorbankan privasi sebagai imbalan atas insight dan perencanaan, atau memberikan insight sepenuhnya. Namun, hal ini tidak lagi terjadi, dan sekarang sering kali ada jalan tengah yang dapat ditemukan di antara kedua hal ekstrem ini. Hubungi penyedia analisis Anda untuk mengetahui opsi konfigurasi guna membatasi data yang dikumpulkan dan mengurangi jumlah serta durasi penyimpanannya. Karena Anda memiliki data dari audit teknis yang dijelaskan sebelumnya, Anda dapat menjalankan ulang bagian yang relevan dari audit tersebut untuk mengonfirmasi bahwa mengubah konfigurasi ini benar-benar mengurangi jumlah data yang dikumpulkan. Jika Anda melakukan transisi ini pada situs yang sudah ada, hal ini dapat memberi Anda beberapa ukuran terukur yang dapat dituliskan untuk pengguna Anda. Misalnya, Google Analytics memiliki sejumlah fitur privasi keikutsertaan (sehingga dinonaktifkan secara default), yang banyak di antaranya mungkin berguna untuk mematuhi hukum perlindungan data setempat. Beberapa opsi yang perlu dipertimbangkan saat menyiapkan Google Analytics termasuk menetapkan periode retensi data pada data yang dikumpulkan (Admin > Info Pelacakan > Retensi Data) yang lebih rendah daripada default 26 bulan, dan mengaktifkan beberapa solusi yang lebih teknis seperti anonimisasi IP parsial (lihat https://support.google.com/analytics/answer/9019185 untuk detail selengkapnya).

Menggunakan pihak ketiga untuk menjaga privasi

Sejauh ini, kita telah membahas cara melindungi pengguna dari pihak ketiga selama fase desain aplikasi, selagi Anda merencanakan apa yang akan dilakukan aplikasi tersebut. Memutuskan untuk tidak menggunakan pihak ketiga tertentu sama sekali merupakan bagian dari perencanaan ini, dan mengaudit penggunaan oleh Anda juga termasuk dalam kategori ini: pengambilan keputusan tentang sikap privasi Anda. Namun, keputusan ini pada dasarnya tidak terlalu terperinci; memilih untuk menggunakan pihak ketiga tertentu atau memilih untuk tidak melakukannya bukanlah keputusan yang perlu diperhatikan. Kemungkinan besar Anda menginginkan sesuatu di antaranya: memerlukan atau berencana menggunakan penawaran pihak ketiga tertentu, tetapi mengurangi kecenderungan yang melanggar privasi (baik disengaja maupun tidak disengaja). Tugas ini adalah melindungi pengguna pada "waktu build": menambahkan pengamanan untuk mengurangi bahaya yang tidak Anda antisipasi. Semua ini adalah header HTTP baru yang dapat Anda berikan saat menyajikan halaman dan yang akan mengisyaratkan atau memerintahkan agen pengguna untuk mengambil sikap privasi atau keamanan tertentu.

Kebijakan Perujuk

Anjuran

Tetapkan kebijakan strict-origin-when-cross-origin atau noreferrer agar situs lain tidak menerima header Perujuk saat Anda menautkannya atau saat situs dimuat sebagai subresource oleh halaman:

index.html:
<meta name="referrer" content="strict-origin-when-cross-origin" />

Atau sisi server, misalnya di Express:

const helmet = require('helmet');
app.use(helmet.referrerPolicy({policy: 'strict-origin-when-cross-origin'}));

Jika perlu, tetapkan kebijakan longgar pada elemen atau permintaan tertentu.

Alasan tindakan ini melindungi privasi pengguna

Secara default, setiap permintaan HTTP yang dibuat oleh browser akan diteruskan pada header Referer yang berisi URL halaman yang memulai permintaan, baik link, gambar tersemat, atau skrip. Hal ini dapat menjadi masalah privasi karena URL dapat berisi informasi pribadi, dan URL tersebut tersedia untuk pihak ketiga akan meneruskan informasi pribadi tersebut kepada mereka. Web.dev mencantumkan beberapa contoh URL yang berisi data pribadi—mengetahui bahwa pengguna datang ke situs Anda dari https://social.example.com/user/me@example.com akan memberi tahu Anda siapa pengguna tersebut, dan ini adalah kebocoran yang pasti. Namun, bahkan URL yang tidak mengekspos informasi pribadi sendiri pun akan mengungkap bahwa pengguna tertentu ini (yang mungkin Anda kenal, jika mereka login) berasal dari situs lain, sehingga hal ini mengungkapkan bahwa pengguna ini mengunjungi situs lain tersebut. Hal ini sendiri adalah pemaparan informasi yang mungkin tidak seharusnya Anda ketahui tentang histori penjelajahan pengguna.

Dengan menyediakan header Referrer-Policy (dengan ejaan yang benar), Anda dapat mengubah ini, sehingga beberapa atau tidak ada URL perujuk yang diteruskan. MDN mencantumkan detail lengkap, tetapi sebagian besar browser kini telah mengadopsi nilai strict-origin-when-cross-origin yang diasumsikan secara default, yang berarti URL perujuk kini diteruskan ke pihak ketiga sebagai origin saja (https://web.dev, bukan https://web.dev/learn/privacy). Ini adalah perlindungan privasi yang berguna tanpa Anda harus melakukan apa pun. Namun, Anda dapat memperketatnya lebih lanjut dengan menetapkan Referrer-Policy: same-origin agar informasi perujuk tidak diteruskan sama sekali ke pihak ketiga (atau Referrer-Policy: no-referrer agar tidak diteruskan ke siapa pun, termasuk asal Anda sendiri). (Ini adalah contoh yang bagus dari keseimbangan privasi vs utilitas; default baru ini jauh lebih menjaga privasi daripada sebelumnya, tetapi masih memberikan informasi tingkat tinggi kepada pihak ketiga pilihan Anda, seperti penyedia analisis Anda.)

Sebaiknya tentukan header ini secara eksplisit karena Anda mengetahui persis apa kebijakannya, bukan mengandalkan default browser. Jika tidak dapat menetapkan header, Anda dapat menyetel kebijakan perujuk untuk keseluruhan halaman HTML menggunakan elemen meta di <head>: <meta name="referrer" content="same-origin">; dan jika khawatir dengan pihak ketiga tertentu, Anda juga dapat menetapkan atribut referrerpolicy pada masing-masing elemen seperti <script>, <a>, atau <iframe>: <script src="https://thirdparty.example.com/data.js" referrerpolicy="no-referrer">

Kebijakan-Keamanan-Konten

Header Content-Security-Policy, yang sering disebut sebagai "CSP", menentukan dari mana resource eksternal dapat dimuat. Alat ini terutama digunakan untuk tujuan keamanan, dengan mencegah serangan pembuatan skrip lintas situs dan injeksi skrip. Namun, saat digunakan bersama audit reguler Anda, pengujian ini juga dapat membatasi tempat tujuan penerusan data oleh pihak ketiga yang Anda pilih.

Hal ini berpotensi memberikan pengalaman pengguna yang kurang baik; jika salah satu skrip pihak ketiga mulai memuat dependensi dari origin yang tidak ada dalam daftar, permintaan tersebut akan diblokir, skrip akan gagal, dan aplikasi Anda mungkin gagal dengan dependensi tersebut (atau setidaknya direduksi menjadi versi penggantiannya yang gagal JavaScript-nya). Hal ini berguna saat CSP diimplementasikan untuk keamanan, yang merupakan tujuan normalnya: melindungi dari masalah pembuatan skrip lintas situs (dan untuk melakukannya, gunakan CSP ketat). Setelah mengetahui semua skrip inline yang digunakan halaman, Anda dapat membuat daftarnya, menghitung nilai hash, atau menambahkan nilai acak (disebut "nonce") untuk setiap skrip, lalu menambahkan daftar hash ke Kebijakan Keamanan Konten. Hal ini akan mencegah skrip apa pun yang tidak ada dalam daftar dimuat. Hal ini perlu disertakan ke dalam proses produksi untuk situs: skrip di halaman Anda harus menyertakan nonce atau agar hash dihitung sebagai bagian dari build. Lihat artikel tentang strict-csp untuk semua detailnya.

Untungnya, browser mendukung header terkait, Content-Security-Policy-Report-Only. Jika header ini diberikan, permintaan yang melanggar kebijakan yang disediakan tidak akan diblokir, tetapi laporan JSON akan dikirim ke URL yang disediakan. Header tersebut mungkin terlihat seperti ini: Content-Security-Policy-Report-Only: script-src 3p.example.com; report-uri https://example.com/report/, dan jika browser memuat skrip dari mana pun selain 3p.example.com, permintaan tersebut akan berhasil, tetapi laporan akan dikirim ke report-uri yang disediakan. Biasanya kunci ini digunakan untuk bereksperimen dengan kebijakan sebelum menerapkannya, tetapi ide yang berguna di sini adalah menggunakannya sebagai cara untuk melakukan "audit berkelanjutan". Selain audit reguler yang dijelaskan sebelumnya, Anda dapat mengaktifkan pelaporan CSP untuk mengetahui apakah ada domain yang tidak terduga yang muncul, yang dapat berarti bahwa resource pihak ketiga Anda memuat resource pihak ketiga mereka sendiri dan yang perlu Anda pertimbangkan dan evaluasi. (Hal ini mungkin juga merupakan tanda bahwa beberapa eksploitasi pembuatan skrip lintas situs telah melewati batas keamanan Anda, tentu saja, yang juga penting untuk diketahui.)

Content-Security-Policy adalah API yang kompleks dan tidak akurat untuk digunakan. Hal ini diketahui, dan ada pekerjaan yang terus dilakukan untuk membangun "generasi berikutnya" dari CSP yang akan memenuhi sasaran yang sama tetapi tidak terlalu rumit untuk digunakan.Ini belum siap, tetapi jika Anda ingin melihat ke mana arahnya (atau untuk terlibat dan membantu dalam desainnya) maka lihat https://github.com/WICG/csp-next untuk mengetahui detailnya.

Anjuran

Tambahkan header HTTP ini ke halaman yang dilayani: Content-Security-Policy-Report-Only: default-src 'self'; report-uri https://a-url-you-control. Simpan JSON setelah diposting ke URL tersebut. Tinjau data yang disimpan tersebut untuk mendapatkan kumpulan domain pihak ketiga yang diminta situs Anda saat dikunjungi oleh orang lain. Perbarui header Content-Security-Policy-Report-Only untuk mencantumkan domain yang Anda harapkan agar dapat melihat kapan daftar tersebut berubah:

Content-Security-Policy-Report-Only: default-src 'self' https://expected1.example.com https://expected2.example.com ; report-uri https://a-url-you-control

Mengapa

Audit ini merupakan bagian dari audit teknis Anda, secara berkelanjutan. Audit teknis awal yang Anda lakukan akan memberi Anda daftar pihak ketiga yang diajak berbagi atau meneruskan data pengguna oleh situs Anda. Header ini kemudian akan menyebabkan permintaan halaman melaporkan kembali pihak ketiga mana yang saat ini sedang dihubungi, dan Anda dapat melacak perubahan dari waktu ke waktu. Hal ini tidak hanya memberi tahu Anda tentang perubahan yang dibuat oleh pihak ketiga yang ada, tetapi juga akan menandai pihak ketiga yang baru ditambahkan yang tidak ditambahkan ke audit teknis. Penting untuk memperbarui header agar berhenti melaporkan domain yang Anda harapkan, tetapi audit teknis manual juga harus diulang dari waktu ke waktu (karena pendekatan Content-Security-Policy tidak menandai data apa yang diteruskan, hanya saja bahwa permintaan telah dibuat.)

Perhatikan bahwa URL ini tidak perlu ditambahkan ke halaman yang ditayangkan setiap saat atau ke setiap halaman. Kurangi jumlah respons halaman yang menerima header sehingga Anda menerima sampel laporan yang representatif, dengan jumlah yang tidak berlebihan.

Kebijakan izin

Header Permissions-Policy (yang diperkenalkan dengan nama Feature-Policy) memiliki konsep yang mirip dengan Content-Security-Policy, tetapi membatasi akses ke fitur browser yang canggih. Misalnya, Anda dapat membatasi penggunaan hardware perangkat seperti akselerometer, kamera, atau perangkat USB, atau membatasi fitur non-hardware seperti izin beralih ke layar penuh atau menggunakan XMLHTTPRequest sinkron. Pembatasan ini dapat diterapkan ke halaman tingkat atas (untuk menghindari skrip yang dimuat mencoba menggunakan fitur ini) atau ke halaman subframe yang dimuat melalui iframe. Pembatasan penggunaan API ini bukan semata-mata tentang sidik jari browser; ini tentang melarang pihak ketiga melakukan hal-hal yang mengganggu (seperti menggunakan API yang canggih, memunculkan jendela izin, dll.). Hal ini didefinisikan oleh Model Ancaman Privasi Target sebagai "intrusion".

Header Permissions-Policy ditentukan sebagai daftar pasangan (fitur, origin yang diizinkan), sehingga:

Permissions-Policy: geolocation=(self "https://example.com"), camera=(), fullscreen=*

Contoh ini memungkinkan halaman ini ("self") dan <iframe> dari example.com asal menggunakan API navigator.geolocation dari JavaScript; halaman ini dan semua subframe dapat menggunakan API layar penuh, serta melarang semua halaman, termasuk halaman ini, menggunakan kamera untuk membaca informasi video. Ada banyak detail dan daftar contoh potensial di sini.

Daftar fitur yang ditangani oleh header Kebijakan Izin berukuran besar dan mungkin berubah-ubah. Saat ini, daftar ini dipertahankan di https://github.com/w3c/webappsec-permissions-policy/blob/main/features.md.

Anjuran

Browser yang mendukung Permissions-Policy secara default tidak mengizinkan fitur canggih dalam subframe, dan Anda harus bertindak untuk mengaktifkannya. Pendekatan ini bersifat pribadi secara default. Jika Anda menemukan bahwa subframe di situs Anda memerlukan izin ini, Anda dapat menambahkannya secara selektif. Namun, tidak ada kebijakan izin yang diterapkan pada halaman utama secara default, sehingga skrip (termasuk skrip pihak ketiga) yang dimuat oleh halaman utama tidak dibatasi dalam mencoba menggunakan fitur ini. Oleh karena itu, sebaiknya terapkan Permissions-Policy terbatas ke semua halaman secara default, lalu tambahkan kembali fitur yang diperlukan halaman Anda secara bertahap.

Contoh fitur canggih yang dipengaruhi Permissions-Policy antara lain meminta lokasi pengguna, akses ke sensor (termasuk akselerometer, giroskop, dan magnetometer), izin untuk membuka layar penuh, serta meminta akses ke kamera dan mikrofon pengguna. Daftar lengkap fitur (yang berubah) ditautkan di atas.

Sayangnya, memblokir semua fitur secara default lalu mengizinkannya kembali secara selektif memerlukan listingan semua fitur di header, yang mungkin terasa agak kaku. Meskipun demikian, header Permissions-Policy tersebut merupakan tempat yang tepat untuk memulai. permissionspolicy.com/ memiliki generator yang dapat diklik dengan mudah untuk membuat header tersebut: menggunakannya untuk membuat header yang menonaktifkan semua fitur sehingga:

Permissions-Policy: accelerometer=(), ambient-light-sensor=(), autoplay=(), battery=(), camera=(), cross-origin-isolated=(),
display-capture=(), document-domain=(), encrypted-media=(), execution-while-not-rendered=(), execution-while-out-of-viewport=(),
fullscreen=(), geolocation=(), gyroscope=(), keyboard-map=(), magnetometer=(), microphone=(), midi=(), navigation-override=(),
payment=(), picture-in-picture=(), publickey-credentials-get=(), screen-wake-lock=(), sync-xhr=(), usb=(), web-share=(), xr-spatial-tracking=()

Memahami fitur privasi bawaan di browser web

Selain perlindungan "waktu build" dan "waktu desain", ada juga perlindungan privasi yang terjadi saat "waktu proses": yaitu, fitur privasi yang diimplementasikan di browser itu sendiri untuk melindungi pengguna. Ini bukanlah fitur yang dapat langsung Anda kontrol atau manfaatkan sebagai developer situs. Ini adalah fitur produk, melainkan fitur yang harus Anda ketahui, karena situs Anda mungkin terpengaruh oleh keputusan produk ini di browser. Sebagai contoh di sini tentang bagaimana perlindungan browser ini dapat memengaruhi situs Anda, jika Anda memiliki JavaScript sisi klien yang menunggu dependensi pihak ketiga dimuat sebelum melanjutkan penyiapan halaman, dan dependensi pihak ketiga tersebut tidak pernah dimuat sama sekali, penyiapan halaman Anda mungkin tidak akan selesai, sehingga pengguna melihat halaman yang dimuat setengahnya.

Perlindungan tersebut mencakup Intelligent Tracking Prevention di Safari (dan mesin WebKit yang mendasarinya), serta Enhanced Tracking Protection di Firefox (dan mesinnya, Gecko). Semua ini menyulitkan pihak ketiga untuk membuat profil pengguna Anda yang mendetail.

Pendekatan browser pada fitur privasi sering berubah, dan penting untuk tetap mengikuti perkembangan terbaru; daftar perlindungan berikut benar pada saat penulisan. Browser juga dapat menerapkan perlindungan lain; daftar ini tidak bersifat menyeluruh. Lihat modul tentang praktik terbaik untuk mengetahui cara mengikuti perubahan di sini, dan pastikan untuk melakukan pengujian dengan versi browser mendatang untuk mengetahui perubahan yang dapat memengaruhi project Anda. Perlu diingat bahwa mode samaran/penjelajahan pribadi terkadang menerapkan setelan yang berbeda dari setelan default browser (misalnya, cookie pihak ketiga dapat diblokir secara default dalam mode tersebut). Oleh karena itu, pengujian dalam mode samaran mungkin tidak selalu mencerminkan pengalaman penjelajahan umum sebagian besar pengguna jika mereka tidak menggunakan penjelajahan rahasia. Perlu diingat juga bahwa memblokir cookie dalam berbagai situasi dapat berarti bahwa solusi penyimpanan lainnya, seperti window.localStorage, juga diblokir, bukan hanya cookie.

Chrome

  • Cookie pihak ketiga dimaksudkan untuk diblokir di masa mendatang. Hingga saat ini, tag tersebut tidak diblokir secara default (tetapi dapat diaktifkan oleh pengguna): https://support.google.com/chrome/answer/95647 menjelaskan detailnya.
  • Fitur privasi Chrome, dan khususnya fitur di Chrome yang berkomunikasi dengan layanan Google dan pihak ketiga, dijelaskan di privacysandbox.com/.

Edge

  • Cookie pihak ketiga tidak diblokir secara default (tetapi tindakan ini dapat diaktifkan oleh pengguna).
  • Fitur Tracking Prevention Edge memblokir pelacak dari situs yang tidak dikunjungi dan pelacak berbahaya yang diketahui diblokir secara default.

Firefox

Untuk mendapatkan informasi tentang hal-hal yang mungkin diblokir dan membantu men-debug masalah, klik ikon perisai di kolom URL atau buka about:protections di Firefox (di desktop).

Safari

  • Cookie pihak ketiga diblokir secara default.
  • Sebagai bagian dari fitur Intelligent Tracking Prevention, Safari mengurangi perujuk yang diteruskan ke halaman lain menjadi situs tingkat teratas, bukan halaman tertentu: (https://something.example.com, bukan https://something.example.com/this/specific/page).
  • Data localStorage browser dihapus setelah tujuh hari.

(https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/ merangkum fitur-fitur ini.)

Untuk mendapatkan insight tentang hal yang mungkin diblokir dan membantu men-debug masalah, aktifkan "Intelligent Tracking Prevention Debug Mode" di menu developer Safari (di desktop). (Lihat https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/ untuk detail selengkapnya.)

Proposal API

Mengapa kami memerlukan API baru?

Meskipun fitur dan kebijakan baru yang menjaga privasi di produk browser membantu menjaga privasi pengguna, fitur dan kebijakan tersebut juga memiliki beberapa tantangan. Banyak teknologi web yang dapat digunakan untuk pelacakan lintas situs meskipun dirancang dan digunakan untuk tujuan lain. Misalnya, banyak sistem penggabungan identitas yang kami gunakan setiap hari mengandalkan cookie pihak ketiga. Banyak solusi periklanan yang saat ini diandalkan penayang untuk memperoleh pendapatan saat ini dibuat berdasarkan cookie pihak ketiga. Banyak solusi deteksi penipuan yang mengandalkan sidik jari. Apa yang terjadi pada kasus penggunaan ini jika cookie dan pelacakan sidik jari pihak ketiga dihentikan?

Browser akan sulit dan rentan error untuk membedakan kasus penggunaan, dan untuk secara andal membedakan penggunaan yang melanggar privasi dari pihak lain. Inilah alasan sebagian besar browser besar telah memblokir cookie dan pelacakan sidik jari pihak ketiga atau bermaksud melakukannya untuk melindungi privasi pengguna.

Pendekatan baru diperlukan: saat cookie pihak ketiga dihentikan dan pelacakan sidik jari diminimalkan, developer memerlukan API yang dibuat khusus yang memenuhi kasus penggunaan (yang belum dihentikan) tetapi didesain dengan cara yang menjaga privasi. Tujuannya adalah untuk mendesain dan membuat API yang tidak dapat digunakan untuk pelacakan lintas situs. Tidak seperti fitur browser yang dijelaskan di bagian sebelumnya, teknologi ini bercita-cita menjadi API lintas browser.

Contoh proposal API

Daftar berikut tidaklah lengkap—ini merupakan sebagian dari beberapa hal yang sedang didiskusikan.

Contoh proposal API untuk menggantikan teknologi yang dibuat menggunakan cookie pihak ketiga:

Contoh proposal API untuk menggantikan teknologi yang dibuat di pelacakan pasif:

Contoh proposal lain yang dapat dikembangkan oleh API lain di masa mendatang tanpa cookie pihak ketiga:

Selain itu, jenis proposal API lainnya muncul untuk mencoba dan memiliki mitigasi pelacakan tersembunyi khusus browser sejauh ini. Salah satu contohnya adalah Anggaran Privasi. Di berbagai kasus penggunaan ini, API yang awalnya diusulkan oleh Chrome berada di bawah istilah umum Privacy Sandbox.

Global-Privacy-Control adalah header yang ditujukan untuk berkomunikasi ke situs bahwa pengguna tidak ingin data pribadi yang dikumpulkannya dibagikan ke situs lain. Tujuannya mirip dengan Jangan Lacak, yang telah dihentikan.

Status proposal API

Sebagian besar proposal API ini belum di-deploy, atau hanya di-deploy di belakang flag atau di lingkungan terbatas untuk eksperimen.

Fase inkubasi publik ini penting: vendor dan developer browser mengumpulkan diskusi dan pengalaman terkait apakah API ini berguna dan apakah API ini benar-benar tujuan desainnya. Developer, vendor browser, dan pelaku ekosistem lainnya menggunakan fase ini untuk melakukan iterasi desain API.

Tempat terbaik untuk terus mengikuti perkembangan terkait API baru yang diusulkan saat ini adalah daftar proposal Grup Privasi di GitHub.

Apakah Anda perlu menggunakan API ini?

Jika produk Anda secara langsung dibuat menggunakan cookie atau teknik pihak ketiga seperti pelacakan sidik jari, Anda harus terlibat dengan API baru ini, bereksperimen dengannya, dan berkontribusikan pengalaman Anda sendiri dalam diskusi dan desain API. Dalam semua kasus lain, Anda tidak perlu mengetahui semua detail tentang API baru ini pada saat panduan ini ditulis, tetapi ada baiknya Anda mengetahui apa yang akan hadir.