Local Database
Koleksiyonlar ile düzeninizi koruyun
İçeriği tercihlerinize göre kaydedin ve kategorilere ayırın.
Google Güvenli Tarama v5, istemci Depolama Alanı Olmayan Gerçek Zamanlı Mod'u seçmediği sürece istemcinin yerel bir veritabanı tutmasını bekler. Bu yerel veritabanının biçimi ve depolaması istemciye bağlıdır. Bu yerel veritabanının içeriği, kavramsal olarak dosya olarak çeşitli listeler içeren bir klasör olarak düşünülebilir. Bu dosyaların içeriği SHA256 karmaları veya en yaygın olarak kullanılan karma uzunluğu olan dört baytlık karma önekine sahip karşılık gelen ön ekleridir.
Kullanılabilir Listeler
Listeler, farklı adlarıyla tanımlanır. Bu adlar, adında listede görmeyi beklediğiniz karma değerin uzunluğunu belirten bir son ek içeren bir adlandırma kuralına uyar. Aynı tehdit türüne sahip ancak farklı karma uzunluğuna sahip karma listeleri, karma uzunluğunu belirten bir son ek ile niteliklendirilmiş ayrı bir ada sahip liste olur.
Aşağıdaki listeler, karma liste yöntemleriyle kullanılabilir.
| Liste Adı |
İlgili v4 ThreatType Enum |
Açıklama |
gc-32b |
Yok |
Bu liste, küresel önbelleğe alma listesidir. Yalnızca gerçek zamanlı çalışma modunda kullanılan özel bir listetir. |
se-4b |
SOCIAL_ENGINEERING |
Bu liste, SOCIAL_ENGINEERING tehdit türündeki tehditleri içerir. |
mw-4b |
MALWARE |
Bu liste, masaüstü platformları için KÖTÜ AMAÇLI YAZILIM tehdit türündeki tehditleri içerir. |
uws-4b |
UNWANTED_SOFTWARE |
Bu liste, masaüstü platformları için UNWANTED_SOFTWARE tehdit türündeki tehditleri içerir. |
uwsa-4b |
UNWANTED_SOFTWARE |
Bu liste, Android platformları için UNWANTED_SOFTWARE tehdit türündeki tehditleri içerir. |
pha-4b |
POTENTIALLY_HARMFUL_APPLICATION |
Bu listede, Android platformları için POTENTIALLY_HARMFUL_APPLICATION tehdit türündeki tehditler yer alır. |
Daha sonra ek listeler kullanıma sunulabilir. Bu durumda yukarıdaki tablo genişletilir ve hashList.list yönteminin sonuçları, en güncel listelerle benzer bir sonuç gösterir.
Veritabanı Güncellemeleri
İstemci, veritabanını güncellemek için düzenli olarak hashList.get yöntemini veya hashLists.batchGet yöntemini çağırır. Tipik bir istemci aynı anda birden fazla listeyi güncellemek isteyeceğinden hashLists.batchGet yönteminin kullanılması önerilir.
Liste adları hiçbir zaman yeniden adlandırılmaz. Ayrıca, bir liste bir kez gösterilmeye başladıktan sonra hiçbir zaman kaldırılmaz (liste artık yararlı değilse boş olur ancak var olmaya devam eder). Bu nedenle, bu adları Google Güvenli Tarama istemci koduna sabit kodlamak uygundur.
Hem hashList.get yöntemi hem de hashLists.batchGet yöntemi artımlı güncellemeleri destekler. Artımlı güncellemeleri kullanmak bant genişliğinden tasarruf sağlar ve performansı artırır. Artımlı güncellemeler, istemcinin liste sürümü ile listenin en son sürümü arasında bir fark sunarak çalışır. (Yeni dağıtılan ve mevcut sürümü olmayan istemciler için tam güncelleme kullanılabilir.) Artımlı güncelleme, kaldırma dizinlerini ve eklemeleri içerir. İstemcinin önce belirtilen dizinlerdeki girişleri yerel veritabanından kaldırması, ardından eklemeleri uygulaması beklenir.
Son olarak, bozulmayı önlemek için istemcinin, depolanan verileri sunucu tarafından sağlanan sağlama toplamıyla kontrol etmesi gerekir. Kontrol toplamı eşleşmediğinde istemci tam güncelleme yapmalıdır.
Liste içeriğinin kodunu çözme
Karma ve karma ön eklerinin kodunu çözme
Tüm listeler, boyutu azaltmak için özel bir kodlama kullanılarak yayınlanır. Bu kodlama, Google Güvenli Tarama listelerinin kavramsal olarak, istatistiksel olarak rastgele tam sayılardan ayırt edilemeyecek bir karma oluşturma veya karma oluşturma ön eklerinden oluşan bir grup içerdiğini kabul ederek çalışır. Bu tam sayıları sıralar ve bitişik farklarını alırsak bu bitişik farkın bir anlamda "küçük" olması beklenir. Golomb-Rice kodlaması bu küçüklükten yararlanır.
a.example.com/, b.example.com/ ve y.example.com/ olmak üzere üç ana makine soneki yol ön ek ifadesi 4 baytlık karma ön ek kullanılarak iletileceğini varsayalım. Ayrıca, k ile gösterilen Rice parametresinin şu şekilde seçildiğini varsayalım:
- Sunucu, sırasıyla aşağıdakiler olan bu dizelerin tam karmasını hesaplamaya başlar:
291bc5421f1cd54d99afcc55d166e2b9fe42447025895bf09dd41b2110a687dc a.example.com/
1d32c5084a360e58f1b87109637a6810acad97a861a7769e8f1841410d2a960c b.example.com/
f7a502e56e8b01c6dc242b35122683c9d25d07fb1f532d9853eb0ef3ff334f03 y.example.com/
Ardından sunucu, yukarıdakilerin her biri için 4 baytlık karma ön ekleri oluşturur. Bu ön ekler, büyük endian 32 bit tam sayılar olarak yorumlanan 32 baytlık tam karmanın ilk 4 baytıdır. Büyük endian, tam karmanın ilk baytının 32 bitlik tam sayının en anlamlı baytı haline gelmesini ifade eder. Bu adım, 0x291bc542, 0x1d32c508 ve 0xf7a502e5 tam sayılarıyla sonuçlanır.
Sunucunun bu üç karma ön ekini alfabetik olarak sıralaması gerekir (büyük endian'da sayısal sıralamaya eşdeğerdir). Sıralama sonucu 0x1d32c508, 0x291bc542, 0xf7a502e5 olur. İlk karma ön ek, first_value alanında değiştirilmeden saklanır.
Ardından sunucu, sırasıyla 0xbe9003a ve 0xce893da3 olan iki bitişik farkı hesaplar. k'nın 30 olarak seçildiği varsayıldığında sunucu bu iki sayıyı sırasıyla 2 ve 30 bit uzunluğunda olan kesir ve kalan bölümlerine ayırır. İlk sayı için bölme bölümü sıfır, kalan ise 0xbe9003a'dır. İkinci sayı için bölme bölümü 3'tür çünkü en önemli iki bit ikili sistemde 11'dir ve kalan 0xe893da3'tür. Belirli bir bölme q, tam olarak 1 + q bit kullanılarak (1 << q) - 1 olarak kodlanır; kalan ise doğrudan k bit kullanılarak kodlanır. İlk sayının bölme bölümü 0 olarak kodlanır ve kalan bölümü ikili sistemde 001011111010010000000000111010 şeklindedir; ikinci sayının bölme bölümü 0111 olarak kodlanır ve kalan bölümü 001110100010010011110110100011 şeklindedir.
Bu sayılar bir bayt dizesi olarak oluşturulduğunda küçük endian kullanılır. Kavramsal olarak, en az anlamlı bitlerden başlayarak oluşturulan uzun bir bit dizesi hayal etmek daha kolay olabilir: İlk sayının bölümüne, kalan kısmını ekliyoruz. Ardından ikinci sayının bölümüne, kalan kısmını ekliyoruz. Bu işlem, aşağıdaki büyük sayıya yol açar (netlik için satır sonları ve yorumlar eklenmiştir):
001110100010010011110110100011 # Second number, remainder part
0111 # Second number, quotient part
001011111010010000000000111010 # First number, remainder part
0 # First number, quotient part
Tek bir satırda yazılırsa bu
00111010001001001111011010001101110010111110100100000000001110100
Bu sayı, tek bir bayttaki 8 biti çok aşar. Ardından küçük endian kodlaması, bu sayının en az anlamlı 8 bitini alır ve ilk bayt olarak 01110100 olarak gösterir. Daha net bir şekilde açıklamak gerekirse, yukarıdaki bit dizesini en az anlamlı bitlerden başlayarak sekizli gruplar halinde toplayabiliriz:
0 01110100 01001001 11101101 00011011 10010111 11010010 00000000 01110100
Ardından küçük endian kodlaması, her baytı sağdan alır ve bir bayt dizesine yerleştirir:
01110100
00000000
11010010
10010111
00011011
11101101
01001001
01110100
00000000
Kavramsal olarak soldaki büyük sayıya yeni parçalar eklediğimizde (yani daha fazla önemli bit ekleyerek) ancak sağdan kodladığımızda (yani en az önemli bitler) kodlama ve kod çözme işleminin artımlı olarak gerçekleştirilebileceği görülebilir.
Bu durum,
additions_four_bytes {
first_value: 489866504
rice_parameter: 30
entries_count: 2
encoded_data: "t\000\322\227\033\355It\000"
}
İstemci, karma ön eklerinin kodunu çözmek için yukarıdaki adımları ters sırada uygular.
Yayından kaldırma indekslerinin kodunu çözme
Kaldırma dizinleri, 32 bit tam sayılar kullanılarak yukarıdakiyle tam olarak aynı teknikle kodlanır.
Güncelleme Sıklığı
İstemci, minimum_wait_duration alanındaki sunucunun döndürdüğü değeri incelemeli ve veritabanının bir sonraki güncellemesini planlamak için bu değeri kullanmalıdır. Bu değer muhtemelen sıfırdır (minimum_wait_duration alanı tamamen eksiktir). Bu durumda istemcinin hemen başka bir güncelleme yapması GEREKİR.
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-07-25 UTC.
[[["Anlaması kolay","easyToUnderstand","thumb-up"],["Sorunumu çözdü","solvedMyProblem","thumb-up"],["Diğer","otherUp","thumb-up"]],[["İhtiyacım olan bilgiler yok","missingTheInformationINeed","thumb-down"],["Çok karmaşık / çok fazla adım var","tooComplicatedTooManySteps","thumb-down"],["Güncel değil","outOfDate","thumb-down"],["Çeviri sorunu","translationIssue","thumb-down"],["Örnek veya kod sorunu","samplesCodeIssue","thumb-down"],["Diğer","otherDown","thumb-down"]],["Son güncelleme tarihi: 2025-07-25 UTC."],[],[],null,["# Local Database\n\nGoogle Safe Browsing v5 expects the client to maintain a local database, except when the client chooses the [No-Storage Real-Time Mode](/safe-browsing/reference#no-storage-real-time-mode). It is up to the client the format and storage of this local database. The contents of this local database can conceptually be thought of as a folder containing various lists as files, and the contents of these files are SHA256 hashes, or their corresponding prefixes with four byte hash prefix being the most commonly used hash length.\n\n### Available Lists\n\nLists are identified by their distinct names which follows a naming convention where the name contains a suffix that signifies the length of the hash you should expect in the list. Hash lists with the same threat type but different hash length will be a separately named list that's qualified with a suffix that indicates the hash length.\n\nThe following lists are available for use with the hash list methods.\n\n| List Name | Corresponding v4 `ThreatType` Enum | Description |\n|-----------|------------------------------------|------------------------------------------------------------------------------------------------------|\n| `gc-32b` | None | This list is a Global Cache list. It is a special list only used in the Real-Time mode of operation. |\n| `se-4b` | `SOCIAL_ENGINEERING` | This list contains threats of the SOCIAL_ENGINEERING threat type. |\n| `mw-4b` | `MALWARE` | This list contains threats of the MALWARE threat type for desktop platforms. |\n| `uws-4b` | `UNWANTED_SOFTWARE` | This list contains threats of the UNWANTED_SOFTWARE threat type for desktop platforms. |\n| `uwsa-4b` | `UNWANTED_SOFTWARE` | This list contains threats of the UNWANTED_SOFTWARE threat type for Android platforms. |\n| `pha-4b` | `POTENTIALLY_HARMFUL_APPLICATION` | This list contains threats of the POTENTIALLY_HARMFUL_APPLICATION threat type for Android platforms. |\n\nAdditional lists can become available at a later date, at which time the above table will be expanded, and the results from the [hashList.list method](/safe-browsing/reference/rest/v5/hashList/list) will show a similar result with the most up to date lists.\n\n### Database Updates\n\nThe client will regularly call the [hashList.get method](/safe-browsing/reference/rest/v5/hashList/get) or the [hashLists.batchGet method](/safe-browsing/reference/rest/v5/hashLists/batchGet) to update the database. Since the typical client will want to update multiple lists at a time, it is recommended to use [hashLists.batchGet method](/safe-browsing/reference/rest/v5/hashLists/batchGet).\n\nThe list names will never be renamed. Furthermore, once a list has appeared, it will never be removed (if the list is no longer useful, it will become empty but will continue to exist). Therefore, it is appropriate to hard code these names in the Google Safe Browsing client code.\n\nBoth the [hashList.get method](/safe-browsing/reference/rest/v5/hashList/get) and the [hashLists.batchGet method](/safe-browsing/reference/rest/v5/hashLists/batchGet) support incremental updates. Using incremental updates saves bandwidth and improves performance. Incremental updates work by delivering a delta between client's version of the list and the latest version of the list. (If a client is newly deployed and does not have any versions available, a full update is available.) The incremental update contains removal indices and additions. The client is first expected to remove the entries at the specified indices from its local database, and then apply the additions.\n\nFinally, to prevent corruption, the client should check the stored data against the checksum provided by the server. Whenever the checksum does not match, the client should perform a full update.\n\n### Decoding the List Content\n\n#### Decoding Hashes and Hash Prefixes\n\nAll lists are delivered using a special encoding to reduce size. This encoding works by recognizing that Google Safe Browsing lists contain, conceptually, a set of hashes or hash prefixes, which are statistically indistinguishable from random integers. If we were to sort these integers and take their adjacent difference, such adjacent difference is expected to be \"small\" in a sense. [Golomb-Rice encoding](https://en.wikipedia.org/wiki/Golomb_coding) then exploits this smallness.\n\nSuppose that three host-suffix path-prefix expressions, namely `a.example.com/`, `b.example.com/`, and `y.example.com/`, are to be transmitted using 4-byte hash prefixes. Further suppose that the Rice parameter, denoted by k, is chosen to be\n\n1. The server would start by calculating the full hash for these strings, which are, respectively:\n\n 291bc5421f1cd54d99afcc55d166e2b9fe42447025895bf09dd41b2110a687dc a.example.com/\n 1d32c5084a360e58f1b87109637a6810acad97a861a7769e8f1841410d2a960c b.example.com/\n f7a502e56e8b01c6dc242b35122683c9d25d07fb1f532d9853eb0ef3ff334f03 y.example.com/\n\nThe server then forms 4-byte hash prefixes for each of the above, which is the first 4 bytes of the 32-byte full hash, interpreted as big-endian 32-bit integers. The big endianness refers to the fact that the first byte of the full hash becomes the most significant byte of the 32-bit integer. This step results in the integers 0x291bc542, 0x1d32c508, and 0xf7a502e5.\n\nIt is necessary for the server to sort these three hash prefixes lexicographically (equivalent to numerical sorting in big endian), and the result of the sorting is 0x1d32c508, 0x291bc542, 0xf7a502e5. The first hash prefix is stored unchanged in the `first_value` field.\n\nThe server then calculates the two adjacent differences, which are 0xbe9003a and 0xce893da3 respectively. Given that k is chosen to be 30, the server splits these two numbers into the quotient parts and remainder parts that are 2 and 30 bits long respectively. For the first number, the quotient part is zero and the remainder is 0xbe9003a; for the second number, the quotient part is 3 because the most significant two bits are 11 in binary and the remainder is 0xe893da3. For a given quotient `q` it is encoded into `(1 \u003c\u003c q) - 1` using exactly `1 + q` bits; the remainder is encoded directly using k bits. The quotient part of the first number is encoded as 0, and the remainder part is in binary 001011111010010000000000111010; the quotient part of the second number is encoded as 0111, and the remainder part is 001110100010010011110110100011.\n\nWhen these numbers are formed into a byte string, little endian is used. Conceptually it may be easier to imagine a long bitstring being formed starting from the least significant bits: we take the quotient part of the first number and prepend the remainder part of the first number; we then further prepend the quotient part of the second number and prepend the remainder part. This should result in the following large number (linebreaks and comments added for clarity): \n\n 001110100010010011110110100011 # Second number, remainder part\n 0111 # Second number, quotient part\n 001011111010010000000000111010 # First number, remainder part\n 0 # First number, quotient part\n\nWritten in a single line this would be \n\n 00111010001001001111011010001101110010111110100100000000001110100\n\nObviously this number far exceeds the 8 bits available in a single byte. The little endian encoding then takes the least significant 8 bits in that number, and outputs it as the first byte which is 01110100. For clarity, we can group the above bitstring into groups of eight starting from the least significant bits: \n\n 0 01110100 01001001 11101101 00011011 10010111 11010010 00000000 01110100\n\nThe little endian encoding then takes each byte from the right and puts that into a bytestring: \n\n 01110100\n 00000000\n 11010010\n 10010111\n 00011011\n 11101101\n 01001001\n 01110100\n 00000000\n\nIt can be seen that since we conceptually *prepend* new parts to the large number on the left (i.e. adding more significant bits) but we encode from the right (i.e. the least significant bits), the encoding and decoding can be performed incrementally.\n\nThis finally results in \n\n additions_four_bytes {\n first_value: 489866504\n rice_parameter: 30\n entries_count: 2\n encoded_data: \"t\\000\\322\\227\\033\\355It\\000\"\n }\n\nThe client simply follows the above steps in reverse to decode the hash prefixes.\n\n#### Decoding Removal Indices\n\nRemoval indices are encoded using the exact same technique as above using 32-bit integers.\n\n### Update Frequency\n\nThe client should inspect the server's returned value in the field `minimum_wait_duration` and use that to schedule the next update of the database. This value is possibly zero (the field `minimum_wait_duration` is completely missing), in which case the client SHOULD immediately perform another update."]]
