Petunjuk dan ruang lingkup
Perusahaan mengoperasikan aplikasi web, klien seluler, analitik, dan integrasi iklan. Sistem harus mematuhi sinyal Global Privacy Control tingkat browser, pilihan eksplisit pengguna, dan aturan yurisdiksi yang terus berubah. Rancang control plane dan jalur penegakan saat waktu permintaan (request-time), termasuk pengunjung anonim, pengguna yang masuk, banyak perangkat, mitra, dan pembaruan kebijakan.
Keterampilan intinya adalah penegakan kebijakan terdistribusi dan pemodelan status privasi, sehingga topik ini termasuk dalam system-design.
Hal yang dinilai oleh pewawancara
Pertama, dapatkah Anda memisahkan sinyal dari keputusan hukum? Header atau properti browser Sec-GPC hanyalah sebuah input; keberlakuan dan pemrosesan yang diizinkan berasal dari kebijakan dan konteks.
Kedua, dapatkah Anda menentukan preseden dan ruang lingkup (scope)? Penghentian langganan global (global opt-out) dapat berlaku untuk browser, akun, rumah tangga, atau yurisdiksi berdasarkan aturan yang berbeda. Sistem harus menghindari penggabungan scope secara diam-diam.
Ketiga, dapatkah Anda melakukan penegakan sebelum data keluar dari batasan sistem? Analitik, ad-tech, ekspor, dan API mitra memerlukan titik keputusan bersama, bukan hanya banner.
Keempat, dapatkah Anda membuat keputusan yang dapat dijelaskan dan dapat dicabut? Simpan versi kebijakan, sumber, stempel waktu, dan masa kedaluwarsa, sekaligus meminimalkan data pribadi dan mendukung penarikan persetujuan di kemudian hari.
Kelima, dapatkah sistem mengalami kegagalan dengan aman (fail safely)? Pemadaman policy-store, cache yang usang, atau yurisdiksi yang tidak dikenal harus secara default beralih ke mode pembagian yang paling tidak permisif dan memancarkan alasan yang dapat diamati.
Pertanyaan untuk diklarifikasi terlebih dahulu
- Yurisdiksi dan tujuan mana saja yang masuk dalam cakupan, dan aturan mana yang bersifat otoritatif?
- Apakah sinyal GPC berlaku untuk akun setelah login atau hanya untuk konteks browser?
- Tujuan mana saja yang diblokir: penjualan, pembagian, iklan bertarget, pengukuran, atau semua pemrosesan opsional?
- Seberapa cepat pencabutan harus mencapai cache, antrean, data warehouse, dan mitra?
- Bukti apa yang harus disimpan, dan data apa yang harus dihapus atau dianonimkan?
- Bisakah setiap integrasi keluar memanggil layanan keputusan kebijakan yang sama?
Kerangka jawaban 30 detik
“Saya akan menormalisasi sinyal browser dan pilihan eksplisit menjadi niat privasi berversi, lalu mengevaluasinya dengan kebijakan yurisdiksi dan tujuan di setiap batasan data-egress. Keputusan tersebut mencakup scope, versi kebijakan, masa kedaluwarsa, dan alasan, serta di-cache secara singkat dengan perilaku fail-closed untuk pembagian opsional. Event mempropagasi pencabutan ke antrean dan mitra, sementara jejak audit append-only menyimpan bukti minimal. Saya akan menguji transisi anonim-ke-login, scope yang berkonflik, perubahan kebijakan, keusangan cache, dan kegagalan mitra.”
Jawaban langkah demi langkah
Langkah 1: Normalisasi input tanpa identifikasi berlebihan
Di edge, tangkap sinyal GPC, origin, konteks user agent, status akun, dan wilayah yang dideklarasikan. Pisahkan pengidentifikasi browser anonim dari pengidentifikasi akun hingga kebijakan mengizinkan penautan. Normalisasi pilihan eksplisit ke dalam tujuan seperti penjualan, pembagian, pengukuran, dan personalisasi.
Langkah 2: Evaluasi kebijakan berversi
Layanan kebijakan menerima subject scope, tujuan, yurisdiksi, sinyal sumber, dan waktu. Layanan ini mengembalikan allow, deny, atau unknown, ditambah versi kebijakan, masa kedaluwarsa, dan kode alasan. Sinyal GPC itu sendiri bukan bukti bahwa setiap tujuan dilarang di semua tempat; evaluator menerapkan rangkaian aturan yang relevan.
Langkah 3: Tegakkan di setiap egress
Wajibkan token keputusan sebelum mengirimkan event ke analitik, ad-tech, ekspor, atau API mitra. SDK dapat mengurangi pengumpulan yang tidak disengaja, namun server harus menegakkannya karena klien dapat dimodifikasi. Antrean dan batch job memeriksa ulang keputusan sebelum pengiriman, bukan hanya saat waktu enqueue.
Langkah 4: Propagasi perubahan dan pencabutan
Publikasikan event niat privasi yang diberi kunci referensi subjek dengan scope tertentu. Konsumen membatalkan validitas cache, menghentikan ekspor di masa mendatang, dan menandai data yang disimpan untuk alur kerja penghapusan atau supresi yang berlaku. Mitra menerima kontrak minimal dengan tujuan, scope, waktu efektif, dan data verifikasi; jangan menyiarkan identitas mentah jika token sudah cukup.
Langkah 5: Audit keputusan, bukan payload
Catat kelas permintaan, hash scope subjek, tujuan, versi kebijakan, sumber sinyal, keputusan, dan stempel waktu. Enkripsi akses, batasi retensi, dan pisahkan log operasional dari penjelasan yang dapat dilihat pengguna. Catatan audit harus dapat menjawab mengapa suatu transfer diizinkan atau ditolak tanpa menyalin konten event yang sensitif.
Langkah 6: Gunakan fail-closed dan observasi
Jika pencarian kebijakan atau propagasi pencabutan gagal, blokir pembagian opsional dan antrekan tugas untuk dicoba kembali. Metrik harus menunjukkan keputusan yang tidak dikenal, versi kebijakan yang usang, transfer yang ditolak, konfirmasi penerimaan dari mitra, dan waktu hingga pencabutan (time-to-revocation). Peringatan harus membedakan gangguan kebijakan dari peningkatan opt-out yang sah.
Langkah 7: Uji batasan dan kasus adversarial
Uji penelusuran anonim yang diikuti dengan login, banyak tab, konflik scope antara akun dan browser, pergeseran waktu (clock skew), perpindahan wilayah, sinyal replay, kedaluwarsa cache, pengiriman ulang antrean, batas waktu mitra (partner timeout), dan rollback kebijakan. Verifikasi bahwa keputusan penolakan tidak dapat dilewati melalui jalur ekspor alternatif.
Contoh jawaban model
“Saya akan membangun layanan keputusan privasi berversi dan mewajibkan token keputusan berumur pendek di setiap batasan data-egress opsional. Edge menormalisasi GPC dan pilihan eksplisit sambil menjaga scope browser dan akun tetap terpisah. Evaluasi kebijakan menggabungkan tujuan, yurisdiksi, sumber, dan waktu efektif; ini menghasilkan alasan dan versi kebijakan. Antrean dan mitra memeriksa ulang sebelum pengiriman, dan event pencabutan membatalkan validitas cache serta memicu alur kerja supresi.
Layanan ini menerapkan fail-closed untuk pembagian opsional, mencatat bukti keputusan minimal, dan mengekspos metrik untuk keputusan yang tidak dikenal, cache yang usang, konfirmasi penerimaan, dan waktu hingga pencabutan. Pengujian mencakup transisi login, konflik scope, replay, perubahan wilayah, percobaan ulang, dan jalur ekspor alternatif. Banner saja bukanlah penegakan.”
Kesalahan umum
- Memperlakukan GPC sebagai nilai boolean universal → scope dan yurisdiksi hilang → evaluasi sinyal, tujuan, dan kebijakan secara bersamaan.
- Menegakkan hanya di browser → klien yang dimodifikasi dapat melewati kontrol → tegakkan pada egress server.
- Menautkan identitas anonim dan akun secara langsung → pembuatan profil yang tidak perlu → pisahkan scope sampai ada justifikasi.
- Memeriksa persetujuan hanya pada saat enqueue → terjadi race condition antara pencabutan dan pengiriman → periksa ulang sebelum pengiriman.
- Menerapkan fail-open saat pemadaman kebijakan → data opsional bocor → terapkan fail-closed dan coba lagi.
- Mengaudit muatan (payload) lengkap → log menjadi risiko privasi → simpan bukti keputusan minimal.
- Mengabaikan konfirmasi mitra → propagasi tidak terverifikasi → lacak tanda terima dan tenggat waktu.
Pertanyaan lanjutan
Pertanyaan lanjutan 1: Apakah GPC menggantikan banner persetujuan?
Tidak. Ini adalah sinyal tingkat browser yang maknanya bergantung pada kebijakan yang berlaku. Antarmuka pengguna dapat mengumpulkan pilihan tambahan, namun penegakan harus mematuhi keputusan yang telah dievaluasi.
Pertanyaan lanjutan 2: Apa yang terjadi setelah login?
Biarkan scope browser dan akun tetap terpisah, lalu terapkan aturan penautan yang terdokumentasi. Jangan secara diam-diam mengubah sinyal anonim menjadi preferensi akun yang lebih luas tanpa dukungan kebijakan.
Pertanyaan lanjutan 3: Berapa lama keputusan boleh di-cache?
Hanya selama risiko dan kebijakan mengizinkan. Gunakan TTL yang singkat, pembatalan validitas berversi, dan perilaku fail-closed saat kesegaran data tidak dapat dibuktikan.
Pertanyaan lanjutan 4: Bagaimana cara menangani mitra yang sedang offline?
Hentikan pengiriman opsional setelah tenggat waktu konfirmasi, simpan catatan percobaan ulang minimal, dan lakukan rekonsiliasi setelah mitra kembali online.
Pertanyaan lanjutan 5: Apa yang harus dimuat dalam catatan audit?
Referensi scope, tujuan, sumber sinyal, versi kebijakan, keputusan, alasan, dan waktu biasanya sudah cukup; hindari menyalin payload event.
Pertanyaan lanjutan 6: Bagaimana cara membuktikan bahwa tidak ada bypass?
Inventarisasi setiap jalur egress, wajibkan token keputusan di middleware bersama, dan jalankan uji penolakan terhadap SDK, batch job, ekspor, dan percobaan ulang mitra.