No Storage Real Time Mode

जब क्लाइंट, नो-स्टोरेज रीयल-टाइम मोड में Google Safe Browsing v5 का इस्तेमाल करते हैं, तो क्लाइंट को किसी भी परसिस्टेंट लोकल डेटाबेस को बनाए रखने की ज़रूरत नहीं होती. हालांकि, क्लाइंट को अब भी लोकल कैश मेमोरी बनाए रखनी होगी. इस तरह की लोकल कैश मेमोरी को परसिस्टेंट स्टोरेज में सेव करने की ज़रूरत नहीं होती. साथ ही, मेमोरी पर दबाव पड़ने पर इसे मिटाया जा सकता है.

जब भी क्लाइंट को किसी यूआरएल की जांच करनी होती है, तो वह हमेशा जांच करने के लिए सर्वर से कनेक्ट होता है. यह मोड, v4 Lookup API के क्लाइंट के लिए उपलब्ध मोड जैसा ही है.

रीयल-टाइम मोड की तुलना में, यह मोड ज़्यादा नेटवर्क बैंडविथ का इस्तेमाल कर सकता है. हालांकि, अगर क्लाइंट के लिए लगातार लोकल स्टेट को बनाए रखना मुश्किल है, तो यह मोड ज़्यादा सही हो सकता है.

लोकल डेटाबेस के बिना रीयल-टाइम में यूआरएल की जांच करने की प्रक्रिया

यह तरीका, एक यूआरएल u लेता है और SAFE या UNSAFE दिखाता है.

1. मान लें कि expressions, यूआरएल u से जनरेट किए गए प्रत्यय/उपसर्ग एक्सप्रेशन की सूची है.
2. मान लें कि expressionHashes एक सूची है, जिसमें expressions के हर एक्सप्रेशन के SHA256 हैश शामिल हैं.
3. मान लें कि expressionHashPrefixes एक सूची है, जिसमें एलिमेंट, expressionHashes में मौजूद हर हैश के पहले चार बाइट हैं.
4. expressionHashPrefixes के हर expressionHashPrefix के लिए:
   1. स्थानीय कैश में expressionHashPrefix को ढूंढें.
   2. अगर कैश मेमोरी में सेव की गई एंट्री मिल जाती है, तो:
      1. यह तय करता है कि मौजूदा समय, कुकी के खत्म होने के समय से ज़्यादा है या नहीं.
      2. अगर यह ज़्यादा है, तो:
         1. लोकल कैश से, कैश की गई एंट्री को हटाता है.
         2. लूप जारी रखें.
      3. अगर यह इससे ज़्यादा नहीं है, तो:
         1. expressionHashPrefixes से इस expressionHashPrefix को हटाएं.
         2. देखें कि expressionHashes में मौजूद पूरा हैश, कैश मेमोरी में सेव की गई एंट्री में मौजूद है या नहीं.
         3. अगर ऐसा होता है, तो UNSAFE दिखाएं.
         4. अगर नहीं मिलता है, तो लूप जारी रखें.
   3. अगर कैश मेमोरी में सेव की गई एंट्री नहीं मिलती है, तो लूप जारी रखें.
5. RPC SearchHashes या REST तरीके hashes.search का इस्तेमाल करके, expressionHashPrefixes को Google Safe Browsing v5 सर्वर पर भेजें. अगर कोई गड़बड़ी हुई है (जैसे, नेटवर्क की गड़बड़ियां, एचटीटीपी गड़बड़ियां वगैरह), तो SAFE दिखाएं. अगर ऐसा नहीं है, तो एसबी सर्वर से मिले response को रिस्पॉन्स के तौर पर सेट करें. यह पूरी हैश की सूची होती है. इसमें कुछ अन्य जानकारी भी होती है, जिससे खतरे के बारे में पता चलता है. जैसे, सोशल इंजीनियरिंग, मैलवेयर वगैरह. साथ ही, इसमें कैश मेमोरी के खत्म होने का समय expiration भी होता है.
6. response के हर fullHash के लिए:
   1. fullHash को expiration के साथ लोकल कैश मेमोरी में डालें.
7. response के हर fullHash के लिए:
   1. मान लें कि expressionHashes में fullHash को खोजने पर isFound मिलता है.
   2. अगर isFound की वैल्यू False है, तो लूप जारी रखें.
   3. अगर isFound सही है, तो UNSAFE दिखाएं.
8. वापसी की तारीख: SAFE.

रीयल-टाइम मोड की तरह ही, इस तरीके में यह नहीं बताया गया है कि सर्वर को हैश प्रीफ़िक्स कैसे भेजे जाएं. उदाहरण के लिए, क्लाइंट के लिए यह स्वीकार्य है कि वह एक ही अनुरोध में सभी expressionHashPrefixes भेजे. साथ ही, क्लाइंट के लिए यह भी स्वीकार्य है कि वह expressionHashPrefixes में मौजूद हर प्रीफ़िक्स को सर्वर पर अलग-अलग अनुरोधों में भेजे. ऐसा हो सकता है कि वह एक साथ कई अनुरोध भेजे. क्लाइंट, expressionHashPrefixes में दिए गए हैश प्रीफ़िक्स के साथ-साथ, मिलते-जुलते या रैंडम तरीके से जनरेट किए गए हैश प्रीफ़िक्स भी भेज सकता है. हालांकि, यह ज़रूरी है कि एक अनुरोध में भेजे गए हैश प्रीफ़िक्स की संख्या 30 से ज़्यादा न हो.