No Storage Real Time Mode

When clients choose to use Google Safe Browsing v5 in the no-storage real-time mode, the client need not maintain any persistent local database. However, the client is still expected to maintain a local cache. Such a local cache need not be in persistent storage and may be cleared in case of memory pressure.

Whenever the client wishes to check a particular URL, the client always connects to the server to perform a check. This mode is similar to what clients of the v4 Lookup API may implement.

Compared to the Real-Time Mode, this mode may use more network bandwidth but may be more suitable if it is inconvenient for the client to maintain persistent local state.

The Real-Time URL Check Procedure Without a Local Database

This procedure takes a single URL u and returns SAFE or UNSAFE.

  1. Let expressions be a list of suffix/prefix expressions generated by the URL u.
  2. Let expressionHashes be a list, where the elements are SHA256 hashes of each expression in expressions.
  3. Let expressionHashPrefixes be a list, where the elements are the first 4 bytes of each hash in expressionHashes.
  4. For each expressionHashPrefix of expressionHashPrefixes:
    1. Look up expressionHashPrefix in the local cache.
    2. If the cached entry is found:
      1. Determine whether the current time is greater than its expiration time.
      2. If it is greater:
        1. Remove the found cached entry from the local cache.
        2. Continue with the loop.
      3. If it is not greater:
        1. Remove this particular expressionHashPrefix from expressionHashPrefixes.
        2. Check whether the corresponding full hash within expressionHashes is found in the cached entry.
        3. If found, return UNSAFE.
        4. If not found, continue with the loop.
    3. If the cached entry is not found, continue with the loop.
  5. Send expressionHashPrefixes to the Google Safe Browsing v5 server using RPC SearchHashes or the REST method hashes.search. If an error occurred (including network errors, HTTP errors, etc), return SAFE. Otherwise, let response be the response received from the SB server, which is a list of full hashes together with some auxiliary information identifying the nature of the threat (social engineering, malware, etc), as well as the cache expiration time expiration.
  6. For each fullHash of response:
    1. Insert fullHash into the local cache, together with expiration.
  7. For each fullHash of response:
    1. Let isFound be the result of finding fullHash in expressionHashes.
    2. If isFound is False, continue with the loop.
    3. If isFound is True, return UNSAFE.
  8. Return SAFE.

Just like the Real-Time Mode, this procedure does not specify exactly how to send the hash prefixes to the server. For example, it is acceptable for the client to send all the expressionHashPrefixes in a single request, and it is also acceptable for the client to send each individual prefix in expressionHashPrefixes to the server in separate requests (perhaps proceeding in parallel). It is also acceptable for the client to send unrelated or randomly generated hash prefixes together with the hash prefixes in expressionHashPrefixes, as long as the number of hash prefixes sent in a single request does not exceed 30.