Migration From V4

Salah satu peningkatan signifikan Google Safe Browsing v5 dibandingkan v4 (khususnya, Update API v4) adalah keaktualan dan cakupan data. Karena perlindungan sangat bergantung pada database lokal yang dikelola klien, penundaan dan ukuran update database lokal adalah penyebab utama perlindungan yang terlewatkan. Di v4, klien biasanya memerlukan waktu 20 hingga 50 menit untuk mendapatkan versi terbaru daftar ancaman. Sayangnya, serangan phishing menyebar dengan cepat: pada tahun 2021, 60% situs yang melancarkan serangan aktif kurang dari 10 menit. Analisis kami menunjukkan bahwa sekitar 25-30% perlindungan phishing yang hilang disebabkan oleh data yang sudah tidak berlaku. Selain itu, beberapa perangkat tidak dilengkapi untuk mengelola seluruh daftar ancaman Google Safe Browsing, yang terus bertambah besar dari waktu ke waktu.

Jika saat ini Anda menggunakan Update API v4, ada jalur migrasi yang lancar dari v4 ke v5 tanpa harus mereset atau menghapus database lokal. Bagian ini mendokumentasikan cara melakukannya.

Pembaruan Daftar Konversi

Tidak seperti V4, yang mengidentifikasi daftar berdasarkan tuple jenis ancaman, jenis platform, jenis entri ancaman, di v5 daftar diidentifikasi hanya berdasarkan nama. Hal ini memberikan fleksibilitas saat beberapa daftar v5 dapat berbagi jenis ancaman yang sama. Jenis platform dan jenis entri ancaman dihapus di v5.

Di v4, pengguna akan menggunakan threatListUpdates.fetch method untuk mendownload daftar. Di v5, Anda dapat beralih ke hashLists.batchGet method.

Perubahan berikut harus dilakukan pada permintaan:

  1. Hapus objek v4 ClientInfo sepenuhnya. Daripada memberikan identifikasi klien menggunakan kolom khusus, cukup gunakan header User-Agent yang sudah dikenal. Meskipun tidak ada format yang ditentukan untuk memberikan identifikasi klien di header ini, sebaiknya cukup sertakan ID klien dan versi klien asli yang dipisahkan oleh karakter spasi atau karakter garis miring.
  2. Untuk setiap objek v4 ListUpdateRequest:
    • Cari nama daftar v5 yang sesuai dari available lists dan berikan nama tersebut dalam permintaan v5.
    • Hapus kolom yang tidak diperlukan seperti threat_entry_type atau platform_type.
    • Kolom state di v4 kompatibel langsung dengan kolom versions v5. String byte yang sama yang akan dikirim ke server menggunakan kolom state di v4 dapat dikirim di v5 menggunakan kolom versions.
    • Untuk batasan v4, v5 menggunakan versi sederhana yang disebut SizeConstraints. Kolom tambahan seperti region harus dihapus.

Perubahan berikut harus dilakukan pada respons:

  1. enum ResponseType v4 diganti dengan kolom boolean bernama partial_update.
  2. Kolom minimum_wait_duration sekarang dapat berupa nol atau dihilangkan. Jika ya, klien diminta untuk segera membuat permintaan lain. Hal ini hanya terjadi jika klien menentukan batasan yang lebih kecil pada ukuran update maksimum daripada ukuran database maksimum di SizeConstraints.
  3. Algoritma decoding Rice untuk bilangan bulat 32-bit perlu disesuaikan. Perbedaannya adalah data yang dienkode dienkode dengan endianness yang berbeda. Di v4 dan v5, awalan hash 32-bit diurutkan secara leksikografis. Namun, di v4, awalan tersebut diperlakukan sebagai little endian saat diurutkan, sedangkan di v5, awalan tersebut diperlakukan sebagai big endian saat diurutkan. Artinya, klien tidak perlu melakukan pengurutan apa pun, karena pengurutan leksikografis identik dengan pengurutan numerik dengan big endian. Contoh jenis ini dalam penerapan v4 di Chromium dapat ditemukan di sini. Pengurutan tersebut dapat dihapus.
  4. Algoritma decoding Rice juga perlu diterapkan untuk panjang hash lainnya.

Mengonversi Penelusuran Hash

Di v4, orang akan menggunakan metode fullHashes.find untuk mendapatkan hash lengkap. Metode yang setara di v5 adalah metode hashes.search.

Perubahan berikut harus dilakukan pada permintaan:

  1. Strukturkan kode untuk hanya mengirimkan awalan hash yang panjangnya tepat 4 byte.
  2. Hapus objek v4 ClientInfo sepenuhnya. Daripada memberikan identifikasi klien menggunakan kolom khusus, cukup gunakan header User-Agent yang sudah dikenal. Meskipun tidak ada format yang ditentukan untuk memberikan identifikasi klien di header ini, sebaiknya cukup sertakan ID klien dan versi klien asli yang dipisahkan oleh karakter spasi atau karakter garis miring.
  3. Hapus kolom client_states. Fungsi tersebut tidak diperlukan lagi.
  4. Tidak perlu lagi menyertakan threat_types dan kolom serupa.

Perubahan berikut harus dilakukan pada respons:

  1. Kolom minimum_wait_duration telah dihapus. Klien selalu dapat mengeluarkan permintaan baru sesuai kebutuhan.
  2. Objek v4 ThreatMatch telah disederhanakan menjadi objek FullHash.
  3. Penyimpanan dalam cache telah disederhanakan menjadi durasi cache tunggal. Lihat prosedur di atas untuk berinteraksi dengan cache.