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 से ज़्यादा न हो.