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 kontributor utama perlindungan yang terlewatkan. Di v4, klien umum 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 hanya aktif kurang dari 10 menit. Analisis kami menunjukkan bahwa sekitar 25-30% perlindungan phishing yang hilang disebabkan oleh kedaluwarsa data tersebut. 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.

Memperbarui 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 ListUpdateRequest v4: * Cari nama daftar v5 yang sesuai dari daftar yang tersedia 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. Logika untuk mendekode hash yang dienkode Rice-Golomb memerlukan dua penyesuaian utama:
    • Endianness dan Pengurutan: Di v4, hash yang ditampilkan diurutkan sebagai nilai little-endian. Di v5, nilai ini diperlakukan sebagai nilai big-endian. Karena pengurutan leksikografis string byte setara dengan pengurutan numerik nilai big-endian, klien tidak perlu lagi melakukan langkah pengurutan khusus. Pengurutan little-endian kustom, seperti yang ada di implementasi Chromium v4, dapat dihapus jika sebelumnya diterapkan.
    • Panjang Hash Variabel: Algoritma decoding harus diupdate untuk mendukung berbagai panjang hash yang dapat ditampilkan di kolom HashList.compressed_additions, bukan hanya panjang hash empat byte yang digunakan di v4. Panjang hash yang ditampilkan dalam respons dapat ditentukan berdasarkan HashList.metadata.hash_length yang ditampilkan dari hashLists.list. Atau, penamaan daftar hash yang diminta juga menandakan ukuran hash yang diharapkan ditampilkan dari daftar. Lihat halaman Database Lokal untuk mengetahui detail selengkapnya tentang daftar hash.

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.