Overview

नया डेटा

v5 में, हमने रीयल-टाइम सुरक्षा नाम का एक मोड जोड़ा है. इससे, डेटा पुराना होने की ऊपर बताई गई समस्या हल हो जाती है. वर्शन 4 में, क्लाइंट को एक स्थानीय डेटाबेस डाउनलोड और मैनेज करना होता है. साथ ही, स्थानीय तौर पर डाउनलोड की गई खतरे की सूचियों की जांच करनी होती है. इसके बाद, जब प्रीफ़िक्स का कुछ हिस्सा मैच होता है, तो पूरा हैश डाउनलोड करने का अनुरोध करना होता है. v5 में, क्लाइंट को खतरे वाली साइटों की सूची का लोकल डेटाबेस डाउनलोड और मैनेज करते रहना चाहिए. हालांकि, अब क्लाइंट को ऐसी साइटों की सूची भी डाउनलोड करनी होगी जो शायद नुकसान न पहुंचाती हों. इसे ग्लोबल कैश कहा जाता है. साथ ही, क्लाइंट को इस ग्लोबल कैश और खतरे वाली साइटों की सूची, दोनों की लोकल जांच करनी होगी. आखिर में, अगर खतरे वाली साइटों की सूची के लिए प्रीफ़िक्स का कुछ हिस्सा मैच होता है या ग्लोबल कैश में कोई मैच नहीं होता है, तो पूरे हैश डाउनलोड करने का अनुरोध करें. (क्लाइंट के लिए ज़रूरी स्थानीय प्रोसेसिंग के बारे में जानकारी पाने के लिए, कृपया यहां दी गई प्रोसेस देखें.) इसका मतलब है कि डिफ़ॉल्ट रूप से अनुमति देने की सुविधा को हटाकर, डिफ़ॉल्ट रूप से जांच करने की सुविधा जोड़ी गई है. इससे वेब पर खतरों के तेज़ी से फैलने के मद्देनज़र, सुरक्षा को बेहतर बनाया जा सकता है. दूसरे शब्दों में, यह एक ऐसा प्रोटोकॉल है जिसे रीयल-टाइम में सुरक्षा देने के लिए डिज़ाइन किया गया है: हमारा मकसद क्लाइंट को Google के सुरक्षित ब्राउज़िंग के नए डेटा का फ़ायदा देना है.

आईपी निजता

Google SafeBrowsing (v4 या v5), अनुरोधों को पूरा करने के दौरान उपयोगकर्ता की पहचान से जुड़ी कोई भी जानकारी प्रोसेस नहीं करता. अगर कुकी भेजी जाती हैं, तो उन्हें अनदेखा कर दिया जाता है. Google को अनुरोधों के ओरिजनल आईपी पते की जानकारी होती है. हालांकि, Google इन आईपी पतों का इस्तेमाल सिर्फ़ ज़रूरी नेटवर्किंग ज़रूरतों (जैसे, जवाब भेजने के लिए) और डीओएस (डिस्ट्रिब्यूटेड सर्विस अटैक) से जुड़े कामों के लिए करता है.

हम v5 के साथ-साथ, एक साथ काम करने वाला एक एपीआई भी लॉन्च कर रहे हैं. इसे Safe Browsing Oblivious HTTP Gateway API कहा जाता है. यह Google से असली उपयोगकर्ताओं के आईपी पते छिपाने के लिए, Oblivious HTTP का इस्तेमाल करता है. यह सुविधा, उपयोगकर्ता के अनुरोध के एन्क्रिप्ट (सुरक्षित) किए गए वर्शन को मैनेज करने के लिए, किसी ऐसे तीसरे पक्ष की मदद लेती है जो किसी भी तरह से अनुरोध में शामिल नहीं होता. इसके बाद, वह अनुरोध को Google को फ़ॉरवर्ड करता है. इसलिए, तीसरे पक्ष के पास सिर्फ़ आईपी पतों का ऐक्सेस होता है और Google के पास सिर्फ़ अनुरोध के कॉन्टेंट का ऐक्सेस होता है. तीसरा पक्ष, ऑब्लिवियस एचटीटीपी रिले (जैसे, Fastly की यह सेवा) चलाता है और Google, ऑब्लिवियस एचटीटीपी गेटवे चलाता है. यह एक वैकल्पिक साथी एपीआई है. Google की सुरक्षित ब्राउज़िंग की सुविधा के साथ इसका इस्तेमाल करने पर, असली उपयोगकर्ताओं के आईपी पते Google को नहीं भेजे जाते.

रीयल-टाइम मोड

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

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

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

लोकल लिस्ट मोड

जब क्लाइंट इस मोड में Google सुरक्षित ब्राउज़िंग v5 का इस्तेमाल करते हैं, तो क्लाइंट का व्यवहार v4 Update API जैसा ही होता है. हालांकि, इसमें v5 के बेहतर एपीआई प्लैटफ़ॉर्म का इस्तेमाल किया जाता है. क्लाइंट अपने लोकल डेटाबेस में, खतरे वाली सूचियों का एक सेट बनाए रखेंगे. यह सूची, होस्ट-सर्फ़िक्स/पाथ-प्रीफ़िक्स यूआरएल एक्सप्रेशन के SHA256 हैश प्रीफ़िक्स के तौर पर फ़ॉर्मैट की जाएगी. जब भी क्लाइंट किसी खास यूआरएल की जांच करना चाहता है, तो स्थानीय खतरे की सूची का इस्तेमाल करके जांच की जाती है. अगर कोई मैच होता है, तो ही क्लाइंट जांच जारी रखने के लिए सर्वर से कनेक्ट होता है.

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

स्टोरेज के बिना रीयल-टाइम मोड

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

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

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

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

इस प्रोसेस का इस्तेमाल तब किया जाता है, जब क्लाइंट रीयल-टाइम मोड में काम करना चुनता है.

यह प्रोसेस, एक यूआरएल u लेती है और SAFE, UNSAFE या UNSURE दिखाती है. अगर यह SAFE दिखाता है, तो इसका मतलब है कि Google सुरक्षित ब्राउज़िंग की सुविधा के हिसाब से, यूआरएल सुरक्षित है. अगर यह 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. आरपीसी SearchHashes या REST तरीके hashes.search का इस्तेमाल करके, Google सुरक्षित ब्राउज़िंग v5 सर्वर पर expressionHashPrefixes भेजें. अगर कोई गड़बड़ी हुई है, तो UNSURE दिखाएं. इसमें नेटवर्क से जुड़ी गड़बड़ियां, एचटीटीपी गड़बड़ियां वगैरह शामिल हैं. अगर ऐसा नहीं है, तो रिस्पॉन्स को SB सर्वर से मिला response मानें. यह पूरे हैश की सूची होती है. साथ ही, इसमें खतरे (सोशल इंजीनियरिंग, मैलवेयर वगैरह) की प्रकृति की पहचान करने वाली कुछ सहायक जानकारी और कैश मेमोरी की समयसीमा खत्म होने का समय expiration भी शामिल होता है.
7. response के हर fullHash के लिए:
   1. expiration के साथ-साथ, लोकल कैश में fullHash डालें.
8. response के हर fullHash के लिए:
   1. मान लें कि expressionHashes में fullHash ढूंढने पर isFound मिलता है.
   2. अगर isFound False है, तो लूप जारी रखें.
   3. अगर isFound True है, तो UNSAFE दिखाएं.
9. वापसी की तारीख: SAFE.

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

LocalThreat List में शामिल यूआरएल की जांच करने का तरीका

इस प्रोसेस का इस्तेमाल तब किया जाता है, जब क्लाइंट स्थानीय सूची मोड के लिए ऑप्ट इन करता है. इसका इस्तेमाल तब भी किया जाता है, जब क्लाइंट के ऊपर दिए गए RealTimeCheck प्रोसेस से UNSURE की वैल्यू मिलती है.

यह प्रोसेस, एक यूआरएल 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. expressionHashPrefixes के हर expressionHashPrefix के लिए:
   1. स्थानीय खतरे की सूची के डेटाबेस में expressionHashPrefix खोजें.
   2. अगर expressionHashPrefix को स्थानीय खतरे की सूची के डेटाबेस में नहीं मिलता है, तो उसे expressionHashPrefixes से हटा दें.
6. आरपीसी SearchHashes या REST तरीके hashes.search का इस्तेमाल करके, Google सुरक्षित ब्राउज़िंग v5 सर्वर पर expressionHashPrefixes भेजें. अगर कोई गड़बड़ी हुई है, तो SAFE दिखाएं. जैसे, नेटवर्क से जुड़ी गड़बड़ियां, एचटीटीपी गड़बड़ियां वगैरह. अगर ऐसा नहीं है, तो रिस्पॉन्स को SB सर्वर से मिला response मानें. यह पूरे हैश की सूची होती है. साथ ही, इसमें खतरे (सोशल इंजीनियरिंग, मैलवेयर वगैरह) की प्रकृति की पहचान करने वाली कुछ सहायक जानकारी और कैश मेमोरी की समयसीमा खत्म होने का समय expiration भी शामिल होता है.
7. response के हर fullHash के लिए:
   1. expiration के साथ-साथ, लोकल कैश में fullHash डालें.
8. response के हर fullHash के लिए:
   1. मान लें कि expressionHashes में fullHash ढूंढने पर isFound मिलता है.
   2. अगर isFound False है, तो लूप जारी रखें.
   3. अगर isFound True है, तो UNSAFE दिखाएं.
9. वापसी की तारीख: SAFE.

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

इस प्रोसेस का इस्तेमाल तब किया जाता है, जब क्लाइंट स्टोरेज के बिना रीयल-टाइम मोड में काम करने का विकल्प चुनता है.

यह प्रोसेस, एक यूआरएल 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. आरपीसी SearchHashes या REST तरीके hashes.search का इस्तेमाल करके, Google सुरक्षित ब्राउज़िंग v5 सर्वर पर expressionHashPrefixes भेजें. अगर कोई गड़बड़ी हुई है, तो SAFE दिखाएं. इसमें नेटवर्क से जुड़ी गड़बड़ियां, एचटीटीपी गड़बड़ियां वगैरह शामिल हैं. अगर ऐसा नहीं है, तो रिस्पॉन्स को SB सर्वर से मिला response मानें. यह पूरे हैश की सूची होती है. साथ ही, इसमें खतरे (सोशल इंजीनियरिंग, मैलवेयर वगैरह) की प्रकृति की पहचान करने वाली कुछ सहायक जानकारी और कैश मेमोरी की समयसीमा खत्म होने का समय expiration भी शामिल होता है.
6. response के हर fullHash के लिए:
   1. expiration के साथ-साथ, लोकल कैश में fullHash डालें.
7. response के हर fullHash के लिए:
   1. मान लें कि expressionHashes में fullHash ढूंढने पर isFound मिलता है.
   2. अगर isFound False है, तो लूप जारी रखें.
   3. अगर isFound True है, तो UNSAFE दिखाएं.
8. वापसी की तारीख: SAFE.

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