Real Time Mode

जब क्लाइंट, Google Safe Browsing v5 को रीयल-टाइम मोड में इस्तेमाल करते हैं, तो वे अपने लोकल डेटाबेस में ये चीज़ें सेव करते हैं: (i) ऐसी साइटों का ग्लोबल कैश जो शायद सुरक्षित हों. इन्हें होस्ट-सफ़िक्स/पाथ-प्रीफ़िक्स यूआरएल एक्सप्रेशन के SHA256 हैश के तौर पर फ़ॉर्मैट किया जाता है, (ii) खतरों की सूची का एक सेट. इसे होस्ट-सफ़िक्स/पाथ-प्रीफ़िक्स यूआरएल एक्सप्रेशन के SHA256 हैश प्रीफ़िक्स के तौर पर फ़ॉर्मैट किया जाता है. इसका मतलब यह है कि जब भी क्लाइंट को किसी यूआरएल की जांच करनी होती है, तब ग्लोबल कैश का इस्तेमाल करके स्थानीय जांच की जाती है. अगर यह जांच पास हो जाती है, तो स्थानीय थ्रेट लिस्ट की जांच की जाती है. अगर ऐसा नहीं होता है, तो क्लाइंट, रीयल-टाइम हैश की जांच जारी रखता है. इसके बारे में यहां बताया गया है.

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

इस प्रक्रिया के बारे में ज़्यादा जानकारी यहां दी गई है.

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

यह तरीका, एक यूआरएल u लेता है और SAFE, UNSAFE या UNSURE दिखाता है. अगर यह SAFE दिखाता है, तो इसका मतलब है कि Google Safe Browsing के हिसाब से यूआरएल सुरक्षित है. अगर यह UNSAFE दिखाता है, तो इसका मतलब है कि Google सुरक्षित ब्राउज़िंग के हिसाब से यूआरएल संभावित रूप से असुरक्षित है. इसलिए, ज़रूरी कार्रवाई की जानी चाहिए. जैसे, असली उपयोगकर्ता को चेतावनी दिखाना, मिले हुए मैसेज को स्पैम फ़ोल्डर में ले जाना या आगे बढ़ने से पहले उपयोगकर्ता से अतिरिक्त पुष्टि कराना. अगर यह UNSURE दिखाता है, तो इसके बाद स्थानीय जांच की इस प्रक्रिया का इस्तेमाल किया जाना चाहिए.

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

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