Overview

नया डेटा

वर्शन 4 (खास तौर पर, v4 अपडेट एपीआई) के मुकाबले, Google सुरक्षित ब्राउज़िंग के v5 वर्शन में हुए एक अहम सुधार, डेटा अपडेट होने की फ़्रीक्वेंसी और कवरेज है. डेटा की सुरक्षा, क्लाइंट के रखरखाव किए गए लोकल डेटाबेस पर बहुत ज़्यादा निर्भर करती है. इसलिए, लोकल डेटाबेस के अपडेट होने में होने वाली देरी और साइज़ की वजह से, सुरक्षा से जुड़े जोखिम की आशंका सबसे ज़्यादा होती है. वर्शन 4 में, सामान्य क्लाइंट को खतरे की सूचियों का सबसे अप-टू-डेट वर्शन पाने में 20 से 50 मिनट लगते हैं. हालांकि, फ़िशिंग अटैक बहुत तेज़ी से फैल रहे हैं: 2021 तक, ऐसी 60% साइटें जो 10 मिनट से भी कम समय में ऑनलाइन रहती हैं. हमारे विश्लेषण से पता चलता है कि डेटा की पुरानी जानकारी की वजह से, 25 से 30% तक फ़िशिंग से सुरक्षा नहीं मिलती. इसके अलावा, कुछ डिवाइस में Google सुरक्षित ब्राउज़िंग से जुड़ी खतरे की सूचियों को पूरी तरह से मैनेज नहीं किया जा सकता. ये समस्याएं समय के साथ बढ़ती जा रही हैं.

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

आईपी निजता

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

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

अनुमति का इस्तेमाल

सुरक्षित ब्राउज़िंग एपीआई सिर्फ़ गैर-व्यावसायिक इस्तेमाल के लिए है (इसका मतलब है कि “बिक्री या आय जनरेट करने के मकसद से नहीं”). अगर आपको व्यावसायिक उद्देश्यों के लिए कोई समाधान चाहिए, तो कृपया वेब रिस्क देखें.

कीमत

Google सुरक्षित ब्राउज़िंग के सभी एपीआई बिना किसी शुल्क के उपलब्ध हैं.

कोटा

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

सही यूआरएल

Google सुरक्षित ब्राउज़िंग को उन यूआरएल पर कार्रवाई करने के लिए डिज़ाइन किया गया है जो ब्राउज़र के पता बार में दिखाए जाते हैं. इसे सबरिसॉर्स (जैसे कि किसी एचटीएमएल फ़ाइल से रेफ़र की गई JavaScript या इमेज या JavaScript से शुरू किया गया WebSocket यूआरएल) की जांच करने के लिए नहीं बनाया गया है. ऐसे सबरिसॉर्स यूआरएल की जांच, 'Google सुरक्षित ब्राउज़िंग' के तहत नहीं की जानी चाहिए.

अगर किसी यूआरएल पर जाने से रीडायरेक्ट (जैसे कि एचटीटीपी 301) दिखता है, तो Google सुरक्षित ब्राउज़िंग के लिए रीडायरेक्ट किए गए यूआरएल की जांच करना सही होगा. क्लाइंट-साइड यूआरएल में बदलाव, जैसे कि History.pushState की वजह से नए यूआरएल की जांच, 'Google सुरक्षित ब्राउज़िंग' के तहत नहीं की जाती.

उपयोगकर्ता चेतावनियां

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

इन दिशा-निर्देशों की मदद से, आप और Google, दोनों को किसी भी तरह की ग़लतफ़हमी से बचाने में मदद मिलती है. इसके लिए, यह साफ़ तौर पर बताया जाता है कि पेज को पक्के तौर पर असुरक्षित वेब रिसॉर्स के तौर पर पहचाना नहीं जा सका. साथ ही, चेतावनियां सिर्फ़ संभावित जोखिम की पहचान करती हैं.

• उपयोगकर्ताओं को दिखने वाली चेतावनी में, आपको उपयोगकर्ताओं को यह नहीं भरोसा दिलाना चाहिए कि जिस पेज की शिकायत की गई है वह असुरक्षित वेब संसाधन है. जब पहचाने जा रहे पेज या इससे उपयोगकर्ताओं को होने वाले संभावित खतरों के बारे में बात की जाती है, तो आपको चेतावनी के लिए इन शब्दों का इस्तेमाल करना होगा: संदिग्ध, संभावित, संभव, संभावना हो.
• आपकी चेतावनी में लोगों को ज़्यादा जानकारी मिलनी चाहिए. इसके लिए, यह ज़रूरी है कि Google ने अलग-अलग खतरों की परिभाषा को समझ लिया हो. यहां दिए गए लिंक सुझाए गए हैं:
  • सोशल इंजीनियरिंग: https://developers.google.com/search/docs/monitor-debug/security/social-engineering
  • मैलवेयर और अनचाहा सॉफ़्टवेयर: https://developers.google.com/search/docs/monitor-debug/security/malware
  • नुकसान पहुंचा सकने वाले ऐप्लिकेशन (सिर्फ़ Android के लिए): https://developers.google.com/android/play-protect/potentially-harmful-applications
• सुरक्षित ब्राउज़िंग सेवा ने जिन पेजों की पहचान जोखिम वाले पेजों के तौर पर की है उनके लिए चेतावनियां दिखाने पर, आपको Google को एट्रिब्यूशन देना होगा. इसके लिए, आपको सुरक्षित ब्राउज़िंग से जुड़ी सलाह के लिंक के साथ, "Google की ओर से दी गई सलाह" लाइन शामिल करनी होगी. अगर आपका प्रॉडक्ट अन्य सोर्स के आधार पर चेतावनियां भी दिखाता है, तो आपको Google से बाहर के डेटा से मिलने वाली चेतावनियों में Google एट्रिब्यूशन को शामिल नहीं करना चाहिए.

• अपने प्रॉडक्ट के दस्तावेज़ों में, आपको उपयोगकर्ताओं को यह बताना होगा कि 'Google सुरक्षित ब्राउज़िंग' से मिलने वाली सुरक्षा सटीक नहीं है. कॉन्टेंट में उन्हें यह बताया जाना चाहिए कि इससे फ़ॉल्स पॉज़िटिव (सुरक्षित साइटें जोखिम वाली साइट के तौर पर फ़्लैग की गई) और फ़ॉल्स नेगेटिव (जिन साइटों को फ़्लैग नहीं किया गया हो), दोनों की आशंका है. हमारा सुझाव है कि आप नीचे दी गई भाषा का इस्तेमाल करें:

  Google, असुरक्षित वेब संसाधनों के बारे में सबसे सटीक और अप-टू-डेट जानकारी देने की कोशिश करता है. हालांकि, Google इस बात की गारंटी नहीं दे सकता कि इसकी जानकारी में कोई गड़बड़ी नहीं है. साथ ही, इसमें जोखिम वाली कुछ साइटों की पहचान नहीं की जा सकती. साथ ही, कुछ सुरक्षित साइटों को गलती से पहचाना जा सकता है.

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

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

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

इस प्रक्रिया की पूरी जानकारी यहां दी गई है.

स्थानीय सूची मोड

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

जैसा कि ऊपर बताया गया है, क्लाइंट उस लोकल कैश मेमोरी को भी बनाए रखेगा जिसे स्थायी स्टोरेज में नहीं होना चाहिए.

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

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

यूआरएल को कैननिकल बनाना

किसी भी यूआरएल की जांच से पहले, क्लाइंट को उस यूआरएल पर कुछ चीज़ों के कैननिकल होने की जांच करनी होती है.

शुरू करने के लिए, हम मान लेते हैं कि क्लाइंट ने यूआरएल को पार्स कर दिया है और उसे आरएफ़सी 2396 के मुताबिक मान्य बना दिया है. अगर यूआरएल, अंतरराष्ट्रीय डोमेन नेम (आईडीएन) का इस्तेमाल करता है, तो क्लाइंट को यूआरएल को ASCII पनीकोड रिप्रज़ेंटेशन में बदलना चाहिए. यूआरएल में पाथ कॉम्पोनेंट शामिल होना चाहिए. इसका मतलब है कि डोमेन के बाद (http://google.com के बजाय http://google.com/) कम से कम एक स्लैश होना चाहिए.

सबसे पहले, यूआरएल से Tab (0x09), CR (0x0d), और LF (0x0a) वर्ण हटाएं. इन वर्णों के लिए एस्केप सीक्वेंस न हटाएं (जैसे, %0a).

दूसरा, अगर यूआरएल किसी फ़्रैगमेंट पर खत्म होता है, तो फ़्रैगमेंट हटा दें. उदाहरण के लिए, http://google.com/#frag को http://google.com/ तक छोटा करें.

तीसरा, यूआरएल का बार-बार प्रतिशत-अन-एस्केप तब तक करें, जब तक कि उसमें कोई और प्रतिशत-बच नहीं हो जाता. (इससे यूआरएल अमान्य हो सकता है.)

होस्टनेम को कैननिकल बनाने के लिए:

यूआरएल से होस्टनेम एक्सट्रैक्ट करें. इसके बाद:

1. शुरुआत और आखिर के सभी बिंदुओं को हटाएं.
2. लगातार आने वाले बिंदुओं को एक बिंदु से बदलें.
3. अगर होस्टनेम को आईपीवी4 पते के तौर पर पार्स किया जा सकता है, तो उसे चार बिंदुओं से अलग की गई दशमलव वैल्यू में सामान्य बनाएं. क्लाइंट को आईपी पते को कोड में बदलने के किसी भी कानूनी तरीके का इस्तेमाल करना चाहिए. इसमें ऑक्टल, हेक्स, और चार से कम कॉम्पोनेंट शामिल हैं.
4. अगर होस्टनेम को ब्रैकेट किए गए आईपीवी6 पते के तौर पर पार्स किया जा सकता है, तो उसे सामान्य बनाने के लिए, कॉम्पोनेंट से शुरुआती शून्यों को हटाएं और शून्य कॉम्पोनेंट को छोटा करने के लिए, डबल-कोलन सिंटैक्स का इस्तेमाल करें. उदाहरण के लिए, [2001:0db8:0000::1] को [2001:db8::1] में बदलना चाहिए. अगर होस्टनेम इन दो खास IPv6 पता टाइप में से कोई एक है, तो उन्हें IPv4 में बदलें:
   • IPv4-मैप किया गया IPv6 पता, जैसे कि [::ffff:1.2.3.4], जिसे 1.2.3.4 में बदला जाना चाहिए;
   • जाने-पहचाने प्रीफ़िक्स 64:ff9b::/96 का इस्तेमाल करने वाला NAT64 पता, जैसे कि [64:ff9b::1.2.3.4], जिसे 1.2.3.4 में बदला जाना चाहिए.
5. पूरी स्ट्रिंग के छोटे अक्षरों का इस्तेमाल करें.

पाथ को कैननिकल बनाने के लिए:

1. पाथ में क्रम /../ और /./ को ठीक करें. इसके लिए, /./ को / से बदलें और पिछले पाथ कॉम्पोनेंट के साथ-साथ /../ को हटाएं.
2. लगातार चलने वाले स्लैश को एक स्लैश वर्ण से बदलें.

क्वेरी पैरामीटर पर इन पाथ के कैननिकल होने की जांच न करें.

यूआरएल में, उन सभी वर्णों का प्रतिशत-एस्केप करें जो <= ASCII 32, >= 127, # या % हैं. एस्केप में अपरकेस हेक्स वर्णों का इस्तेमाल किया जाना चाहिए.

होस्ट-सफ़िक्स पाथ-प्रीफ़िक्स एक्सप्रेशन

यूआरएल के कैननिकल होने के बाद, अगला चरण सफ़िक्स/प्रीफ़िक्स एक्सप्रेशन बनाना है. हर सफ़िक्स/प्रीफ़िक्स एक्सप्रेशन में एक होस्ट सफ़िक्स (या पूरा होस्ट) और एक पाथ प्रीफ़िक्स या पूरा पाथ होता है.

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

होस्ट के लिए, क्लाइंट ज़्यादा से ज़्यादा पांच अलग-अलग स्ट्रिंग को आज़माएगा. ये वजह हैं:

• अगर होस्टनेम, IPv4 या IPv6 लिटरल नहीं है, तो eTLD+1 डोमेन से शुरू करके और क्रम के मुताबिक मुख्य कॉम्पोनेंट जोड़कर, ज़्यादा से ज़्यादा चार होस्टनेम बनाए जा सकते हैं. eTLD+1 का पता, सार्वजनिक सफ़िक्स सूची के आधार पर होना चाहिए. उदाहरण के लिए, a.b.example.com का नतीजा example.com के eTLD+1 डोमेन के साथ-साथ एक अतिरिक्त होस्ट कॉम्पोनेंट b.example.com वाला होस्ट होगा.
• यूआरएल में मौजूद होस्टनेम. पिछले उदाहरण के मुताबिक, a.b.example.com की जांच की जाएगी.

पाथ के लिए, क्लाइंट ज़्यादा से ज़्यादा छह अलग-अलग स्ट्रिंग को आज़माएगा. ये वजह हैं:

• क्वेरी पैरामीटर के साथ-साथ यूआरएल का सटीक पाथ.
• क्वेरी पैरामीटर के बिना, यूआरएल का सटीक पाथ.
• रूट (/) से शुरू करके और पीछे लगने वाले स्लैश के साथ, पाथ के कॉम्पोनेंट को लगातार जोड़कर, चार पाथ बनाए जाते हैं.

इन उदाहरणों में, जांच के तरीके के बारे में बताया गया है:

यूआरएल http://a.b.com/1/2.html?param=1 के लिए, क्लाइंट इन संभावित स्ट्रिंग को आज़माएगा:

a.b.com/1/2.html?param=1
a.b.com/1/2.html
a.b.com/
a.b.com/1/
b.com/1/2.html?param=1
b.com/1/2.html
b.com/
b.com/1/

यूआरएल http://a.b.c.d.e.f.com/1.html के लिए, क्लाइंट इन संभावित स्ट्रिंग को आज़माएगा:

a.b.c.d.e.f.com/1.html
a.b.c.d.e.f.com/
c.d.e.f.com/1.html
c.d.e.f.com/
d.e.f.com/1.html
d.e.f.com/
e.f.com/1.html
e.f.com/
f.com/1.html
f.com/

(ध्यान दें: b.c.d.e.f.com को छोड़ें, क्योंकि हम सिर्फ़ आखिरी पांच होस्टनेम कॉम्पोनेंट और पूरा होस्टनेम लेंगे.)

यूआरएल http://1.2.3.4/1/ के लिए, क्लाइंट इन संभावित स्ट्रिंग को आज़माएगा:

1.2.3.4/1/
1.2.3.4/

यूआरएल http://example.co.uk/1 के लिए, क्लाइंट इन संभावित स्ट्रिंग को आज़माएगा:

example.co.uk/1
example.co.uk/

हैशिंग

'Google सुरक्षित ब्राउज़िंग' खास तौर पर हैश फ़ंक्शन के तौर पर SHA256 का इस्तेमाल करता है. यह हैश फ़ंक्शन ऊपर दिए गए एक्सप्रेशन पर लागू किया जाना चाहिए.

हालात के मुताबिक, पूरे 32-बाइट वाले हैश को 4 बाइट, 8 बाइट या 16 बाइट तक छोटा किया जाएगा:

• hashes.search के तरीके का इस्तेमाल करते समय, फ़िलहाल हमें अनुरोध में हैश की संख्या को चार बाइट तक कम करने की ज़रूरत होती है. इस अनुरोध में और बाइट भेजने से उपयोगकर्ता की निजता से छेड़छाड़ होगी.

• hashList.get मेथड या hashLists.batchGet के तरीके का इस्तेमाल करके, लोकल डेटाबेस के लिए सूचियां डाउनलोड करते समय, सर्वर से भेजे गए हैश की लंबाई पर, सूची का टाइप और desired_hash_length पैरामीटर से मिली हैश की लंबाई के लिए क्लाइंट की प्राथमिकता, दोनों का असर पड़ता है.

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

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

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

LocalPlanet के यूआरएल की जांच की प्रक्रिया

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

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

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

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

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

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

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

डेटाबेस से जुड़े अपडेट

डेटाबेस को अपडेट करने के लिए, क्लाइंट नियमित तौर पर hashList.get मेथड या hashLists.batchGet मेथ को कॉल करेगा. आम क्लाइंट एक बार में कई सूचियों को अपडेट करना चाहेगा, इसलिए हमारा सुझाव है कि आप hashLists.batchGet के तरीके का इस्तेमाल करें.

सूचियों की पहचान उनके अलग-अलग नामों से की जाती है. नाम, कुछ वर्णों की छोटी ASCII स्ट्रिंग होती हैं.

वर्शन 4 से अलग, जहां सूची को खतरा टाइप, प्लैटफ़ॉर्म टाइप, और खतरे के एंट्री टाइप से पहचान की जाती है, v5 सूचियों में उन्हें सिर्फ़ नाम से पहचाना जाता है. इससे, एक ही तरह के खतरे को कई वर्शन 5 वाली सूचियों में इस्तेमाल करने का विकल्प मिलता है. वर्शन 5 से प्लैटफ़ॉर्म के टाइप और खतरे की एंट्री को हटा दिया जाता है.

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

hasList.get का तरीका और hashLists.batchGet का तरीका, दोनों ही बार-बार अपडेट होने की सुविधा देते हैं. इंक्रीमेंटल अपडेट का इस्तेमाल करने से बैंडविथ की बचत होती है और परफ़ॉर्मेंस बेहतर होती है. क्लाइंट के वर्शन और सूची के सबसे नए वर्शन के बीच डेल्टा डिलीवर करके, इंक्रीमेंटल अपडेट काम करते हैं. (अगर किसी क्लाइंट को हाल ही में डिप्लॉय किया गया है और उसके पास कोई वर्शन उपलब्ध नहीं है, तो पूरी जानकारी मिलती है.) इंक्रीमेंटल अपडेट में, कॉन्टेंट हटाने के इंडेक्स और कई एलिमेंट शामिल होते हैं. क्लाइंट से पहले यह उम्मीद की जाती है कि वह अपने लोकल डेटाबेस से, तय किए गए इंडेक्स की एंट्री हटाएं और फिर जोड़ को लागू करे.

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

सूची के कॉन्टेंट को डिकोड करना

सभी सूचियां, साइज़ को कम करने के लिए, कोड में बदलने के खास तरीके का इस्तेमाल करके डिलीवर की जाती हैं. कोड में बदलने का यह तरीका, इस बात की पहचान करता है कि Google सुरक्षित ब्राउज़िंग की सूचियों में ऐसे हैश या हैश प्रीफ़िक्स का सेट होता है जिन्हें अलग-अलग पूर्णांकों से अलग नहीं किया जा सकता. अगर हमें इन पूर्णांकों को क्रम से लगाने और उनके बीच के अंतर को समझने की कोशिश करनी हो, तो इस तरह का नज़दीकी अंतर कुछ हद तक "छोटा" होगा. फिर Golomb-Rice एन्कोडिंग इस छोटे पैमाने का फ़ायदा उठाती है.

Google सुरक्षित ब्राउज़िंग v5 में चार अलग-अलग तरह के डेटा, 4-बाइट डेटा, 8-बाइट डेटा, 16-बाइट डेटा, और 32-बाइट डेटा का इस्तेमाल किया जा सकता है. आइए, एक उदाहरण देखते हैं, जिसमें संख्या के हिसाब से लगातार 4-बाइट वाले तीन पूर्णांकों को कोड में बदला जाता है. मान लें कि चावल के पैरामीटर को k से दिखाया गया है और इसे 3 किया गया है. एन्कोडिंग का भागफल वाला हिस्सा, बस एक-दूसरे के बीच का अंतर मान होता है, जिसे k बिट के ज़रिए दाएं शिफ़्ट किया जाता है. दिए गए पूर्णांक क्रमागत होते हैं, इसलिए उनका आस-पास का अंतर 1 होता है और 3 बिट से शिफ़्ट होने के बाद, भागफल वाला हिस्सा शून्य होता है. सबसे कम अहम k बिट 001 हैं. शून्य भागफल के लिए, कोड में एक 0 बिट का इस्तेमाल किया जाता है. बाकी बचा 1 है और उसे 100 के तौर पर एन्कोड किया गया है. बिटस्ट्रीम 01000100 बनाने के लिए, इसे फिर से दोहराया जाता है. नतीजे में मिलने वाले बिटस्ट्रीम को 00100010 के तौर पर छोटे एंडियन का इस्तेमाल करके एन्कोड किया जाता है. इसलिए, यह नीचे दिए गए डेटा से जुड़ा होता है:

rice_parameter: 3
entries_count: 2
encoded_data: "\x22"

32-बिट पूर्णांक के लिए ऊपर दिए गए डिकोड करने के चरण के बाद, नतीजे को सीधे तौर पर हटाने के इंडेक्स या जोड़ के रूप में इस्तेमाल किया जा सकता है. वर्शन 4 से अलग, इसके बाद बाइट-स्वैप करने की ज़रूरत नहीं होती.

उपलब्ध सूचियां

v5alpha1 में इस्तेमाल करने के लिए नीचे दी गई सूचियों का सुझाव दिया जाता है:

बाद में, अन्य सूचियां उपलब्ध होंगी. इसके बाद, ऊपर दी गई टेबल को बड़ा किया जाएगा.

अपडेट का अंतराल

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

सूची में हुए अपडेट को बदला जा रहा है

वर्शन 4 में, सूचियों को डाउनलोड करने के लिए threatListUpdated.fetch तरीके का इस्तेमाल किया जाएगा. वर्शन 5 में, कोई व्यक्ति hashLists.batchGetMethod पर स्विच हो जाएगा.

अनुरोध में ये बदलाव किए जाने चाहिए:

1. v4 ClientInfo ऑब्जेक्ट को पूरी तरह से हटाएं. किसी खास फ़ील्ड का इस्तेमाल करके क्लाइंट की पहचान की जानकारी देने के बजाय, सिर्फ़ लोकप्रिय उपयोगकर्ता-एजेंट हेडर का इस्तेमाल करें. हालांकि इस हेडर में क्लाइंट की पहचान करने के लिए कोई तय फ़ॉर्मैट नहीं है, लेकिन हमारा सुझाव है कि आप मूल क्लाइंट आईडी और क्लाइंट वर्शन को स्पेस वर्ण या स्लैश वर्ण से अलग करके शामिल करें.
2. हर v4 ListUpdateRequest ऑब्जेक्ट के लिए:
   • ऊपर दी गई टेबल में, इससे जुड़े v5 वर्शन की सूची का नाम खोजें और v5 अनुरोध में वह नाम डालें.
   • threat_entry_type या platform_type जैसे ग़ैर-ज़रूरी फ़ील्ड हटाएं.
   • v4 में state फ़ील्ड, v5 versions फ़ील्ड के साथ सीधे काम करता है. v4 में state फ़ील्ड का इस्तेमाल करके सर्वर को भेजी जाने वाली बाइट स्ट्रिंग, versions फ़ील्ड का इस्तेमाल करके v5 में आसानी से भेजी जा सकती है.
   • v4 कंस्ट्रेंट के लिए, v5 SizeConstraints नाम का एक आसान वर्शन इस्तेमाल करता है. region जैसे अतिरिक्त फ़ील्ड को छोड़ देना चाहिए.

जवाब में ये बदलाव किए जाने चाहिए:

1. v4 enum ResponseType को partial_update नाम वाले बूलियन फ़ील्ड से बदल दिया जाता है.
2. minimum_wait_duration फ़ील्ड को अब शून्य या हटाया जा सकता है. अगर ऐसा है, तो क्लाइंट को तुरंत दूसरा अनुरोध करने के लिए कहा जाता है. ऐसा सिर्फ़ तब होता है, जब क्लाइंट SizeConstraints में, अपडेट के ज़्यादा से ज़्यादा साइज़ की सीमा को डेटाबेस के सबसे बड़े साइज़ से कम तय करता है.
3. 32-बिट पूर्णांक के लिए, राइस डिकोडिंग एल्गोरिदम में बदलाव करना होगा. अंतर यह है कि कोड में बदले गए डेटा को अलग तरीके से एन्कोड किया जाता है. v4 और v5, दोनों में 32-बिट हैश प्रीफ़िक्स को लेक्सिकोलॉजिकल तरीके से क्रम में लगाया जाता है. हालांकि, v4 में उन प्रीफ़िक्स को क्रम से लगाने पर, उन्हें छोटे एंडियन माना जाता है. वहीं v5 में, क्रम में लगाए जाने पर उन प्रीफ़िक्स को बड़े एंडियन के तौर पर माना जाता है. इसका मतलब है कि क्लाइंट को किसी भी क्रम में लगाने की ज़रूरत नहीं है, क्योंकि लेक्सिकोग्राफ़िक सॉर्टिंग, बड़े एंडियन के साथ न्यूमेरिक सॉर्टिंग के समान है. v4 के Chromium लागू करने में इस सॉर्ट का एक उदाहरण यहां देखा जा सकता है. इस क्रम को हटाया जा सकता है.
4. हैश की अन्य लंबाई के लिए, राइस डिकोडिंग एल्गोरिदम को लागू करना होगा.

हैश खोजों को बदलना

वर्शन 4 में, पूरे हैश पाने के लिए fullHashes.find तरीके का इस्तेमाल किया जाएगा. वर्शन 5 में इसी तरह का तरीका hashes.search का तरीका है.

अनुरोध में ये बदलाव किए जाने चाहिए:

1. कोड को सिर्फ़ चार बाइट लंबाई वाले हैश प्रीफ़िक्स भेजने के लिए स्ट्रक्चर करें.
2. v4 ClientInfo ऑब्जेक्ट को पूरी तरह से हटाएं. किसी खास फ़ील्ड का इस्तेमाल करके क्लाइंट की पहचान की जानकारी देने के बजाय, सिर्फ़ लोकप्रिय उपयोगकर्ता-एजेंट हेडर का इस्तेमाल करें. हालांकि इस हेडर में क्लाइंट की पहचान करने के लिए कोई तय फ़ॉर्मैट नहीं है, लेकिन हमारा सुझाव है कि आप मूल क्लाइंट आईडी और क्लाइंट वर्शन को स्पेस वर्ण या स्लैश वर्ण से अलग करके शामिल करें.
3. client_states फ़ील्ड को हटाएं. अब इसकी ज़रूरत नहीं है.
4. अब threat_types और इससे मिलते-जुलते फ़ील्ड को शामिल करने की ज़रूरत नहीं है.

जवाब में ये बदलाव किए जाने चाहिए:

1. minimum_wait_duration फ़ील्ड को हटा दिया गया है. क्लाइंट ज़रूरत के हिसाब से किसी भी समय नया अनुरोध कर सकता है.
2. v4 ThreatMatch ऑब्जेक्ट को FullHash ऑब्जेक्ट में आसान बना दिया गया है.
3. डेटा को कैश मेमोरी में सेव करने की अवधि को आसान बना दिया गया है. कैश मेमोरी के साथ इंटरैक्ट करने के लिए ऊपर दी गई प्रक्रियाएं देखें.