Ngobrolin Cookies
Ringkasan Episode
Bantu KoreksiCookie dibahas dari akarnya: HTTP itu stateless, server tidak peduli siapa yang meminta — datang permintaan, dikirim jawaban, selesai. Masalah muncul ketika Netscape membangun toko online di awal 90-an dan semua data pelanggan ditumpuk di server sehingga makin lambat seiring bertambahnya pengunjung. Solusinya membalik arah: penanda identitas disimpan di komputer pengguna, dan lahirlah magic cookie — istilah yang sebelumnya sudah lumrah di kalangan programmer. Analoginya seperti karcis parkir; kita tunjukkan potongan kertas itu saat mau keluar. Yang membedakan cookie dari penyimpanan lain di browser bukan kapasitasnya — hanya sekitar empat kilobyte — tapi sifatnya yang selalu ikut menempel di setiap request dan response, termasuk request ke domain lain. Dari situlah masalah privasi tumbuh: satu titik data soal sepatu lari tidak berarti apa-apa, tapi ketika menumpuk dengan pembelian aksesori bayi dan aksesori mobil, terbentuklah persona lengkap dengan perkiraan lokasi, status keluarga, dan rentang penghasilan. Ivan berbagi pengalaman mengimplementasikan kepatuhan GDPR dan menegaskan bahwa memasang banner saja tidak cukup: semua vendor pihak ketiga harus benar-benar diblokir sampai izin diberikan, dan pekerjaan itu memakan waktu lebih dari sebulan termasuk berkonsultasi dengan pengacara. Sisanya membahas flag HttpOnly, Secure, dan SameSite sebagai pertahanan terhadap CSRF, perbedaan first-party dan third-party cookie, serta penegasan bahwa cookie sendiri bukan teknologi jahat — menyimpan sesi login lewat cookie justru penggunaan yang sepenuhnya sah.
Poin-poin Utama
- •Cookie lahir karena HTTP stateless: toko online awal menyimpan semua data pelanggan di server dan jadi lambat, lalu dibalik dengan menaruh penanda identitas di komputer pengguna
- •Yang membedakan cookie dari penyimpanan browser lain bukan kapasitasnya yang cuma sekitar empat kilobyte, tapi sifatnya yang selalu ikut menempel di setiap request dan response
- •Bahaya pelacakan bukan pada satu titik data melainkan akumulasinya — sepatu lari, aksesori bayi, dan aksesori mobil bersama-sama membentuk persona lengkap dengan lokasi dan status keluarga
- •GDPR bukan cuma soal banner: consent harus diberikan secara sadar, data harus bisa diminta pemiliknya, dan penghapusan harus tuntas tanpa soft delete atau backup
- •Implementasi yang benar berarti memblokir semua skrip pihak ketiga sampai izin diberikan, dan mengerjakannya untuk satu situs bisa makan waktu lebih dari sebulan termasuk konsultasi dengan pengacara
- •Flag SameSite mencegah CSRF dengan membuat cookie tidak ikut terkirim saat request datang dari origin lain, sementara HttpOnly menutup akses dari JavaScript di browser
- •Cookie sendiri bukan teknologi jahat — menyimpan sesi login lewat cookie itu sah, dan menghindarinya dengan menaruh data di tempat yang aneh-aneh justru bukan solusi
kita di ngobrolin web, karena malam ini adalah hari Selasa Malam Rambu.
- Selasa Malam Rambu. - Kok nggak kompak ya kayaknya, opening-nya ganti-ganti terus ya.
Kayaknya kita harus latihan dulu deh, kita harus latihan dulu, kita harus bikin script-nya latihan dulu.
Gimana kabarnya teman-teman malam hari ini semoga semuanya sehat-sehat ya,
yang nonton juga, mungkin boleh say hi kita di komentar, biar bisa kita liat-liat nih siapa aja yang sudah hadir malam hari ini.
Seperti biasa kalau mau tanya-tanya di komentar juga boleh, baik yang ada mau tanya maupun yang nggak ada.
Yang nggak ada hubungannya juga boleh ditanya ya, yang nggak boleh ditanya itu tanya nomor top 10.
- Biasanya ada yang bahas jQuery lagi. - Oh iya, biasanya betul.
- Setiap episode harus ada jQuery. - Betul.
Ya, jadi kita malam hari ini seperti biasa kita akan ngobrolin seputar dunia web,
teknologi web yang cakupannya sangat besar, dan malam hari ini kita akan membahas tentang kue atau cookies.
- Oh iya, kue. - Cookies itu kue bukan sih, atau kue coklat gitu kan?
- Biscuit. - Biscuit, oh biscuit, oke.
Nah biskuit favorit Ivan apa? Tanpa menyebutkan merek.
- Susah ya. - Susah ya.
- Susah. - Tunggu dapetin tulisan dulu.
- Coklat chip lah, coklat chip. - Toko chip ya, oh iya.
- Yang mereknya itu ya. - Pasti ada merek top of mind kan.
Waktu yang baik ya, waktu yang baik.
Ya biskuit ya, wafers termasuk biskuit ga wafers?
- Beda, wafers beda. - Engga ya, beda lagi ya.
- Kerupuk apa lagi, bukan? - Oh iya bukan, halo Ira.
Selamat datang. Ya, jadi kita malam ini ga akan ngomongin makanan,
- Tapi kita ngomongin tentang sesuatu. - Sayangnya, cookies.
- Ya namanya. - Teknologi web yang namanya cookies.
Yang biasa digunakan di browser, dan dalam beberapa tahun belakangan ini
sangat sering muncul, terutama kalau kita baru buka web yang baru kita akses gitu kan.
- Terus tiba-tiba ada... - Pasti ada banner.
Apa sih ini cookies, maksudnya gitu kan, malam hari ini kita akan...
- Aset-aset aja ya. - Iya, terima-terima aja ya.
Lihat transkrip lengkap (812 segmen lagi)
- Ga dibaca dulu atau ini apa. - Cookie apa, terus apa yang terjadi pas accept
juga kelihatannya sebagian besar pengguna web ya, ga begitu tahu.
Terus kayaknya juga sekalian kayaknya kalau webdev diminta,
diminta selalu buatin cookies ya pokoknya pasang-pasang aja.
Pasang-pasang aja tuh bannernya, tinggal install leveler-nya,
1 install plug-nya yang penting jadi gitu.
- Ya kita akan mulai dari apa itu cookies, digunakan di bagian mananya,
dan kenapa kok beberapa tahun belakangan ini tiba-tiba cookies itu seperti sebuah...
- Seperti di mana-mana? - Seperti keharusan.
Kalau dulu kok ga ada gitu kan, ya kita pakai cookies biasanya untuk session gitu kan.
Biasanya untuk session, untuk autotifikasi dan lain-lain.
Tapi ga ada tuh yang accept cookies, reject cookies gitu.
Terus tiba-tiba beberapa tahun belakangan ini tiba-tiba kayaknya beberapa website
terutama Eropa gitu ya, itu harus ada accept cookies sebelum kita baca gitu,
harus ada kayak semacam pop-up atau ada banner di bawahnya itu yang harus kita
klik dulu baru bisa kita nikmati website. - Nah, sisa kalaman.
- Jadi cookies itu apa? Ini Ivan ya, Ivan? Mari kita baca sama-sama.
- Kita baca sama-sama. - Sebenarnya awalnya...
- Ada sejarahnya ternyata. - Iya. Cookies itu secara singkat aja ya.
Itu cara temporary storage yang ada di browser untuk menyimpan data.
Itu aja sih sebenarnya simpelnya, tapi kita lihat sejarahnya dulu ya.
Kalau kita tahu ya HTTP request atau hypertext transfer protocol itu sebenarnya
ya kalau tahu web, cara requestnya kan via HTTP ya, HTTP itu protokolnya dan itu sebenarnya stateless.
Stateless itu waktu terjadi request dari this one itu sebenarnya servernya bodoh amat,
ga tau siapa yang request, yang penting ada request itu, halaman itu,
gue respond ini gitu. Intinya kan seperti itu stateless.
Gak peduli itu siapa, dimana gitu ya. Ada service, gue minta minum gitu,
kasih minum, udah gitu aja. Gak peduli siapa. - Ya ga tau sebelumnya udah kasih minum atau belum.
- Kalau istilah di programmingnya pure function gitu ya, apapun yang negasi hasil akhirnya tetap sama gitu ya.
- Input, output selalu sama. - Jadi memang dulu awalnya,
kalau back to tahun 90-an, jamannya web itu awal-awal itu kan sebenarnya simpel informasi aja ya.
Kayak semua, kayak library online aja pokoknya semua text gitu.
- Dokumen lah ya. - Dokumen, orientasinya pada sharing dokumen.
Betul. Terus si Mas Lomontuli ini itu dari Netscape ya, di 90-an awal, ada problem.
Waktu itu mereka lagi bikin online store untuk company namanya MCI.
- Tahun 90-an udah ada online store berarti? - Udah awalnya gitu.
Awalnya semua data itu disimpan di server. Saya ga tau ya gimana caranya,
karena kepikiran sekarang itu sisinya yang penting kalau mau bikin login pasti pakai cookies atau session gitu ya.
Sekarang kita ga tau, kalau zaman dulu itu mungkin mereka cari simpannya setiap customer punya URL unik dan datanya disimpan di server.
Nah itu kan berarti kalau satu hari aksesnya 1000, berarti 1000 customer beda-beda dong disimpan semua di server, jadinya lambat gitu.
Akhirnya perubahan nasi tektur, si company minta, "Gua ga mau disimpan di server, gua mau semua data ini simpannya sebenarnya di komputer user aja."
Dibalik gitu ya. Jadi identifier-nya disimpan di komputernya si customer, disitulah lahir namanya Magic Cookie.
- Magic Cookie, lucu ya dulu namanya ada magic-nya. - Iya.
Ini dia sebutkan bahwa konsep ini sudah di halangan programmer, udah lumrah udah umum.
Iya, Magic Cookie tetap. Kayak identifier, kalau misalnya kita mau request, mungkin kan jaman itu protocolnya ga cuma HTTP ya.
Masih ada protocolnya ini, FTP, masih ada FTP, SFTP segala macam. Mungkin jaman itu ada protocol lain, dia identifier.
- Atau sistem komunikasi yang saling berkomunikasi kali ya? Kayak internet atau jaringan apa pun. - Iya, betul.
Kalau misalnya mau identifikasi, kirim sesuatu kayak flag, kayak data tambahan, siapa gua gitu ya.
Nah, itulah namanya Magic Cookie di kalangan jaman itu. Dengan sistem yang sama, dia terapkan di HTTP atau di web.
Nahir lah Cookie. Itu aja sih sejarah singkatnya ya.
- Nah kalau mau baca lagi lanjut, bagaimana cara ketujuan Cookie. - Baca sendiri ya.
Iya, namun sebagai intinya, anggap aja kalau di dunia sekarang itu gampangnya gini lah ya.
Kalau kita mau masuk parkir, kita masuk ambil tiket, supaya kita bisa keluar kita tunjukin tiket identifier kita itu ya.
Itulah Cookie, yang sepotong kertas itulah Cookie.
Jadi kalau di ilustrasi ini, user log in, berhasil log in, sesenya di-store ke database, kemudian hasilnya dikirim Cookie.
Dikirim hasil sesen ID-nya. Sesen ID-nya disimpan di lokal, di klien dalam bentuk Cookie.
Dan ketika setiap kali kita mengakses web yang harus membutuhkan log in, Cookie-nya dibawa.
- Kita request berserta kuehnya ini ya, kueh kuehnya ini. - Tiket merger tadi.
Jadi kita nggak perlu buka konsol, jadi semuanya itu ada di dev console bisa kelihatan.
- Di bahagia application cookies. - Aplikasi cookies.
Jadi dia sebenarnya sederhana seperti key value store ya, kayak redis, kalau yang di web juga ada database itu, index DB ya kan?
- Index DB. - Ya, caching yang kemarin kita bahas juga key value store juga.
Jadi ada beberapa macam persistent storage ya, seperti Mas Dita sudah bilang, itu dari yang paling, cookies itu cuma bisa memuat 40, coba scroll sedikit ke bawah, kalau nggak salah 40 kilobyte deh.
- 40 kilobyte. - 4 kilobyte, 4 kilobyte aja itu maksimal.
Jadi cookies itu storage yang paling lama ya, bisa dibilang paling pertama ada, dan kelihatannya perbedaan utamanya dibanding storage lainnya adalah si cookie ini selalu ke bawah ya, di request dan respond.
Apa di operasi-operasi protocol HTTP, jadi perbedaan paling utama sih itu ya kelihatannya.
Jadi kalau misalkan tadi kita login, terus kita udah dapat session ID-nya yang di-store di database, kemudian dikirimkan ke kita, setiap kali kita mau masuk ke halaman yang membutuhkan login, kita tuh nggak perlu login lagi, karena udah ada si cookie-nya ini.
Kalau misalkan kita nggak kirimin cookie-nya, berarti kita harus login lagi setiap halaman. Setiap halaman kan cape ya, karena kan tadi yang Ivan ceritakan bahwa setiap halaman, setiap request itu...
- Aslinya status. - Jadi dia nggak tahu kita udah dalam keadaan login atau belum. Nah, yang menandakan kita udah login atau belum ya cookie-nya ini.
- Ya, kali dengan cookie. - Iya. Ada juga yang kadang-kadang ada di halaman loginnya itu ada remember login selama 30 hari, ya itu cookie-nya ya expired-nya sampai 30 hari gitu.
- Ya kan? - Termasuk ini ya, termasuk dengan request yang terjadi via Ajax ya.
- Client side. - Oh ya, client side.
- Request. - Fetch.
- Ajax. - Ajax. XHR.
- Oh, ini bahasanya masih bahasa jQuery ya, Ajax. - Enak aja, itu Ajax itu sebelumnya. Itu yang diadopsi sama jQuery sebelumnya kan, Ajax.
- Apa? XML? - XML HTTP request.
Panjang banget namanya. Makanya disingkat sama jQuery kan dot get dot post.
- Ya, pokoknya apapun client side request tapi ya ini. - Iya.
- Ya misalkan kita... - Cookie selalu ke bawah. - Mau request ke API yang membutuhkan login atau autentikasi.
Jadi API-nya tidak publik, nggak bisa dibaca umum. Hanya bisa dibaca oleh user-user yang terautentikasi.
- Nah, caranya adalah... - Ya misalnya kita mau lihat draft-post kita sendiri.
Itu cuma misalnya aplikasi blogging atau email, kan kita harus lihat kita akan nge-fetch email kita sendiri atau draft-post kita sendiri.
Nah, kita harus kirim si token atau apapun itu yang mengidentifikasi siapakah kita lewat dengan cookies yang dikirim lewat request itu ya, berarti.
Betul. Nah, kalau mau tahu atau mau belajar lebih lanjut, disini ada tautan yang menarik nih dari Data Academia.
Nah, menurutku ini salah satu resursi yang enak buat beginner kalau misalnya yang pengen dari awal banget.
Terus kalau menurutku ini lebih jelas dari MDN malah. Karena MDN itu kan detail. Cuma maksudnya kita harus sudah tahu kita mau cari apa.
Kita harus agak familiar dulu sedikit baru cari. Nah, kalau ini tuh kayak urutannya lumayan enak sih menurutku buat dibelajarin.
Cookie itu, apa contohnya liatnya di mana? Terus itu ada contohnya.
- Ada... - Kalau mau dibelajarin lebih lanjut sih bisa cek aja link-nya.
Oke, ada contoh-contohnya, ada contoh kasusnya juga bisa dipakai di model autentikasi.
Ada, nanti kita bahas juga tentang third party, first party, cookie, gitu kan. Ada web security juga, macem-macem ya.
Nah, terus apa cara nge-setnya tuh bagaimana? Jadi kan tadi udah dibilang sedikit ya sekilas. Cookie tuh key value.
Maksudnya walaupun flag-nya banyak, semua tuh harus di-stringify jadi satu. Nah, bentuknya kayak gitu tuh.
Format sintaksnya seperti itu. Jadi nggak bisa kita kirim objek.
Betul, database sederhana yang hanya bisa menerima string. Jadi semuanya harus dijadikan string terlebih dahulu untuk value-nya.
Sedangkan key-nya string juga. Jadi dua-duanya string ya.
Nah, terus beberapa penggunaan yang cukup umum tuh usage.
Kan tadi kita udah bahas tuh yang 6, apa? Point 6.1 ya. Maksudnya identifikasi, siapa kita, 6.2 juga.
Autentikasi juga udah kita bahas. Cross-site tracking. Nah, ini yang nanti bakal banyak topiknya ya.
Iya, ada A/B testing juga. Jadi, apa? Bisa menentukan. Bisa nge-tag user-nya. Dia sudah akses alpas sehingga kita bisa kasih konten yang berbeda.
Jadi misalnya contoh kasusnya mungkin yang belum familiar ya. A/B testing tuh misalnya kalau marketing kita mau jualan sesuatu,
itu kalau tombolnya di atas, kita pengen tahu kalau tombolnya di atas yang membeli berapa banyak.
Terus gimana kalau ditukar. Misalnya apa, image-nya di atas, tombolnya yang di bawah.
Banyak yang beli kan itu mungkin untuk bakal pakai load balancer atau teknologi apapun itu, sebagian user dapat format A, sebagian user dapat format B.
Nah, kita kan harus tahu tuh user yang nge-click itu dapat layout yang mana. Jadi itu harus pakai cookie untuk A/B testing umumnya.
Umumnya seperti itu. Terus kita bahas apa lagi nih? Sudah tahu cookies itu apa? Kalo itu security, nanti aja lah ya.
Panjang itu ya. Panjang nanti. Oke, lebih ke ini mungkin. Kita udah tahu cookies itu apa, kemudian cara penggunaannya gimana,
digunakan di mana. Nah, kok kenapa tiba-tiba, ya cookies ini kan udah lama dipakai ya, udah lama banget gitu kan.
Dari 90an lah tadi. Dari awal 90an udah dimunculkan, terus kita pakai juga mungkin kalo temen-temen yang udah biasa
nge-hoding gitu ya, udah biasa bikin aplikasi web terutama, bikin login pasti pakai sessionnya, ya disimpanin salah satunya di cookies gitu kan.
Nah, tapi kenapa akhir-akhir ini berapa tahun belakangan nih kok tiba-tiba si cookie ini selalu harus kita accept atau kita reject gitu ya.
Ada semacam kayak pop-up atau banner di bagian bawah biasanya. Sebelum kita mau baca artikel atau mau buka aplikasi webnya, kita harus accept dulu.
Kita harus setuju dulu. Harus setuju. Nah, ini ada apa nih? Kenapa akhirnya muncul? Ada apa dengan cookies?
Ada apa dengan cookies? Ya sebetulnya mungkin itu ya berkaitan sama poin 6 tadi, beberapa penggunaan cookies. Ya mungkin sejak dulu kan emang
cookies itu bisa berisi informasi yang sensitif. Sensitif maksudnya apa? Ya itu bisa berarti rahasia atau bisa mengidentifikasi kita itu siapa.
Ya contoh paling gampangnya email lah ya. Email atau username dan lain-lain. Nah, terus apa? Nature-nya cookie itu yang tadi kita udah bahas kan,
selalu nempel di request dan response. Dan bahkan dulu, mungkin sekarang udah nggak ya atau masih. Jadi kalau misalnya di halaman web kita
membuat request ke origin atau domain lain, misalnya untuk memanggil image atau accept apapun atau javascript, misalnya analytic script apapun
yang di luar website kita, itu kan bikin request. Nah, kita di situ juga kekirim di request. Sementara cookie itu bisa berisi beberapa hal
yang bersifat informasi pribadi. Sebenarnya berangkat dari situ sih. Dan itu kan dari dulu. Cuma mungkin namanya apa e-commerce atau online marketing
atau praktek-praktek iklan dan analytics dan social media dan hal-hal semacamnya mungkin kan baru meledak ya sekian tahun terakhir ya.
Mungkin jadi muncul macem-macem, ya ada penyalahgunaan, mungkin ada eksploitasi yang berdampak kurang baik buat user, makanya mulai lahir aturan-aturan
yang mengatur penggunaan cookies. Kalau menurutku sih lainnya dari situ tuh. - Yang mengatur bagaimana penyimpanan data user.
- Penyimpanan data user. Ya, intinya sebenarnya si cookies ini kan sifatnya public ya. Jadi jangan sampai teman-teman
nyimpan data-data pribadi user di cookies atau di local storage karena kemungkinan bisa diambilkan sama orang ya.
- Jangan simpan ini ya, kalau webdev ini ya, jangan simpan IPIQ di cookies. - IPIQ? - IPIQ di cookies. - IPIQ? - Iya, siapa tahu.
- Itu agak unik juga itu. - Siapa tahu. - Cuma itu kan sebenarnya rumit juga ya nuance.
- Biasanya kalau untuk login, kita kan punya data session. Data session itu biasanya memang dikirim lewat cookies dalam bentuk jwt-encrypted kan.
Cuma yang tabu, yang gak boleh, itu passwordnya jangan dikirim lewat cookies. Kalainkan sessionnya. Kenapa? Karena session itu bisa di-invalidate kan.
- Betul, iya. - Kita bisa matur, itu bisa expire, bisa di-invalidate. Jadi ya itu berbagai layer keamanan aja sih.
- Dan beberapa tahun terakhir muncul, nah ini gara-gara ada isu tentang data protection tadi. - Ngomongin cookies, "Ada-ada nih, akan kesini nih."
Kalau sebelumnya, ingat gak, ya saat social media meredak lah ya. Itu kan ibaratnya web 2.0, bahasanya jaman itu ya.
Jadi user itu, kita pakai situs dan kita itu adalah, sebagai user kita itu adalah, ini apa istilahnya bahasanya?
- Kita adalah produknya. - Kita adalah produknya, kita disegmentasi sebagai target iklan dan segala macam.
Pernah gak sih kalian apa ngerasain gitu misalkan awalnya kita browsing-browsing di marketplace.
Tiba-tiba buka social media, oh tiba-tiba muncul sepatu gitu.
Dan buat orang awam, maksudnya orang yang gak tahu tentang ini, itu mereka tuh bisa kaget loh.
- Maksudnya bisa terpengaruh secara psikis, kaget. - Loh, kok dia tahu ya? Kita baru cari sepatu gitu kan.
Ibaratnya itu sih damanya remarketing, ya. Remarketing dimana kita bisa disegmentasi berdasarkan interest.
Dan kemudian karena kita menggunakan situs lain contohnya, anggap lah mesin pencari apa gitu ya.
Kita login, ya login disitu. Terus kita, keyboardnya kita cari sepatu indah bola pingpong gitu misalnya.
- Misalnya sepatu apa lah gitu. - Tengah.
Sepatu. Misalnya sepatu lari gitu ya, sepatu lari gitu. Akhirnya dan kita itu di tag itu, interest kita sepatu lari.
Nanti data kita itu bisa digunakan oleh si penyedia mesin pencari itu dijual ke,
disediakan service-nya ke third party untuk digunakan, eh ini user-nya, ada pool-nya yang interest dengan sepatu lari gitu.
Bisa lu target, nah gitu. Jadi saya pernah jadi produknya, pernah juga jadi marketer-nya.
Jadi kayak nyari men segmentasi user, berdasarkan kalau saya segmentasi keyboard ini, umur siang, daerah mana saya dapat 10.000 user.
Itu target saya, saya coba targetin untuk iklan.
Bisa detail ya, bisa sampai umur, range umur, lokasi.
Nah itu justru kalau cuma satu, jadi kan ini adalah akumulasi data yang masif lah, yang banyak banget.
Jadi kalau cuma satu poin kan sebetulnya kalau kita lihat di gambaran paling kecil, cara kerjanya kan iklan nih, iklan atau satu barang.
Itu disimpan bahwa user ini melihat sepatu lari, sepatu lari yang sepatu lari laki-laki ukuran sekian.
Nah tapi dengan cookie yang bisa mengikuti user kemana-mana, bahkan ke situs lain,
lama-kelamaan kan gambarnya makin makin besar, maksudnya makin luas.
Jadi misalnya buka sepatu lari, membeli sepatu larinya di sebuah toko di Jakarta Selatan.
Misalnya berarti mulai ketahuan lokasinya.
Terus selain sepatu lari, dia juga misalnya si user itu juga misalnya membeli apa ya,
beli aksesoris bayi atau baliha misalnya. Berarti kan diketahui itu sudah berkeluargaan, sudah punya anak.
Terus misalnya beli aksesoris mobil, berarti dia juga naik mobil, berarti bisa dibuat gambar tentang mungkin,
ya itu status, tempat tinggal, mungkin range penghasilan, jenis pekerjaan.
Makin banyak data point-nya kan itu makin identifying ya, jadi bukan cuma satu hal aja,
tapi kalau udah numpuk itu dampaknya jadi besar.
Jadi terbentuk persona masing-masing gitu ya?
Betul. Nah di zaman sempat karena social media itu mulai mengumpulkan data seperti itu,
dan ternyata datanya mulai digunakan untuk segmentasi iklan dan juga untuk kempen-kempen.
Di jual ke hal, oh ya politik juga ada dulu.
Kampanye politik, mungkin bukan kampanye politik tapi lebih ke arah menyebarkan istilahnya.
Berita-berita provokatif juga termasukkan yang bisa memenuhi, memikirkan orang.
Iya, menarikkan dan bisa menyesuaikan. Intinya banyak hal yang bisa digunakan.
Pokoknya di awalnya simple, kayaknya kita nggak mikir sampai situ.
Tapi ternyata setelah numpuk terbukti itu punya dampak yang,
kalau nggak diatur, bisa punya dampak yang berbahaya.
Terus di 2016 lahirlah GDPR, General Data Protection Regular dari European Union,
mewajibkan semua company ada range-nya ya, ada range duitnya.
Kenapa saya lupa, kalau nggak salah.
Yang cukup besar lah pokoknya ya.
Saya bukan lawyer, jadi saya cuma menjelaskan dari sisi web dev yang pernah implementasi GDPR secara detail.
Jadi, company yang saya berikan service untuk mengimplementasikan GDPR compliance ini terhadap cookies,
itu pertama memasangkan cookies, cookie banner itu.
Di mana cookie banner itu terdiri dari beberapa kategori.
Ada functional cookie, ada functional yang wajib,
ada kategori yang marketing, ada kategori yang analytics, segala macam.
Di GDPR ini sendiri mengatur, nggak cuma mengatur cookie, tetapi mengatur bagaimana si company bisa--
-Mengelolaan data secara umum.
-Iya, mengelola data si customer-nya dia.
Pertama, GDPR ini secara policy mengatur, jika ada identifier yang diambil dari user,
maka user itu wajib diberitahu.
Atau dengan konsen, makanya namanya cookie konsen.
Wajib memberikan konsen.
-Konsen itu bahasa Indonesia apa ya?
-Memberikan izin, izinkan data kita untuk dipakai mereka.
-Walaupun kadang-kadang pilihannya cuma accept.
-Bukan dipakai, disimpan, dikelola.
Mengizinkan data-nya kita, karena data kita jika akses website, misalnya Wikipedia ini contohnya,
mengakses Wikipedia, maka perusahaan itu wajib untuk
memberitahu pada si user kalau mereka akan menyimpan data-nya dan wajib juga memberitahu user
bagaimana cara mereka menyimpannya dan memastikan keamanan data mereka.
Jadi ada policy-nya.
-Konsen itu adalah memberi izin secara sadar.
Jadi ga boleh manipulatif di background, tiba-tiba ototis jalan ya, emang harus secara sadar, mengeklik, accept.
-Ga boleh bintang dan ketentuan berlaku gitu ya.
-Jadi itu satu, jadi memberitahu user untuk memberikan izin secara sadar.
Kedua, GDPR mengatur bagaimana data itu disimpan secara aman.
Ketiga, memberikan, mengatur bagaimana kalau data itu yang disimpan itu
sepenuhnya bukan milik dari si perusahaan, tetapi milik si customer-nya, si user-nya.
Jadi user telah yang memiliki data itu yang disimpan oleh perusahaan.
Jadi sewaktu-waktu jika user ingin meminta data apa saja yang disimpan, si perusahaan wajib untuk memberikannya.
Menyediakan itu, semuanya gitu ya, ga boleh ada yang ditutupi.
Terakhir, si user boleh meminta si perusahaan untuk menghapus datanya itu dari perusahaan itu secara completely tanpa boleh ada backup.
-Kalau soft delete, ga boleh ya?
-Gak boleh, jadi masuk trash bin, terus nanti di cover, ga boleh.
-Kalau kita bikin aplikasi kan, biasanya kan soft delete ya?
Cuma tidak ditampilkan saja, tapi biasanya tetap ada.
-Ada challenge-nya di sini, kalau secara sistem data ukir segala macam, kebetulan situs yang saya bantu itu,
saya kerjakan itu tidak ada data yang aneh-aneh yang disimpan secara saja, cuma data analytics saja.
Dan itu data-nya bisa dikumpulkan, bisa dihapus segala macam.
Jadi secara third party vendor yang mereka gunakan untuk analytics pun sudah sadar GDPR dan sudah ada fitur itu.
Fitur untuk mengambil data, fitur untuk menghapus data sudah ada.
Namun yang cookie banner-nya, cookie consent banner-nya ini kan harus di-customize ya.
Jadi dari sisi ada challenge-nya, karena situs ini sudah cukup lama.
Cookie-nya itu ada banyak, analytics-nya ada banyak, tracking-nya ada banyak, dan di-inject dari mana-mana.
Dari GTM lah, dari analytics lah, dari... I don't know, banyak banget lah intinya.
-Dan berarti kalau sudah adopt GDPR ini, by default kan harus off semua ya?
-Sampai secara eksplisit mengizinkan, baru yang banyak banget tadi itu baru jalan semua.
-Jadi masang cookie consent itu tidak hanya memasang, toh, jalan, orang bisa accept, that's it.
Bukan. Tetapi harus bisa nge-block semua third party vendor itu tidak boleh menanamkan cookies-nya sebelum ada consent-nya.
-Ok. -Jadi harus satu-satu itu di pilih tuh.
Misalnya kayak ada yang pakai Hotjar, ada yang pakai Google Analytics,
ada yang pakai dari GTM, Inject, segala macam tracking yang mereka butuhkan gitu ya, ads.
Maka semua itu harus di-block dulu, nggak boleh jalan sampai cookie consent di-block.
-Ribet juga ya? -Itu yang implementasinya secara benar.
-Ok. -Jadi kita harus kayak nasi API event,
jadi ada event dispatch ya, jadi event dispatch, dan waktu event dispatch itu kita tanungkan di cookies-nya kita sendiri,
kalau kita sudah pasang, dan setiap kali page reload, kita ngirim dispatch event itu ke third party vendor,
baru mereka bisa jalan. Kalau nggak, nggak boleh jalan.
-Kalau nggak, nggak boleh. -Iya.
Dan kalau kita accept, berarti kita dengan sadar memberikan izin web,
data kita disimpan di tempat mereka dan bisa digunakan untuk hal-hal yang dibutuhkan gitu ya.
Jadi betul sekali, jangan main accept-accept aja.
Pastikan kalau misalkan teman-teman tidak bersedia datanya dipakai ya, direject aja.
-Jangan pakai webnya, gitu ya. -Iya, cuma prakteknya kan kadang pilihannya cuma accept.
-Accept all atau accept persial? Ada tuh, accept yang... -Kadang ada cuma satu accept.
Makanya hanya accept aja, kalau nggak ya di close aja gitu kan.
-Tapi ya itu minimal satu langkah, ya nggak. -Gak harus.
Cuma kalau user nggak bersedia, ya bisa ditutup aja, nggak usah pakai layanan itu.
-Ini nih ada contohnya, buka aja yang kayak dari standard charter, dia pakai OneTrust kan ini ya?
-Iya, biasanya dead service-nya ya sekarang. -Kalau melihat yang bagus itu dari bank ya, biasanya ya.
-sc.com/en. -Apa tuh, coba dong, Pak.
-sc.com/en. -English.
-SC itu apa? Standard charter? -Standard charter.
-Kok begini? -Loh, kena block, kena block. Ini... ada apa?
-I don't know. -Refresh, refresh. Nggak bisa.
-Kena block CSS-nya, mungkin sama... -Coba deh, theguardian.com juga bagus, theguardian.com/international.
-Nah, make your choice. -Nah, tuh. Manage my cookies.
-Kalau ini dia kan UK-based ya, berbasis di UK, Eropa, Eropa.
Kalau ngikutin GDPR, ini yang kayak strict banget lah, salah satu contoh yang ya, best practice lah.
-Maksudnya yang ideal, yang beneran meng-educasi user. -Best practice, ya.
-Ini accept atau yes, I'm happy ini accept, kalau kita mau lihat... -Yes, I'm happy accept, kita bisa manage.
Bisa lihat yang mana aja yang kita accept, yang mana yang kita tidak. On/off ya, jadi sistemnya ya.
-Dan ada penjelasannya tuh. -Status rejected all.
Nah, ini udah reject semua gitu kan, habis itu kita close.
Kita tetap bisa pakai, meskipun mungkin analyticsnya nggak jalan, atau ada beberapa...
Misalkan ini alamatnya juga mungkin berbeda gitu ya, apa, location dan lain-lain mungkin ya, nggak tahu.
Dan bahkan tadi apa sih, ada list site vendors-nya, jadi kayak pasang iklan atau...
-Udah kubur-kubur itu hutup ya. -Apanya tuh?
-Munculin lagi bisa kok, kayaknya... -Bisa ya?
-Bisa di bawah, bisa di bawah kayaknya. -Bawah, bawah, ke footer.
Oke, ini iklan. Ke footer ya, ada ya di bawah ya?
-Lihatannya ini ya. -Privacy settings.
-Coba deh, privacy settings. -Privacy settings.
-Iya, klik. Nah. -Nah, that's a vendor.
Satu lagi, ke concern vendor yang benar tuh kayak gini.
Jadi habis user submit, harus ada caranya user untuk kembali lagi ke sini.
-Kalau kita berubah pikiran gitu ya? -Yes.
Itu ada keterangannya tuh, di bawah kan, you can change the above settings, blablabla.
Ya, ada Cloudflare, ada Cloudinary, ada Google Analytics.
Nah, Google Analytics juga sempat ini ya, kena isu juga kan,
bakal di block dari apa, di Eropa gitu kan.
Satu-satunya gara-gara dia nggak consent kan, belum mau waktu itu.
Ya, nggak compliance, sorry, nggak compliance.
Akhirnya di ancam untuk tidak diperbolehkan, digunakan di Eropa.
Walaupun sekarang kayaknya udah clear ya. -Uda. Kayaknya udah bersahabat mereka.
-Sudah bersahabat. Iyalah.
Ada banyak sekali, ya. Ada Primeo, ada Netflix, ada Rekspace, macem-macem.
-Gimana nih coba bagi si developer-nya?
Ayo, teman-teman sebagai developer, ayo sadarnya untuk menyediakan fitur ini.
Cuma kalau misalnya target audience kita bukan di wilayah yang ditargetkan oleh hukum kayak gini,
ya nggak perlu. Belum perlu kan? -Belum perlu.
-Belum perlu. -Iya.
Kalau soalnya di target audience kita ada hukum gini, ya harus.
-Iya harus lah. Sekarang ini kan data kita banyak bocor. Ini gimana ini?
Kalau tidak ditangani dengan tepat, bahaya.
-Ya coba. Coba Mas Risa jadi menkominku dulu lah.
-Jangan. Jangan saya. Saya nggak bisa.
Ngeri ini soalnya data-data kebocoran data kan.
Salah satunya juga yang mengekir itu kan. Sebenarnya bukan kebocoran data yang mengekir kan.
Yang mengekir adalah banyak apa? -Segmentasi.
-Iya. Perusahaan-perusahaan yang besar-besar, terutama sosial media, e-commerce, dan lain-lain
menanfaatkan data yang dia punya, data user yang dia punya untuk kebutuhan
yang di luar apa ya, yang tidak terpikirkan sebelumnya.
Dan kemungkinan bisa merugikan user atau merugikan pihak-pihak yang lain gitu.
Jadi salah satu tujuannya adalah untuk, ya harus ada regulasi lah.
Harus ada regulator yang menentukan ini boleh atau tidak gitu kira-kira.
-Bagaimana main cantiknya.
-Misalkan analytics, kita bikin sistem atau kita bikin aplikasi untuk analytics website misalkan.
Seberapa detailnya, seberapa data apa yang mau disimpan, apakah data username-nya
atau data email-nya perlu disimpan atau gimana, itu harus ada regulasinya kan.
Supaya kita bisa mengikutin.
Kalau semua datanya disimpan sampai kukir-kukirnya juga diambil kan enggak lucu ya.
-Dan kalau misalnya memang perusahaan atau yang punya produk, pastikan berargumen,
"Loh kita perlu ini misalnya kita jualan pakaian ya."
Kita kan perlu tahu identitas kayak usia atau jenis lama,
customer kita sendiri untuk menyesuaikan produk yang dijual atau promo atau tawaran.
Oke lah, itu kan keperluan korporat ya, keperluan industri.
Cuma kan ini lebih ke pertanggung jawapannya aja sih.
Jadi tetap ada regulasinya.
Jadi paling enggak yaitu user bisa dengan sadar memberi consent, memberi ijin.
Terus user juga bisa minta untuk dihapus datanya kalau enggak berkenan.
Jadi ada banyak keperluan ya, ada keperluan industri atau orang jualan atau produk.
Ada juga keperluan individu para customer lah,
kayak masyarakat yang menggunakan macam-macam jasa dan produk online.
Nah, regulasi itu kan mengimbangi semua kepentingan itu sih, biar enggak eksploitatif.
Oke. Nah, ngomongin ini kan udah banyak yang ini ya, banyak yang menyadari bahwa ribet sekali gitu kan.
Apalagi ceritanya Ivan kan, luar biasa ribet.
Ada nggak sih tools atau framework sudah menyediakan supaya membuat pekerjaan kita jadi lebih mudah?
Sebenarnya ada step-party-step-party yang sudah ada kayak one-trust kayak gitu ya, atau sejenisnya.
Sebenarnya kembali lagi itu cuma tools untuk menampilkan cookie consent banalnya dan men-trigger.
Dan si framework ini sudah bekerja sama kayak Google.
Sudah punya kayak integrasi ke GTN, ke Google Analytics, sudah punya integrasinya.
Kita tinggal klik-klik-klik. Namun tetap masih butuh saat kita implementasi sebagai web dev.
First party cookie kita sendiri kan mungkin ada. Kita kayak save cookie kita sendiri gitu ya.
Kita juga harus sadar gitu mengirimkan cookie.
Namun ada cookie yang tidak ada personal identificationnya.
Ada contohnya anggapan gini, CDN.
CDN. Jadi saya pernah dapat sebuah kasus yang ujung-ujungnya nggak bisa saya hindari kalau cookies itu harus ada.
Namun kembali lagi waktu itu ngomong sama lawyer,
kalau cookie itu dibutuhkan oleh si CDN untuk menentukan lokasi terdekatnya.
Sebenarnya tidak ada identifikasi user di situ.
Jadi kayak pertama request, kan CDN-nya kan ada banyak lokasi.
Dia harus supaya request yang selanjutnya itu tidak mencari lokasi lagi.
Tetapi sudah tahu lokasi terdekatnya misalnya dari Jakarta.
Jadi next request-nya itu ke Jakarta jaman.
- Gak perlu nyari dari awal lagi. - Iya, nggak perlu cari apa?
Agorik magic strandnya gitu nyari terpendek gitu ya.
Jadi cukup satu kali tetapi itu butuh identifikasi tadi.
Namun identifikasi itu tidak ada menyangkut dengan personal identification.
Itu anggapannya stateless, hanya menentukan posisi supaya performa bagi user.
Maka itu jatuhnya masuk sebagai mandatory cookie yang wajib ada.
Jadi kalau mau pakai website ini, mandatory cookie-nya ini dan itu sudah ada.
Dan itu harus dijelaskan di data privacy policy-nya.
Wow, oke. Se detail itu ya berarti ya.
Kalau ini, Eka, meta framework kayaknya sudah beberapa ada yang sudah menyediakan ya.
Kalau ini, ini di luar topic privacy, di luar GDPR, kita balik lagi.
Cookies itu kan memang teknologi web.
Jadi mungkin tadi kan kalau mungkin jadi kesannya apakah cookie itu berbahaya,
apakah cookie itu negatif, ya nggak juga.
Cookie itu teknologi web yang justru salah satu kan tadi tuh dari awal storage.
Dan dari awal sudah ada dan itu memang penting.
Nah terus kan mungkin kadang orang menghindari cookie malah nge-store-nya di aneh-aneh,
di local storage lah, atau malah in memory.
Padahal ini teknologi web yang penting dan relevan.
Kayak untuk menyimpan login session misalnya itu kan penggunaan yang sangat valid
dan memang kembali ke web API.
Nah ini di beberapa yang aku perhatikan, di beberapa framework yang next-gen,
yang baru lah, yang kembali ke, yang banyak kembali ke web API itu mempermudah,
apa standard-standard web platform itu mempermudah kita bekerja dengan cookies.
Dua contoh yang aku temui sih di Remix dan di Astro.
Jadi kan cookie itu kan tadi rada nggak enak kayak sebenarnya apa,
kalau kita belum familiar, untuk nge-store key value-nya itu harus di-stringify,
harus dipisahkan oleh tanda apa, semicolon, titik koma, itu sering miss kan kadang.
Jadi apa, ini di beberapa meta framework seperti Remix dan Astro,
itu dipermudah dengan sinteks yang itu lebih, kita bisa pakai java strip object,
terus kita bisa pakai intelligence, apa, code completion.
Jadi kita tinggal nge-tick, kan kita lupa misalnya apa, max age gitu.
Nah kita nggak harus nge-ingat, kita nge-tick ma, tuh langsung muncul lah drop-down-nya.
Jangan sampai nggak perlu malas lah, document.cookies juga bisa.
Oh, kalau Remix dan Astro ini kan server-side juga.
Ini server-side, aman.
Nah itu, bahas apa, document.cookies juga tuh penting.
Jadi apa, cookies itu ada yang bisa diakses dari browser,
ada yang nggak bisa, tergantung flag, apa, HTTP only ya.
HTTP only, yang tadi di sini kan?
Ada flag-nya same-side, HTTP only.
Ini, ini, HTTP only.
Nah, iya tuh.
Jadi kalau misalnya pakai flag HTTP only,
dia cuma dikirim di server-side request and response.
Tapi kalau tanpa flag itu, ya bisa diakses dari browser.
Gampangnya kita tinggal buka, apa, devtools, console log,
tick aja document.cookie.
Itu akan muncul.
Itu untuk client-nya, di sisi client-nya.
Nah itu tuh ada implikasi keamanannya juga.
Nah kalau, mungkin kadang-kadang kalau kita lihat beberapa artikel,
itu kayak dianggap itu tabu banget kalau hal-hal yang agak sensitif
atau personal identification itu jangan sampai bisa diakses dari browser.
Nah kenapa? Karena ya apapun yang diakses dari browser kan
itu sebetulnya satu layer aja, satu layer keamanan juga.
Kalau ada yang, apa, misalnya bisa mengakses kode JavaScript dari browser,
itu bisa, bisa terkirim untuk sesi datanya.
Tapi ya kembali ke kita mengamankan,
gimana kita ngamanin juga jangan sampai bocor isi client-side cookie-nya.
Oke, jadi bentuk cookie-nya sendiri seperti ini ya, kurang lebih ya?
String semua iya.
String ya, jadi kalau misalkan, ya plain gitu ya,
jadi kalau misalkan kita ngirim data-data yang private,
ya kalau orang bisa menginterrupsi request dan response, bisa dapat ya.
Nama, terus mungkin email, apa lagi password.
Kalau HTTPS, nggak bisa.
Ada secure, ada flag secure juga sekarang.
Jadi kalau mau menggunakan document.cookie,
kita harus parsingnya manual juga seperti ini,
displit dulu berdasarkan titik oma, terus abis itu ditrim,
terus ada start with dan lain-lain ya, jadi hasilnya seperti ini.
Nah, kalau pakai meta framework yang tadi ya, udah cukup pakai helper-nya mereka ya.
Sebetulnya sama, dibalik layer juga kayak gitu, cuma mempermudah aja.
Ya, kalau misalkan cuma simpan data atau baca data 1, 2,
atau sedikit gitu ya, cukup menggunakan document.cookie.
Tapi kalau misalkan teman-teman sudah mulai butuh banyak gitu ya,
kayak tadi kan, si ini kan banyak sekali ini ya, data-datanya ya.
Nah, itu mungkin udah butuh bantuan library atau framework yang dipakai,
mungkin sudah menyediakan fitur untuk manajemen cookie,
seperti Remix dan juga Astro.
Saya yakin yang lain juga mungkin ada, tapi mungkin kita belum tahu aja.
Atau ada external library untuk mereka, misalkan Next.js ada terpatir library juga
untuk manajemen cookie ya, silahkan digunakan.
Nah, lanjut lagi pembahasan sedikit.
Kita bahas tadi sempat ada yang nyebut first-party, same-site, dan lain-lain.
Itu maksudnya apa tuh?
Mau bahas apa dulu, same-site apa first-party?
Same-site kali ya.
Same-site.
Itu juga merek.
Cookie beneran.
Same-site ini maksudnya adalah?
Dia sebenarnya ini ya, jadi kalau cookie sebelum ada, ini kan baru, baru.
Baru akhir-akhirnya, saya nggak tahu kapan munculnya.
Itu intinya kalau melihat, itu RFC-nya itu ada tuh.
Kapan dia disetujui.
Ini hanya flag, jadi kayak tadi HTTP only, secure, same-site.
Same-site itu adalah atribut atau flag-nya untuk memberitahukan
kalau cookie yang diset ini hanya bisa diases oleh
atau bisa digunakan hanya dari origin yang sama.
Artinya tidak bisa digunakan untuk attack di CSRF, cross-site server forgery.
Kalau tekniknya ya, saya cross-site itu kan imbaranya cookie kita berasal di liar road,
tetapi request yang terjadi dari domain yang beda.
Tetapi ke situs yang target utama, tujuan, tetapi menggunakan cookie-nya kita.
Jadi itu cross-site.
Kalau kita set dengan same-site, maka browser yang misalnya kita buka situs orang ini,
yang situs false ya, situs scam bahasa ini.
Ada button, terus kita klik, ternyata button itu kita klik itu untuk anggapan aja untuk ngehapus data.
- Nge-fetch sesuatu. - Nge-fetch sesuatu yang ada di situs utama.
Tetapi kan kita punya, kalau tanpa same-site, kita itu punya cookies yang di situs kita tersebut.
Jadi kalau kita klik button itu, maka yang terjadi adalah authorize request menuju situs target
yang melakukan apapun, mungkin set password, inject user, atau segala macamnya.
Nah, dengan memberikan flag same-site, maka jika button tadi diklik dari situs scam,
maka cookies itu nggak bisa diakses, nggak bisa dikirim, nggak ada gunanya.
- Tidak valid ya? - Nggak diterima.
- Nggak muncul ya? - Iya, betul.
Ini ada hubungannya sama course nggak? Course origin blah blah blah?
- Beda. - Beda ya?
Jadi hanya bisa digunakan di domain yang sama, same-site, di website yang sama.
Ada bahasanya lagi, strict itu kalau strict, ada lagi yang namanya legs, jadi bisa di set same-site strict, same-site legs.
Jadi kalau legs itu lebih di legs. Kalau strict itu benar-benar hanya langsung dari origin,
kalau legs itu kalau nggak salah, sub-domain-sub-domain masih bisa akses.
Oh sub-domain masih bisa, kalau yang strict itu hanya domain yang sama, persis gitu ya?
- Origin, yes. - Origin, oke.
Nah, kalau first party, third party cookies, tadi udah dibahas kayaknya ya third party ya?
Simplenya, first party itu cookie yang dari origin, third party dari situs yang bukan origin.
Dalam hal ini kita nge-load Google Analytics, maka Google Analytics itu bakal nge-set cookies satu
di domain Google Analytics, satu lagi di domain-nya kita.
- Tempat kita. - First party itu adalah cookie yang di-set oleh origin kita,
bukan yang di-set oleh Google Analytics, itu first party.
Nah, denger-denger kan katanya cookie mau dihapus 2023.
2023 cookie mau dihapus katanya, 2022 malah.
Padahal ini maksudnya clickbait aja ya, bukan cookies-nya yang dihapus,
tapi ya apa, cross origin ya?
- Third party cookie, bisa lagi. - Third party cookies.
Third party atau cross ya? Coba dibaca.
Apple, apa? Mana ya? Kok nggak ada informasinya?
- Dibawah kali. - Dibawah? Gak ada.
- Ya, malah alternatifnya. - Iya.
Yang tidak bisa itu adalah third party cookies nge-set ke,
jadi kayak saya bilang tadi, Google Analytics tidak bisa nge-set cookie
ke sebagai cookie origin lagi.
Coba kita masih bisa buka application DevTool di sini.
- Di sini, inspect element. - Iya, inspect element.
- Terus? - Ke application cookies.
Liat ya, padahal buka website ini ya, website-nya Medio.
Jadi third party itu yang account Google, CDN and Badly, sama YouTube.
- Iya, yang ini first party. - Yang ini first party.
Tetapi kalau kita lihat lebih dalam lagi, yang diset sama si Medio-nya itu cuma sebagian.
Contohnya kayak chat.google, saya yakin bukan diset sama si Medio.
- Nah, chat.google apa itu? - Itu liat tuh, ya itu host.
- Oh, chat.google. - Oh, chat.google, iya kan?
- Itu tidak diset oleh si Medio. - Oke.
Itu diset oleh JavaScript yang jalan di browser,
dan set-nya sebagai origin-nya si Medio.
Jadi bukan diset oleh dari server, oleh Medio.
Jadi isu-nya yang saya dengar, third party itu tidak bisa lagi nge-set cooking-nya.
Oh, cooking-nya yang di origin.
Oke, jadi bukan cookie bakal dihapus, kita nggak bakal ada konsen-konsen lagi, nggak ya?
- Konsen itu tidak. - Nggak mungkin.
Nanti nggak ada orang bisa login.
Iya, tapi ada kapabilitas yang dilarang atau yang tidak diperbolehkan
dari third party service itu nggak boleh menulis ke cookie kita yang di origin kita, gitu ya?
Jadi kalau mau store data ya harus dari sisi kita, apapun yang kita kirim,
harus kita kirim secara manual ke mereka ya?
Maksudnya ke third party itu. Implikasinya kurang lebih begitu kan?
Ya, di limit berarti ya proses tracking-nya.
Jadi nggak boleh sembarangan nyimpen-nyimpen data lagi di cookie yang bukan milik kita.
Nanti ini kalau menurut saya apa plan yang dipus oleh Chrome Tale,
kalau misalnya di third party cookies sudah dihapus, itu lebih diatur secara lebih strict lagi menggunakan storage itu.
Untuk nyimpan cross-site data itu menggunakan namanya set storage.
Bahasanya itu di privacy sandbox.
Nah, ini ada pertanyaan bagus. Apakah cookies bisa diakses di Chrome extension?
Chrome extension bisa mengakses dokumen, dokumen objek.
Jadi kalau misalnya tadi nggak pakai HTTP only ya bisa.
Bisa, bisa.
Jadi cookie itu sifatnya public kan.
Bukan public ya, maksudnya ada di browser kita sendiri gitu kan.
Apapun yang kalau extension itu kan jalan di browser kita gitu kan.
Jadi ya bisa sebenarnya.
Cuman ya kadang-kadang datanya juga sudah di itu kan.
Jadi tidak berarti sebenarnya.
Ya sebenarnya sama aja kayak local storage atau semacamnya kan.
Kalau yang kita ijinkan buat diakses dari client-side.
Course dihapus enggak, course masih tetap ada.
Justru malah makin, ini ya, makin strik gitu ya, nggak boleh sembarangan gitu ya.
Kalo kita mau akses data, iya kita mau akses data atau kita mau kasih,
ngirimin data balik ya itu harus udah lebih strik sekarang.
Ust, sampai sekarang masih belum nangka full link concept course lah.
Masih bingung juga.
Bisa kita bahas di episode mendatang.
Meskipun udah ngomong course, tapi belum ngerti 100%.
Ngefix backnya bisa.
Rezipnya kurang yakin.
Nah ini apa nih?
Nah khusus Chrome, ini nih ada lagi nih bikin partition storage.
Cuma ini masih Chrome only dan masih statusnya kelihatannya sejauh ini masih origin trial.
Jadi kelihatannya ini adalah developer atau situs bisa opt-in.
Kan tadi tuh yang barusan dibahas,
kalo dari terparti, kalo bukan dari tempat kita, ya udah nggak boleh akses.
Nah kalo ini kelihatannya arahnya adalah misalnya gini kasusnya kita punya 2 website, 2 domain.
Tapi keduanya tuh punya milik kita dan emang ada sesuatu yang harus dikomunikasikan.
Entah state user atau mungkin preferensi tertentu.
Jadi ya itu penggunaan yang valid karena kita opt-in
agar 2 domain yang berbeda itu bisa saling mengirim atau menyimpan, menulis cookies.
Kayak set storage.
Mirip ya?
Iya.
Pada baca set storage, shared storage API.
Belum, belum.
Belum.
Gue pernah ikut ini ya sih, pernah ikut apa namanya.
Origin trial, apa? Survey?
Bukan, apa namanya?
Webinar.
Pemenalan webinarnya internal di bot GDI.
Itu ada public link-nya mengenai set storage.
Tapi masih origin trial juga.
Masih origin trial, origin trial ini maksudnya apa?
Kita harus opt-in, kita harus deptar.
Harus deptar untuk mengakses fiturnya.
Jadi belum di-ship, belum masuk ke software Chrome-nya.
Jadi, maksudnya, tenang aja.
Gak perlu khawatir kalau kita gak eksplisitif deptar untuk itu, kita gak bakal affected.
Mirip-mirip nih ya.
Unpartitioned cross-site data in security environment.
Habis mandi. Intinya sama kayak cip tadi.
Namun, cara akses, cara mengakses data yang di-shared itu lebih secure dan ribet.
Semakin secure, memang semakin ribet kan?
Semakin secure, semakin ribet.
Memang, iya.
Jadinya, saya gak tahu.
Waktu diceritakan saya gak masuk di atas, jadi masih belum dapet.
Nah, ini beda lagi nih.
Kuki-nya nih, ini cuma ada data.
Tapi ada more details juga.
Ada more details. More details ini.
More details cuma informasi.
Gak ada kayak yang tadi.
Jadi dipaksa. Cuma dikasih tahu.
Analyze traffic, remember your preference, dan optimize your experience.
Cuma, maksud saya kalau kita gak bergenan, ya jangan...
Yaudah, tutup aja, gitu ya.
Jadi ini hanya informasi aja ya.
Kayak memberitahu bahwa ini di-track loh, gitu.
Udah, gitu kan.
Kalau mau akses silahkan, gak mau, ya udah, cabut, gitu kan.
Oke.
Ada apa lagi nih, ada apa lagi nih?
Apakah, loh ini pertanyaannya agak ini ya.
Agak random, tapi gak apa-apa.
Apakah DDA Indonesia ada yang mendalami ontologi, network science, RDF?
RDF itu apa ya?
Reach Data Format.
Oh, Reach Data Format.
Ontologi itu apa tuh?
Jadi, ontologi itu kayak...
Sila Sophical Study of Being.
Ya. Klasifikasi data, berdasarkan.
Proses mengklasifikasi data dan bagaimana hubungan data.
Jadi data network, kayak data network.
Ya.
Dan yang saya kerjakan sekarang ini masih ber...
Masih seputar ontologi.
Dan bagaimana koneksi antara data A ke data B dan C.
Dan kembali lagi ke Reach Data Format, yes.
Skema data.
Kebetulan lagi ngerjain itu.
Di news side.
Saya pernah belajar, tapi tidak mendalami.
Cuma belajar aja waktu kuliah.
Tapi tidak mendalami.
Cuma sekadar tahu.
Bahkan sekarang pun kayaknya udah lupa ya.
Mungkin nanti kalau ada yang di machine learning juga...
Ini kan relasi antar data pasti harus kuat banget ya.
Kalau machine learning.
Cuma belum ada.
Belum ada.
Di machine learning Indonesia, akan ada.
Gak tahu, kita tunggu aja.
Machine learning ya?
Oh, kalau yang sekarang data cloud ya?
Cloud, ya.
Oke.
Apa lagi yang mau kita bahas?
Oh ini, satu lagi terakhir.
Saya punya website yang lumayan seru.
Namanya Track This.
Ini yang tadi kita bahas tentang persona.
Jadi kan kalau data kita udah terbiasa.
Di kelompokan oleh si ads atau berbagai website.
Termasuk e-commerce atau social media dan lain-lain.
Kita mau ngacak nih, mau random.
Kita bisa buka trackthis.link.
Teman-teman terus klik.
Nanti misalkan kita mau personanya sebagai apa nih?
Orang kaya.
Orang kaya lah.
Influencer.
Atau hype bisni apa, gak tahu.
Jadi begitu diklik.
Dia akan membuka tab-tab baru di browser kita.
Yang mengakses website-website yang berhubungan dengan kategori-kategori ini.
Sehingga data kita jadi keren dong.
Oh, biar targeted ads-nya bingung ya.
Ini istilahnya security by obscurity.
Yes, exactly.
Tapi hati-hati karena tiba-tiba nanti fan laptopnya nanti bunyi.
Karena dia buka tab banyak sekali.
100 tab.
Yes.
Terus jangan lupa pilih yang beda dengan profil asli kalian.
Kalau misalkan kalian aslinya orang kaya.
Buka filthy rich.
Kenapa juga bolo?
Ini situasi yang benar-benar.
Itu tab-nya apa?
Apa sih tab yang selanjutnya?
Habis te, ada gambar sepatu.
Itu ilustrasi doang.
Atau beneran.
Oh, hype bis.
100 tab.
Oh, penjelasan.
Penjelasan apa yang dibuka.
Ya, jadi kalau misalkan kita buka hype bis berarti yang ditawarkan itu fashion ya.
Statwear, sepatu.
Yang terbaru.
Hype bis itu akhirnya semua yang hype.
Semua yang hype.
Kalau filthy rich ya bukanya itu ya kapal persiar gitu ya.
Gimana cara private jet mungkin ya.
Luxury brands.
Kalau ini apa nih?
Dooms.
Ini orang-orang yang ini ya.
Konspirasi gitu ya.
Konspirasi.
Theoris.
Nuklir gitu ya.
Atau apa gitu.
Jadi dia cari supply.
Cari bunker.
Bunker.
Dan lain-lain.
Terakhir influencer.
Skincare.
Akologi.
Meditation.
Asik.
Jadi silahkan kalau ada yang mau mengacak informasinya mungkin sekarang sudah terlalu banyak di track ya.
Jadi bisa membuat bingung para site-site di luar sana.
Kadang berguna juga loh kalau kita kena target.
Karena apa yang kita lihat itu yang kita butuhkan juga.
Iya, ada penggunaan yang valid kayak itu tadi.
Cuma kalau pengelolaannya enggak ada pertanggung jawaban ya itu yang bisa bahaya kan.
Sama agregat sih kalau dijual ke tempat lain.
Nah itu tempat lainnya ngapain kan enggak tahu.
Tapi kalau sebentar-sebentar kita belanja.
Kita belanja online nih toko baju.
Dari sekian banyak baju kita ditawarin produk-produk yang emang sesuai sama usia, gaya, preferensi, sama jenis kelamin kita.
Ya udah kalau gitu doang sih.
Gak apa-apa helpful emang.
Gak enak juga ya kita sukanya misalnya gaming tapi ditawarin skincare.
Gak cocok ya.
Gaming sambil skincarean.
Nah ini ada pertanyaan lagi yang berhubungan sama Chrome extension.
Apakah, eh bukan, sorry salah.
Jadi pertanyaannya yang pertama tentang extension dan sekarang custom tabs.
Menginginkan Google juga.
Custom tabs itu apa?
Custom tabs itu apa? Coba Google-nya.
Custom tabs.
Chrome custom tabs.
Oh Android.
Itu web view ya, keliatannya maksudnya web view deh.
Harusnya ada, setiap web itu ada cookies masing-masing kan.
Benar gak sih? Termasuk juga soal web view.
Sama kayak bukan di inkon itu kayaknya deh.
Android ya.
Itu Androidnya semacam web view.
Selama masih dia web, pasti ada cookie API.
Cookie API, betul.
Ada tapi ya itu lagi-lagi yang tanpa flag HTTP only.
Tapi itu baru kan ya? Flag itu baru tuh.
Udah di-stable semua. Semua browser yang stable maksudnya.
Browser modern udah pasti support lah ya.
Oke, oke, oke.
Ada lagi yang mau disampaikan?
Udah dulu kayaknya deh.
Sudah dulu.
Sudah sejam kita bersama.
Siapa bersama?
Cookie aja bisa sejam ya. Cookie.
Oh iya.
Gimana kita ya? Ngomongin, soalnya kan ini ya.
Kayak tadi ya, contoh website Guardian itu.
Untuk menampilkan si cookie aja butuh effort yang luar biasa besar.
Kita harus nge-track kita pakai...
Saya ngerjain Cookie Concert itu kemarin sebulan lebih loh.
Sebulan?
Sebulan lebih sendiri itu Cookie Concert.
Dan harus mapping semua cookies yang dikirim.
Itu yang bikin mamah itu.
Sampai ngomong ke lawyer loh.
Dan nge-tracknya gimana?
Misalkan gini, misalkan awalnya kan kita pakai terparti service misalkan 5.
Tiba-tiba bulan depan kita nambahin 1.
Kita harus nambahin kan?
Iya, jadinya di workflow.
Harus ada extra di situ.
Kalau nggak, bisa kena denda company-nya.
Iya, makanya.
Kalau masalah sih 25.000 euro gitu.
Apa sesuatu? Saya nggak tahu.
Ada denda gitu.
Yang benar-benar sudah diregulasinya dijalankan adalah di Eropa ya, terutama ya.
Kalau nggak salah di Amerika juga ada ya?
Eropa dan negara bagian Kalifornia di Amerika.
Oh, di Amerika.
Kalau di Indonesia belum ada ya?
Jadi kalau Amerika kan, hal-hal US kan masing-masing negara bagian bisa bikin hukum sendiri ya.
Jadi nggak ada aturan di seluruh negara.
Iya, betul.
Indonesia belum ada.
Untungnya garis mereng sayangnya.
Untungnya sayangnya.
Mudah-mudahan segera lah ya.
Oke, kalau gitu.
Terima kasih banyak, teman-teman.
Kita udahan dulu malam hari ini.
Jangan lupa kalau ada...
Seperti biasa pertanyaan ya.
Kalau ada pertanyaan, ada topik yang mau didiskusikan di episode-episode pendatang, bisa ke bit.ly/ngobrolinweb.
Dan kalau begitu, kita pamit dulu.
Terima kasih banyak untuk malam hari ini.
Lumayan seru untuk topik tentang biskuit malam hari ini.
Tapi, ini ada pertanyaan menarik nih.
Saya nggak tahu.
Apa nggak tahu?
Isinya apa?
Saya nggak tahu banyak.
Tetapi UIT itu setau saya tidak ada mengatur tentang biskuit.
Nggak ada.
Data protection berarti belum ada ya?
Perlindungan data.
Ada, perlindungan data ada.
Cuman saya nggak tahu bagian mana.
Masalahnya ada.
Iya.
Nanti bikin episode UUIT, eh apa.
Kapan-kapan?
Nggak, kalau udah di...
Kita harus undang ahlinya.
Sudah.
Siapa ahlinya?
Gak tahu, kita cari dulu.
Kita cari dulu orang hukum.
Yang mau, yang mau ngomong bisik.
Oke, oke, oke. Siap, siap, siap.
Ya udah kalau begitu.
Terima kasih sekali lagi buat teman-teman yang sudah hadir,
yang sudah meramaikan malam hari ini.
Kita ketemu lagi hari selasa depan.
Jangan lupa kalau ada kritik saran dan bahan diskusi boleh ke bit.ly/ngobrolin.
Kita pamit.
Selamat malam. Sampai jumpa lagi minggu depan.
Bye.
Deskripsi asli dari YouTube
Yuk mari kita diskusi dan ngobrol ngalor-ngidul tentang dunia web. Agar tetap up-to-date dengan teknologi web terkini. Topik, tautan dan pertanyaan menarik bisa dilayangkan ke https://bit.ly/ngobrolinweb Kunjungi https://ngobrol.in untuk catatan, tautan dan informasi topik lainnya.
Episode Terkait
7 Feb 2023
Ngobrolin Metode Rendering
Salah satu permintaan topik paling awal akhirnya dibahas: kumpulan singkatan yang membingungkan seputar cara halaman web...
26 Jul 2023
Ngobrolin Web bersama Thomas Steiner ep43
Episode ini kedatangan Thomas Steiner, Developer Relations Engineer di tim Chrome yang sudah 15 tahun di Google, dan obr...
27 Jun 2023
Ngobrolin Bundler
Module bundler dibahas lewat sejarahnya, bukan daftar perkakasnya — dan pesan pembukanya bahwa hampir semua orang yang m...
Suka episode ini?
Episode baru setiap Selasa malam. Dengarkan lewat YouTube, Spotify, atau feed podcast favoritmu.
Memuat komentar dari GitHub Discussions...
Jika komentar tidak muncul karena ekstensi privasi / adblocker, kamu bisa berdiskusi langsung di GitHub Discussions .