Migration From V4
Koleksiyonlar ile düzeninizi koruyun
İçeriği tercihlerinize göre kaydedin ve kategorilere ayırın.
Google Güvenli Tarama v5'in v4'e (özellikle v4 Güncelleme API'si) kıyasla önemli bir iyileştirmesi, verilerin güncelliği ve kapsamıdır. Koruma büyük ölçüde istemci tarafından tutulan yerel veritabanına bağlı olduğundan, yerel veritabanı güncellemesinin gecikmesi ve boyutu, korumanın kaçırılmasının temel nedenidir. v4'te, istemcinin tehdit listelerinin en güncel sürümünü alması genellikle 20 ila 50 dakika sürer. Maalesef kimlik avı saldırıları hızla yayılıyor. 2021 itibarıyla, saldırı gerçekleştiren sitelerin% 60'ı 10 dakikadan kısa süre içinde yayılıyor. Analizimiz, eksik kimlik avı korumasının yaklaşık% 25-30'unun bu tür veri eskimesinden kaynaklandığını gösteriyor. Ayrıca, bazı cihazlar Google Güvenli Tarama tehdit listelerinin tamamını yönetebilecek donanıma sahip değildir. Bu listeler zaman içinde büyümeye devam etmektedir.
Şu anda v4 Update API'yi kullanıyorsanız yerel veritabanını sıfırlamanız veya silmeniz gerekmeden v4'ten v5'e sorunsuz bir şekilde geçiş yapabilirsiniz. Bu bölümde, bu işlemin nasıl yapılacağı açıklanmaktadır.
Dönüştürme Listesi Güncellemeleri
Listelerin tehdit türü, platform türü ve tehdit girişi türü üçlüsüyle tanımlandığı V4'ten farklı olarak, V5'te listeler yalnızca adla tanımlanır. Bu, birden fazla v5 listesinin aynı tehdit türünü paylaşabileceği durumlarda esneklik sağlar. Platform türleri ve tehdit girişi türleri v5'te kaldırıldı.
v4'te listeleri indirmek için threatListUpdates.fetch yöntemi kullanılır. V5'te hashLists.batchGet yöntemine geçilir.
İstek üzerinde aşağıdaki değişiklikler yapılmalıdır:
- v4
ClientInfo nesnesini tamamen kaldırın. İstemcinin kimliğini özel bir alan kullanarak sağlamak yerine, iyi bilinen User-Agent üst bilgisini kullanmanız yeterlidir. Bu başlıkta istemci tanımlamasının sağlanması için belirlenmiş bir biçim olmasa da orijinal istemci kimliğini ve istemci sürümünü boşluk karakteri veya eğik çizgi karakteriyle ayırarak eklemenizi öneririz.
- Her v4
ListUpdateRequest nesnesi için:
- Kullanılabilir listelerden ilgili v5 liste adını bulun ve bu adı v5 isteğinde belirtin.
threat_entry_type veya platform_type gibi gereksiz alanları kaldırın.- V4'teki
state alanı, V5'teki versions alanı ile doğrudan uyumludur. v4'te state alanı kullanılarak sunucuya gönderilen aynı bayt dizesi, v5'te versions alanı kullanılarak kolayca gönderilebilir.
- V5, v4 kısıtlamaları için
SizeConstraints adlı basitleştirilmiş bir sürümü kullanır. region gibi ek alanlar bırakılmalıdır.
Yanıt aşağıdaki şekilde değiştirilmelidir:
- V4 enum
ResponseType, partial_update adlı bir boolean alanıyla değiştirilir.
minimum_wait_duration alanı artık sıfır olabilir veya atlanabilir. Bu durumda, istemciden hemen başka bir istekte bulunması istenir. Bu durum yalnızca istemci, SizeConstraints içinde maksimum veritabanı boyutundan daha küçük bir maksimum güncelleme boyutu kısıtlaması belirttiğinde meydana gelir.- 32 bit tam sayılar için Rice kod çözme algoritmasının ayarlanması gerekir. Aradaki fark, kodlanmış verilerin farklı bir endianness ile kodlanmış olmasıdır. Hem v4 hem de v5'te 32 bit karma önekleri sözlük sırasına göre sıralanır. Ancak v4'te bu önekler sıralandığında little endian olarak kabul edilirken v5'te sıralandığında big endian olarak kabul edilir. Bu, sözlükbilimsel sıralama, büyük endian ile sayısal sıralamayla aynı olduğundan istemcinin herhangi bir sıralama yapması gerekmediği anlamına gelir. v4'ün Chromium uygulamasında bu tür bir örneği burada bulabilirsiniz. Bu tür sıralamalar kaldırılabilir.
- Rice kod çözme algoritması, diğer karma uzunlukları için de uygulanmalıdır.
Karma Arama Dönüştürme
v4'te tam karma oluşturmak için fullHashes.find yöntemi kullanılırdı. v5'teki eşdeğer yöntem the hashes.search method'dur.
İstek üzerinde aşağıdaki değişiklikler yapılmalıdır:
- Kodu, yalnızca tam olarak 4 bayt uzunluğunda olan karma öneklerini gönderecek şekilde yapılandırın.
- v4
ClientInfo nesnelerini tamamen kaldırın. İstemcinin kimliğini özel bir alan kullanarak sağlamak yerine, iyi bilinen User-Agent üst bilgisini kullanmanız yeterlidir. Bu başlıkta istemci tanımlamasının sağlanması için belirlenmiş bir biçim olmasa da orijinal istemci kimliğini ve istemci sürümünü boşluk karakteri veya eğik çizgi karakteriyle ayırarak eklemenizi öneririz.
client_states alanını kaldırın. Artık gerekli değil.- Artık
threat_types ve benzer alanları eklemeniz gerekmez.
Yanıt aşağıdaki şekilde değiştirilmelidir:
minimum_wait_duration alanı kaldırıldı. İstemci, gerektiğinde her zaman yeni bir istek gönderebilir.- v4
ThreatMatch nesnesi, FullHash nesnesi olarak basitleştirildi.
- Önbelleğe alma işlemi tek bir önbellek süresiyle basitleştirildi. Önbellekle etkileşim kurma prosedürlerini yukarıda bulabilirsiniz.
Aksi belirtilmediği sürece bu sayfanın içeriği Creative Commons Atıf 4.0 Lisansı altında ve kod örnekleri Apache 2.0 Lisansı altında lisanslanmıştır. Ayrıntılı bilgi için Google Developers Site Politikaları'na göz atın. Java, Oracle ve/veya satış ortaklarının tescilli ticari markasıdır.
Son güncelleme tarihi: 2025-08-10 UTC.
[null,null,["Son güncelleme tarihi: 2025-08-10 UTC."],[],[],null,["# Migration From V4\n\nOne significant improvement of Google Safe Browsing v5 over v4 (specifically, [the v4 Update API](/safe-browsing/v4/update-api)) is data freshness and coverage. Since the protection highly depends on the client-maintained local database, the delay and size of the local database update is the main contributor of the missed protection. In v4, the typical client takes 20 to 50 minutes to obtain the most up-to-date version of threat lists. Unfortunately, phishing attacks spread fast: as of 2021, 60% of sites that deliver attacks live less than 10 minutes. Our analysis shows that around 25-30% of missing phishing protection is due to such data staleness. Further, some devices are not equipped to manage the entirety of the Google Safe Browsing threat lists, which continues to grow larger over time.\n\nIf you are currently using the [v4 Update API](/safe-browsing/v4/update-api), there is a seamless migration path from v4 to v5 without having to reset or erase the local database. This section documents how to do that.\n\n### Converting List Updates\n\nUnlike V4, where lists are identified by the tuple of threat type, platform type, threat entry type, in v5 lists are simply identified by name. This provides flexibility when multiple v5 lists could share the same threat type. Platform types and threat entry types are removed in v5.\n\nIn v4, one would use the [threatListUpdates.fetch method](/safe-browsing/reference/rest/v4/threatListUpdates/fetch) to download lists. In v5, one would switch to the [hashLists.batchGet method](/safe-browsing/reference/rest/v5/hashLists/batchGet).\n\nThe following changes should be made to the request:\n\n1. Remove the [v4 `ClientInfo` object](/safe-browsing/reference/rest/v4/ClientInfo) altogether. Instead of supplying a client's identification using a dedicated field, simply use the well-known [User-Agent header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent). While there is no prescribed format for supplying the client identification in this header, we suggest simply including the original client ID and client version separated by a space character or a slash character.\n2. For each [v4 `ListUpdateRequest` object](/safe-browsing/reference/rest/v4/threatListUpdates/fetch#listupdaterequest):\n - Look up the corresponding v5 list name from the [available lists](/safe-browsing/reference/Local.Database#available-lists) and supply that name in the v5 request.\n - Remove unneeded fields such as `threat_entry_type` or `platform_type`.\n - The `state` field in v4 is directly compatible with the v5 `versions` field. The same byte string that would be sent to the server using the `state` field in v4 can simply be sent in v5 using the `versions` field.\n - For the v4 constraints, v5 uses a simplified version called [`SizeConstraints`](/safe-browsing/reference/rest/v5/SizeConstraints). Additional fields such as `region` should be dropped.\n\nThe following changes should be made to the response:\n\n1. The v4 [enum `ResponseType`](/safe-browsing/reference/rest/v4/threatListUpdates/fetch#ResponseType) is simply replaced by a boolean field named `partial_update`.\n2. The `minimum_wait_duration` field can now be zero or omitted. If it is, the client is requested to immediately make another request. This only happens when the client specifies in `SizeConstraints` a smaller constraint on max update size than the max database size.\n3. The Rice decoding algorithm for 32-bit integers will need to be adjusted. The difference is that the encoded data are encoded with a different endianness. In both v4 and v5, 32-bit hash prefixes are sorted lexicographically. But in v4, those prefixes are treated as little endian when sorted, whereas in v5 those prefixes are treated as big endian when sorted. This means that the client does not need to do any sorting, since lexicographic sorting is identical to numeric sorting with big endian. An example of this sort in the Chromium implementation of v4 can be found [here](https://source.chromium.org/chromium/chromium/src/+/main:components/safe_browsing/core/browser/db/v4_rice.cc;l=144-146;drc=8ba1bad80dc22235693a0dd41fe55c0fd2dbdabd). Such sorting can be removed.\n4. The Rice decoding algorithm will need to be implemented for other hash lengths as well.\n\n### Converting Hash Searches\n\nIn v4, one would use the [fullHashes.find method](/safe-browsing/reference/rest/v4/fullHashes/find) to get full hashes. The equivalent method in v5 is [the hashes.search method](/safe-browsing/reference/rest/v5/hashes/search).\n\nThe following changes should be made to the request:\n\n1. Structure the code to only send hash prefixes that are exactly 4 bytes in length.\n2. Remove the [v4 `ClientInfo` objects](/safe-browsing/reference/rest/v4/ClientInfo) altogether. Instead of supplying a client's identification using a dedicated field, simply use the well-known [User-Agent header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent). While there is no prescribed format for supplying the client identification in this header, we suggest simply including the original client ID and client version separated by a space character or a slash character.\n3. Remove the `client_states` field. It is no longer necessary.\n4. It is no longer needed to include `threat_types` and similar fields.\n\nThe following changes should be made to the response:\n\n1. The `minimum_wait_duration` field has been removed. The client can always issue a new request on an as-needed basis.\n2. The [v4 `ThreatMatch` object](/safe-browsing/reference/rest/v4/ThreatMatch) has been simplified into the [`FullHash`](/safe-browsing/reference/rest/v5/hashes/search#FullHash) object.\n3. Caching has been simplified into a single cache duration. See the above procedures for interacting with the cache."]]
